**** BEGIN LOGGING AT Wed Nov 13 02:59:58 2019 Nov 13 08:52:54 Hi, i am currently migrating a functional pru program from debian 7.5 to debian IoT 9.5 on a Sancloud BB Enhanced. I am trying to get the pinconfig set using the /boot/uEnv.txt file instead of the previous capemgr slots. I have defined a uboot_overlay_addr0, being the .dtbo file which previously worked with the slots system, however this seems to be ignored or overwritten. As far as I can tell from the boot log, my custom overlay is loaded after the universal Nov 13 08:52:54 cape, then the eMMC and pru_rproc, the rest is disabled. Can someone give me some up to date links on documentation from after the removal of the slots system? Nov 13 10:05:48 rens: do you actually want to use pru_proc instead of uio_pruss? Nov 13 10:06:48 if not, make sure the appropriate line is uncommented (or if your custom overlay already enables pruss then neither needs to be uncommented, although uncommenting the uio-pruss one wouldn't be a problem either) Nov 13 10:07:41 given that pru_rproc wasn't around yet that long ago (as far as I remember) my guess would be this is the problem Nov 13 10:23:05 Hi zmatt, thanks for the quick reply! I have tried disabling all overlays except the universal sancloud dtb, my custom overlay and the eMMC1 overlay.(So also disabled the pruss and uio overlay since the pruss is enabled in my overlay) My overlay is shown under /proc/device-tree/chosen/overlays, so I suppose it is being loaded properly? If I check the pin configuration under /sys/kernel/debug/pinctrl/44e10800.pinmux/pins, it does not match to what I am trying Nov 13 10:23:05 to set. Is this still the correct location to check this? Nov 13 10:23:58 it is, although I also have a script that presents the info from debugfs in a more readable form: https://github.com/mvduin/bbb-pin-utils/#show-pins Nov 13 10:24:31 can you share the source code of your overlay? Nov 13 10:24:43 also check kernel log for errors Nov 13 10:26:18 are you intentionally leaving the universal overlay enabled? I can't remember if cape-universal was already in use back in the debian wheezy days) Nov 13 10:31:21 https://drive.google.com/drive/folders/1fbC9f3rAtdCVHMAKz7tQxo35aQOIPCxE?usp=sharing Nov 13 10:32:23 please use a paste service like pastebin.com ... google drive seems to think .dts is an audio file :P Nov 13 10:33:09 I was not sure if the universal overlay has to be enabled, have tried without it as well with no difference. Since it is loaded previously to my custom overlay it should be overwritten anyway, so shouldn't cause trouble? Nov 13 10:33:55 that is only true if your overlay is modified to be caoe-universal-compatible Nov 13 10:34:05 in general cape-universal conflicts with basically everything otherwise Nov 13 10:34:26 since it occupies all pins Nov 13 10:35:22 if pin conflicts are causing your problems then you'll find errors about that in the kernel log Nov 13 10:35:38 https://pastebin.com/m4SXss3u Nov 13 10:35:39 also, show-pins will show the pins to be occupied (and by what they are occupied) Nov 13 10:36:17 https://pastebin.com/yWLnaMNt Nov 13 10:36:33 oh your overlay does have the necessary entries to be cape-universal-compatible Nov 13 10:36:49 (that's the purpose of fragment@1 ) Nov 13 10:37:07 kernel log is fully printed on the serial line at startup right? Nov 13 10:37:29 not normally no, but you can dump it at runtime e.g. with journalctl -k Nov 13 10:38:15 -kb I mean (the -b probably doesn't have any impact on the bbb since persistent journal is disabled by default, but it's a good habit to include it anyway if you're only interested in the current boot) Nov 13 10:40:46 also it's hard to check pinmux when it's just a bunch of magic hex values, consider using the pinmux macros/constants instead (see the pinmux declarations in https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/BB-BONE-LCD7-01-00A3.dts for example) Nov 13 10:41:28 I don't see anything obviously wrong, except that I'm pretty sure you'll need the uio-pruss overlay in addition to this Nov 13 10:42:10 since the base dt is not setup for uio-pruss by default anymore, so status = "okay"; will not suffice Nov 13 10:42:44 AM335X-PRU-UIO-00A0.dtbo will correctly set up the DT for uio-pruss use Nov 13 11:53:36 hi zmatt, can't seem to find anything worth noticing in the kernel logs, going to try the github toolbox you proposed earlier, i'll keep you posted. Thanks already! Nov 13 11:54:00 rens: like I said, I'm almost certain it's not working because the uio-pruss overlay needs to be enabled Nov 13 11:54:29 i.e. make sure uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo is uncommented in /boot/uEnv.txt Nov 13 11:56:47 i've rebooted already with that one uncommented, no noticeable change. What I don't understand is that my pinconfig settings seem to be completely ignored, whereas on the serial boot log, it does mention loading my overlay. Nov 13 11:58:14 that is odd indeed, can you share the output of my show-pin script, as well as the kernel log? Nov 13 11:58:20 *show-pins Nov 13 12:03:42 https://pastebin.com/Cq33gDZq Nov 13 12:05:03 https://pastebin.com/wJ3Z5fSC Nov 13 12:12:25 hm, so your overlay was clearly applied (since cape-universal has been disabled for exactly the pins you want to use) but pruss isn't being probed for some reason Nov 13 12:15:12 btw, unrelated: to reduce boot time and get rid of the "uninitialized urandom read" warnings, add this kernel parameter to the "cmdline" variable in /boot/uEnv.txt: rng_core.default_quality=100 Nov 13 12:21:57 rens: can you share the output of: udevadm info /sys/bus/platform/devices/4a300000.pruss Nov 13 12:26:32 output of udevadm info: https://pastebin.com/0vb9aXPy Nov 13 12:30:15 okay so DT has been configured for uio-pruss and enabled, and udev has correctly identified the driver to be used Nov 13 12:30:55 does the uio_pruss module show up in lsmod? Nov 13 12:31:29 yes Nov 13 12:31:38 however, pru_rproc as well Nov 13 12:31:53 that might not be a problem, although it's odd it got loaded Nov 13 12:32:05 oh wait Nov 13 12:32:20 lsmod output: https://pastebin.com/kUU2tfWN Nov 13 12:33:11 check /etc/modprobe.d/ ... I recall I've seen cases where something installed a config file that blacklisted the uio_pruss driver, although I can't remember what or why (also I think then it shouldn't show up in lsmod, but check it anyway) Nov 13 12:34:50 also can you share the output of ls -l /sys/bus/platform/devices/4a300000.pruss/ Nov 13 12:35:26 the only thing there which is related to the pruss, is omap_remoteproc.conf, which contains the following: softdep omap_remoteproc pre: virtio_rpmsg_bus Nov 13 12:35:43 that's not related to pruss Nov 13 12:36:10 in fact I'm pretty sure that's irrelevant for the am335x and only applies to the old omap3-based beagleboards Nov 13 12:37:20 this is all i can find in modprobe.d "btwilink-blacklist.conf omap_remoteproc.conf rtl8723bu-blacklist.conf wl18xx.conf" Nov 13 12:37:29 ok good Nov 13 12:43:50 so far it seems like the driver loads but it fails to probe (yet without error in the kernel log unless I missed it), which seems extremely mysterious to me... or it probed but failed to configure pinmux (without error), which seems even more mysterious Nov 13 12:44:30 the difference between those cases it easy to tell: in the former case there won't be a 'driver' symlink in /sys/bus/platform/devices/4a300000.pruss/ nor an 'uio' subdirectory, nor any /dev/uio* devices Nov 13 12:45:21 I gotto go, but I'll probably drop back in later Nov 13 12:45:38 might be a stupid question, but do I need to add the compatible keyword specific for the "sancloud,am335x-boneenhanced" such as is in the sancloud-bbe-uboot-univ.dts? since it might perhaps explain why it loads but doesn't apply my custom overlay? Nov 13 12:46:04 no, the metadata is ignored Nov 13 12:46:07 and it applies your overlay Nov 13 12:46:34 ok, thanks for the help already! Nov 13 12:47:15 I can see in the show-pins output that it applied fragment@1, and you said it shows up in chosen which means it applied fragment@0 (and u-boot will never apply just a subset of fragments afaik, it'll just fail to boot instead if it encounters a problem) Nov 13 12:48:41 btw you might want to use a bit better label name than "example_pins" :P Nov 13 12:48:53 also, afk Nov 13 14:10:43 Is it possible that the sequence in which the overlays are currently loaded, causes my problem? Currently, the PRU_UIO is loaded after i designate my pins to <&pruss>, thus actually designating it to a non-existing target? Nov 13 14:32:59 zmatt: where are you located? I'm in Middelburg today. (for the next hour or so). Nov 13 14:33:22 on my way to Brussels tonight. Nov 13 14:39:53 jkridner: middelburg? what are you doing in that obscure corner of the netherlands? :D Nov 13 14:40:45 (see private message for my location) Nov 13 14:41:28 enjoying musb interactions with EMI at a customer office Nov 13 14:42:01 ... fun Nov 13 14:47:01 rens__: PRU_UIO does not conflict with your overlay Nov 13 14:47:23 rens__: the only property set by both is status, and both if you set it to 'okay'; Nov 13 14:47:38 zmatt: you say that babble doesn't mean that the musb controller will be hung? Nov 13 14:48:50 jkridner: dunno, lemme check what the musb documentation says about it Nov 13 14:51:30 * jkridner reads https://e2e.ti.com/support/processors/f/791/t/308549?AM335X-USB-babble-interrupt Nov 13 14:51:51 note that the usb spec mandates disabling an usb port (on the usb hub nearest to the offending device) when babble is detected Nov 13 14:52:18 well, we tried the same test with BeagleBone AI and didn't have any disconnection, whereas we do with BeagleBone Black. Nov 13 14:52:43 Also, PCs and other SBCs didn't necessarily show the problem. Nov 13 14:53:01 that just means it's more sensitive to EMI pickup or the babble-detection is overly sensitive Nov 13 14:53:05 I don't know how they wouldn't also incur "babble" based on getting bad data via the EMI. Nov 13 14:53:07 it doesn't mean that the babble is being handled correctly Nov 13 14:53:16 *incorrectly Nov 13 15:01:29 testing whether musb is overly sensitive to babble might be difficult without specialized testing equipment, e.g. you'd need something that can e.g. deliberately present some configurable voltage level on the line during the window where babble is detected, to determine what the threshold is Nov 13 15:02:17 (to be fair it wouldn't be musb that has the blame but rather the phy that's attached to it, which I think is TI's own creation) Nov 13 15:03:51 oh? do you think there is something that could be done system-level (board or external) to reduce this? Nov 13 15:04:26 that depends on whether the problem is 1. that the phy is excessively sensitive, or 2. that the bbb is somehow probe to picking up EMI Nov 13 15:04:40 *prone Nov 13 15:06:10 zmatt: do you know anyone who would be a good consultant on BBB USB issues? Nov 13 15:07:25 no idea Nov 13 15:07:49 btw, the musbmhdrc docs say: Nov 13 15:08:00 "If the bus is still active at the end of a frame then the MUSBMHDRC will assume that the function it is connected to has malfunctioned and will suspend all transactions and generate a babble interrupt." Nov 13 15:08:06 and Nov 13 15:08:42 "The MUSBMHDRC will also automatically end the session if babble is detected." Nov 13 15:08:49 ("end the session" = shut off VBUS) Nov 13 15:08:55 :( Nov 13 15:09:29 k, so, Bin's comment only referred to bringing VBUS and the session back up without performing a full controller reset? Nov 13 15:09:41 no idea Nov 13 15:10:35 note that there's not really much the controller could reasonably do otherwise in reaction to a babble Nov 13 15:10:47 k. off to brussels Nov 13 15:11:17 I guess you could force vbus on and try to reset just the connection, if vbus shutting off is the major problem Nov 13 15:12:09 but I don't know whether the kernel driver will recover when musb gets confused by vbus failing to shut down when it expects to Nov 13 15:12:27 it used to get very confused a long time ago, but I think that's been improved Nov 13 15:12:41 Guest29867: are you reading along? Nov 13 15:13:29 (you may want to pick a different name btw with "/nick desirednamehere" .. but you'll need to pick something that hasn't been claimed by a registered user as "jason" apparently is) Nov 13 15:16:42 the usb2phy also has a whole bunch of registers that allow tweaking of the transmitter and receiver, including calibration overrides, so maybe something can be done to make it less sensitive. those registers are negligibly documented however, so you'd need to find a TI engineer who actually knows the usb2phy Nov 13 15:17:44 @zmatt, do you have a clue on what direction is best to continue looking? I'm a bit in the dark on this one.. I've compared the custom dts file with an existing example (BB-BONE-eMMC1) and can't find any logical differences. Nov 13 15:18:30 rens__: can you show the output of ls -l /sys/bus/platform/devices/4a300000.pruss/ (I asked this earlier but you may have missed it) Nov 13 15:20:42 https://pastebin.com/vr4Z0Zyb Nov 13 15:21:01 uhh, so the driver is actually functional Nov 13 15:21:13 it's just the pinmux that's missing o.O Nov 13 15:22:07 I found it! Nov 13 15:22:53 it is in fact the order in which the overlays are applied! the PRU_UIO overlay changes where the &pruss label points, so your overlay is modifying the wrong node Nov 13 15:23:09 rcn-ee[m]: the pru overlay needs to be applied before cape/custom overlays! Nov 13 15:23:38 or the PRU_UIO overlay needs to be modified so it doesn't change the &pruss label (it really doesn't need to) Nov 13 15:24:50 rens__: hold on, lemme see if I can quickly fix the PRU_UIO overlay Nov 13 15:29:15 zmatt: I want to get two linux services working independently on the BBB. One that uses the PRU core 0 and one that uses core 1. I'm using py-uio and I had a problem where the second service started would call pruss.initialize() and stop the code running on the other core. Here is my attempt to prevent this, but it doesn't seem to be working: https://pastebin.com/raw/vDa0thsz Nov 13 15:30:22 It seems like the second service still thinks the core is halted and calls pruss.initialize() Nov 13 15:32:18 hunter2018[m]: you'll want to make your decision to initialize pruss entirely probably depend on whether both cores are halted Nov 13 15:32:34 you'll still have a race condition though Nov 13 15:33:13 I don't suppose adding a dependency between the two services (and initialize pruss only in the first one) is desirable? Nov 13 15:33:33 m Nov 13 15:34:09 or you could make a one-shot service that only does pruss.initialize() and add that as dependency to the services for the two cores Nov 13 15:35:00 or you could skip pruss.initialize() entirely and just carefully initialize the relevant parts Nov 13 15:35:17 lots of solutions, best one depends a bit on the details of your circumstances Nov 13 15:39:15 Thanks! I think my first solution wasn't working because I was only checking if one core was stopped. I need to check if both are halted. Now it seems to be working. Nov 13 15:39:46 I wonder how likely it is that the race condition will cause a problem. Nov 13 15:40:38 zmatt, where is the order of loading boot overlays determined? Nov 13 15:40:58 We previously had combined both into one service so that we could ensure the order in which they were called, but sometimes we only want to run one service and not the other so having some independence is desirable. Nov 13 15:46:58 rens__: in the bootscript compiled into u-boot Nov 13 15:47:27 rens__: okay, try this: clone https://github.com/mvduin/overlay-utils and in that dir do "make uio-pruss.dtbo" Nov 13 15:48:38 then use that overlay instead of AM335X-PRU-UIO-00A0.dtbo Nov 13 15:50:05 (if you want to compile it as overlay without using my overlay-utils you'll need to manually convert it to the .dts format for an overlay, see https://pastebin.com/b8kZfhRG ) Nov 13 16:03:03 So I'm having a problem where my python script (which runs as a Linux service upon startup) is having the error FileNotFoundError: [Errno 2] No such file or directory: '/dev/uio/pruss/module'. However, if I run it later from the command line it is able to find this file without a problem. Nov 13 16:03:53 Could it be that this file isn't getting setup until after the service is being run? Nov 13 16:04:10 zmatt, the change did not fix my problem, show-pins is still unchanged Nov 13 16:04:38 thanks anyways for the help, i'm trying again tomorrow. Nov 13 16:04:54 huh Nov 13 16:07:49 I'm thinking maybe I need to do something like this: https://superuser.com/a/851966 to fix my problem Nov 13 16:16:08 hunter2018[m]: I'm not sure I'd use SYSTEMD_WANTS in the udev rule but yeah using a dependency on the device would be the elegant fix. as a quick hack you could depend on systemd-udev-settle.service Nov 13 16:16:23 (though using systemd-udev-settle.service slows down boot) Nov 13 17:05:38 zmatt: How would you depend on system-udev-settle.service? Nov 13 17:06:00 Would it just be After=systemd-udev-settle.service Nov 13 17:11:05 Like this: https://pastebin.com/raw/xuuiL1vW Nov 13 17:48:10 Wants= and After= Nov 13 18:55:29 hello Nov 13 18:56:01 is it possible to upload the arducopter code to beaglebone AI? Nov 13 18:57:57 software is not really the problem, though it'll probably need some configuration changes. the bigger issue is that you'd need a device tree correctly setup for the external hardware you want to use (which is currently still a difficult process compared to previous beaglebones, but hopefully this will get easier eventually) Nov 13 19:00:14 I also don't know the degree of cape compatibility between the AI and previous beaglebones Nov 14 02:59:54 Has anyone attempted to get keras on their BBB? **** ENDING LOGGING AT Thu Nov 14 02:59:58 2019