**** BEGIN LOGGING AT Wed May 05 02:59:56 2021 May 05 10:55:24 m May 05 12:44:16 Hello May 05 12:45:05 BBONE-AI can it be used in medical grade products May 05 12:48:05 well it definitely has no special certification for medical or other safety-critical applications May 05 12:49:46 if you're working on such products, you probably ought to know yourself what kind of requirements you have on the hardware you're using May 05 12:57:01 Hello! Is anyone using the tfmini from benewake.com to handle distance sensing on the BBGG? I am asking b/c I have come across using UART1 as an issue so far but it is a library issue it seems. https://github.com/MomsFriendlyRobotCompany/tfmini is the lib. location. May 05 12:58:05 ... May 05 12:58:53 I can use import serial w/ Python3 to handle this issue but for some reason, the source only works when I attempt to use it w/out a print function. May 05 13:01:45 https://pastebin.com/PBBRsz5h is the odd source but it works and changes when I get closer or further away. May 05 13:02:37 I have only been on this for a night. So, no rush here. I should get further along w/ the source in time. May 05 13:14:14 Scratch that idea of questioning. It seems UART1 on the BBGG is taken up by something. UART2 works just fine! May 05 13:36:19 Anyway, I got some other source to work but not the lib. from /tfmini online. Dang it! May 05 13:38:17 If you all want to use a set of source for the tfmini in cloud9-examples, I can make a push request? May 05 13:39:13 It is python3 but not from that lib. I found this source and changed it up a bit to handle python3 and to make it work as is...w/ just import serial. May 05 14:28:07 does anyone know how to turn off the g_multi device on beaglebone black such that gadgetfs can be mounted? May 05 14:28:07 if i follow the steps here May 05 14:28:08 https://unix.stackexchange.com/questions/492280/how-can-i-avoid-that-the-configuration-of-the-provided-debian-image-for-beagle-b May 05 14:28:08 mv /opt/scripts/boot/am335x_evm.sh /opt/scripts/boot/am335x_evm.sh~ May 05 14:28:09 this does turn off all the usb devices and i can turn on gadgetfs but maybe it's turning off one too many things because now i can't load the kernel module usbq_core May 05 14:44:08 p May 05 14:44:09 p May 05 14:44:09 p May 05 14:44:10 p May 05 15:07:50 nip53: ? May 05 15:08:54 Topgun2000: moving that file is an inappropriate way to disable the service, the appropriate way is "sudo systemctl disable generic-board-startup" May 05 15:09:20 it has no influence whatsoever on loading of kernel modules May 05 15:09:53 there's no kernel module "usbq_core" May 05 15:10:45 based on some googling it seems to be some obscure out-off-tree kernel module you'll have to custom-compile May 05 15:10:52 *out-of-tree May 05 15:12:06 unless you already did, in which case if modprobe fails you'll have to check the kernel log to check what the issue is May 05 15:16:31 Topgun2000: if you indeed manually installed this module, have you run "sudo depmod" afterwards to update the module index ? May 05 15:17:41 (I kind of assume so since I think modprobe can't even load the module at all otherwise, but I'm not 100% sure about that) May 05 15:47:16 hi all -- Can one write a device tree overlay for a custom cape support with mainline linux (without capemgr) or is mainline missing something? May 05 15:48:44 overlays are currently handled entirely in u-boot, no specific kernel support is required May 05 15:49:22 (capemgr is obsolete/deprecated) May 05 15:49:35 zmatt: are you saying that there's no upstream kernel notion of DT overlay yet? May 05 15:49:57 kernel support for overlays is entirely deprecated May 05 15:50:02 even on beaglebone kernels May 05 15:50:12 ho. What's the "new" approach then? May 05 15:50:23 16:48 <@zmatt> overlays are currently handled entirely in u-boot, no specific kernel support is required May 05 15:50:50 I mean for upstream, not u-boot/beagle specifics May 05 15:51:24 did the kernel folks entirely dropped the idea of userspace patched device trees or is there something else planned? May 05 15:52:01 afaik it's dropped entirely, it was buggy from the start because too much in the kernel assumes the DT doesn't change at runtime May 05 15:52:13 true May 05 15:53:00 afaik support for applying overlays to the main dtb is however part of mainline u-boot now May 05 15:53:22 at least the underlying mechanisms, not necessarily a way to use those without a custom boot script May 05 15:54:39 zmatt: so let's say I want to write the board support (device tree) for upstream kernel for my beaglebone black + custom cape, what's the "proper" way? copy-paste arch/arm/boot/dts/am335x-boneblack.dts into arch/arm/boot/dts/am335x-myboard.dts and add the cape nodes in there? May 05 15:55:31 make a custom .dts based on an existing one yes... although instead of copy-pasting you can just #include May 05 15:56:53 (arguably, if your .dts represents a board + added hw then #including the .dts for that board and appending the declarations for your added hw is indeed the correct thing to do) May 05 15:59:30 zmatt: because the cape is literally a daughter board plugged on the bbb, I'm not confortable with the copy-paste approach, since I could miss some changes done on upstream am335x-boneblack.dts. I knew .dts were not supposed to be included, but I guess the C preprocessor support was added for this purpose May 05 16:00:11 so I can have a new arch/arm/boot/dts/am335x-myboard.dts which does #include "am335x-boneblack.dts" and add the cape nodes? May 05 16:00:22 yep totally May 05 16:00:55 https://pastebin.com/b60VG5Ys May 05 16:01:07 I knew I had an example somewhere May 05 16:01:31 I guess the .dtsi extension doesn't really make sense anymore ^^ (Unless you write a CPP-less device tree support) May 05 16:01:41 it very much does make sense May 05 16:02:09 it's a dts source fragment meant to be included (directly or indirectly) into a .dts file May 05 16:03:45 with either /include/ or #include ... the latter only being possible if preprocessed, and required if the included file itself requires preprocessing May 05 16:04:16 (in practice it's best to just stick to #include and forget /include/ exists) May 05 16:05:19 oh actually I think there's a mistake in that example, the AM33XX_IOPAD macro isn't compatible with the BONE_Px_xx macros I recently realized May 05 16:06:26 fixed May 05 16:07:21 zmatt: is this example for a bbb + custom cape? or for a custom board designed from bbb? May 05 16:07:35 bbb + stuff May 05 16:07:40 I guess I mean custom motherboard vs. bbb + custom daughter board May 05 16:07:42 ok May 05 16:07:50 zmatt: thank you so much May 05 16:08:26 in fact the example just shows how to disable HDMI (if you need to free up those pins) and sets up uart4 as example May 05 16:11:31 and how to enable uio-pruss if desired May 05 16:12:09 zmatt: Recently the kernel (commit aafd897a5ac4cb7f9b4f99acc5365a7df1f77aa0) added gpio-line-names to am335x-boneblack.dts, this is the kind of changes I don't want to miss (hence reusing am335x-boneblack.dts). Do you know if this table is needed for custom capes? May 05 16:13:16 I have no idea what that might do, presumably related to the gpio chardev which I don't use May 05 16:13:28 I use gpio-of-helper to declare and name my gpios May 05 16:14:43 I guess these are just default names for the default GPIO lines modes, so "gpioinfo" reports these names and their default values May 05 16:14:48 not very important I guess. May 05 16:14:59 zmatt: I'm not sure to undestand what is dt-bindings/board/am335x-bbw-bbb-base.h in your example? May 05 16:15:11 I do know that 27c90e5e48d008bfda1cf6108eb699697317c67b will break a lot May 05 16:15:32 that's the file that defines the BONE_P9_11 macros etc May 05 16:17:23 zmatt: can't find it in upstream kernel May 05 16:17:46 neither BONE_P9_11 May 05 16:18:20 that's entirely possible, I've never attempted to use a mainline kernel, I'd need to apply a whole bunch of patches from rcn's kernels to get one into a state I'd consider usable May 05 16:20:55 e.g. uio-pruss, gpio-of-helper and various enhacements to gpio-sysfs, un-breaking spidev May 05 16:23:38 ok May 05 16:24:30 zmatt: at least the main idea of your example works and still applies: custom dts #including the upstream am335x-boneblack.dts and defining "cape" nodes. May 05 16:25:36 yep, and if you're using a mainline kernel recent enough to have 27c90e5e48d008bfda1cf6108eb699697317c67b then my pinmux example won't work anyway May 05 16:26:45 (I suspect rcn will revert that commit in his kernels if he hasn't already, since that commit will break every bbb overlay in existence) May 05 16:28:03 pdp7: did you realize that when you committed it? ;P May 05 16:32:58 zmatt: I'm currently using 5.4.93 May 05 16:34:26 okay so you're still way before this commit (or the gpio-line-names one you mentioned) May 05 16:36:24 yes May 05 16:36:43 I was just looking at changes done on am335x-boneblack.dts after this release May 05 16:36:56 since I don't want to break anything after a few kernel bumps May 05 16:37:07 (I guess I won't have a choice) May 05 16:47:28 zmatt: what is the issue? May 05 17:14:51 pdp7: that overlays necessarily assume a particular value of #pinctrl-cells, hence changing that value will break compatibility May 05 17:19:13 Tony suggested the change during a list thread last year. I will talk to Robert about updating our downstream. May 05 17:58:17 it'll basically mean there will be three generations of forward- and backward-incompatible overlays: the 3.8 generation, the current one, and the #pinctrl-cells = <2> one May 05 17:58:21 assuming rcn doesn't revert it May 05 19:03:03 hi folks. I'm having trouble getting a canable USB device to work on my beaglebone black. I'm following the instructions for bringing up the interface and I don't see any clear errors but there seems to be no activity when I try to cansend: https://pastebin.com/e2Z99MrU May 05 19:06:50 can0 and can1 are the built-in CAN controllers, your usb device doesn't look like it's showing up at all May 05 19:08:19 oh the slcan thing May 05 19:09:16 masdf: I tried googling slcand and the example I found doesn't add any interface name to slcand (https://elinux.org/Bringing_CAN_interface_up#SLCAN_based_Interfaces) and the resulting interface is called slcan0 May 05 19:09:35 if you do choose a custom name, you can't use can0 or can1 since those are the built-in can controllers May 05 19:12:18 that's a fair point. I went with the commands I've used on other (non debian) embedded Linux devices but maybe there are some hardware differences I didn't fully appreciate. I'll try to follow the instructions in that link May 05 19:12:32 most linux systems don't have integrated CAN controllers May 05 19:12:34 the BBB has two May 05 19:12:55 i.e. you can just hook up an external transciever (like https://copperhilltech.com/can-bus-mini-breakout-board/ ) May 05 19:13:23 (that's just the first google hit I found, there are probably plenty others) May 05 19:13:44 oh that's a little cleaner than going to USB then to CAN May 05 19:14:22 yeah, using usb would be my last resort May 05 19:16:45 it's the only thing I had handy but you're right May 05 19:17:28 yeah I assumed it was a convenience thing May 05 19:18:04 those instructions worked. There must have been a conflict between the built in interface names and what I was trying to use May 05 19:25:32 just to make sure I understand, the problem was likely that I tried to give a serial CAN interface the same name already in use by the built in CAN controller? Intuitively it makes sense that would be a problem but I'm surprised there was no useful feedback/error info along the way May 05 19:27:46 agreed May 05 19:27:52 file a bug report to slcand ;) May 05 19:28:59 or did it maybe log the error to syslog? May 05 19:29:02 check journalctl May 05 19:29:38 still, it could have determined the problem before daemonizing May 05 19:47:10 so this is when it works: https://pastebin.com/TwYZhjLB May 05 19:47:10 this is when I try to use 'can0': https://pastebin.com/d5dgfXhT May 05 19:47:50 under the hood, slcand always creates slcan0 and then tries to rename the interface if specified. In this case it failed because can0 was taken May 05 19:47:52 May 05 18:45:38 beaglebone slcand[1801]: netdevice slcan0 rename to can0 failed May 05 19:48:19 it looks like slcand removed the interface and presumably exited after that error May 05 19:48:57 very interesting May 05 19:49:03 if you wrap your slcand in a systemd .service file you'd be able to see that more easily May 05 19:49:44 this beaglebone is the first time I've worked with systemd so I'm still learning about how to work with it May 05 19:50:09 ah you don't use linux on desktop? May 05 19:50:33 or I guess you could just never have interacted with it directly I suppose May 05 19:53:34 I've honestly never had to touch the linux OS really, my prior experience was mostly baremetal development so linux was just the environment where I did my development May 05 19:55:07 and all my embedded linux work is with sysv May 05 19:55:53 fair, though that doesn't exclude interacting with systemd... in fact systemd user services can be quite useful too (e.g. automatically run some batch job on a timer, or if a particular file or directory is modified) May 05 19:56:17 oh yeah now that I know about it I'm starting to see the benefits May 05 19:57:42 should you happen to use nodejs, I actually made a module for interacting with systemd (that I really ought to put on npm but still haven't): https://github.com/dutchanddutch/node-sd-daemon/ May 05 19:59:25 I don't currently but I'm always down to try cool things, I'll check it out! May 05 19:59:48 well of course if you can avoid doing development in javascript, your life will probably be better as a result **** ENDING LOGGING AT Thu May 06 02:59:56 2021