**** BEGIN LOGGING AT Mon Jan 17 02:59:57 2022 Jan 17 15:04:17 Hi All, How would one modify u-boot so it doesn't load the am335x-pocketbeagle.dtb file? I see the findfdt script, but not where in the u-boot it is instantiated. Jan 17 15:35:01 Konsgn: you can just override the dtb in /boot/uEnv.txt Jan 17 15:35:37 dtb=my-custom-board.dtb Jan 17 15:37:50 and findfdt is invoked from bootcmd Jan 17 15:49:55 gotcha, if the dtb is invalid, would it fall back to the eeprom detected one? Jan 17 15:50:54 nope Jan 17 15:51:47 hmmm. alright then. This yocto based tuild seems to be doing something different. Jan 17 15:52:06 oh yeah I don't know anything about yocto, I was assuming rcn's u-boot Jan 17 15:53:36 Konsgn, yocto is probally using mainline u-boot.. which really doesn't have a *dtb overide, just rename your version as the dfault.. Jan 17 15:53:52 that sounds awful Jan 17 15:54:20 patching u-boot sounds saner Jan 17 15:54:36 exactly, i enjoy making u-boot follow our directions.. Jan 17 15:54:57 or even just patching a new default dtb into u-boot Jan 17 15:55:47 better than risking confusion between the normal am335x-pocketbeagle.dtb and a customized am335x-pocketbeagle.dtb Jan 17 15:56:44 Konsgn, one option, configure yocto to use this branch and tree.. https://github.com/beagleboard/u-boot/tree/v2021.10-bbb.io-am335x Jan 17 15:57:24 Wierd, the bbb-meta layer seems to have at least the eeprom detection mechanisms for determining board type from storage. Jan 17 15:57:35 Konsgn, u-boot does.. Jan 17 15:58:35 so that's a default u-boot feature, interesting. I was seeing that functionality in ti/am335x/board.c Jan 17 15:58:55 https://github.com/u-boot/u-boot/blob/master/include/configs/am335x_evm.h#L124-L148 Jan 17 15:59:48 would that script override a declared fdtfile in the uEnv.txt file? Jan 17 16:00:20 I think that would explain what I was seeing Jan 17 16:00:48 problem is, "run findfdt" is run early and set's fdtfile... however fdtfile would be something you could define in uEnv.txt Jan 17 16:03:14 hmm, side question, Can i just put whatever I want in the "compatible" declaration of the root node of the custom dts file instead of ti,pocketbeagle and others? Jan 17 16:03:36 Konsgn: typically you'd add a custom entry in front Jan 17 16:03:48 in the list Jan 17 16:04:39 as usual with compatible-strings they go from most specific to least specific Jan 17 16:05:38 Gotcha, Thank you!.. does it do anything? i understand calling out peripherals to get the right driver, but is that relevant for the root node too? Jan 17 16:05:40 not sure what exactly might test the board's compatible-string, but if your board embeds a pocketbeagle or is based on one you'll probably want to keep the existing ones in addition to your custom one Jan 17 16:06:37 not afaik no, but like... it there's code that needs to apply some board-specific hack, then it'll probably make that decision based on the root node's compatible-string Jan 17 16:06:43 *if there's code Jan 17 16:06:55 Alright, Thank you! Jan 17 16:07:35 I personally don't bother overriding the root node's compatible-string Jan 17 16:17:50 Does anyone know or have an article I can look at that explains how to do the following in C  the  actions of config-pin for example config-pin P9_18 spi, config-pin P9_17 spi_cs, config-pin P9_22 spi_sclk. Jan 17 16:18:27 Angel_Sosa: I do have a python version: https://pastebin.com/MKtWJ8G8 Jan 17 16:19:02 it's basically just writing the desired pinmux state to the appropriate sysfs attribute (open() + write() + close()) Jan 17 16:19:30 with the main annoyance being that the exact path is kernel version dependent Jan 17 16:19:43 hence my use of glob Jan 17 16:20:39 Is there a C library that interfaces with the BeagleBone Black like in Python? Jan 17 16:21:04 I mean, what I linked isn't a library, it's a tiny snippet of code Jan 17 16:22:51 generally speaking I wouldn't recommend replicating the work of config-pin in application code, it's better to just do one-time setup during boot before your application code runs, or use an overlay and avoid the need for runtime pin configuration entirely Jan 17 16:23:31 unless you actually need to change pinmux on the fly of course Jan 17 16:24:43 maybe in a shell wrapper before calling the C program? Jan 17 16:25:26 I am looking to develop a dynamic environment and I do appreciate the heads up  but conifig-pin is as an active example of what can be donew from the command line. Python is doing it and Javascript Jan 17 16:26:03 okay, if you want to change things dynamically then just rewrite my snippet of python code as C code Jan 17 16:26:11 So I just want to see if there is a C library an actual "C" ecosystem. What is it Jan 17 16:27:00 config-pin itself is written in C, but I recall glancing at its source code and being horrified Jan 17 16:27:04 I've never seen one, I've always just looked at the Python bindings. Jan 17 16:28:12 but like I said, replicating its functionality is pretty trivial: just use glob() to locate the appropriate sysfs attribute and then write the desired state to it (simply open(), write(), close()) Jan 17 16:29:47 I get what your saying. I am just looking for C examples. I thought conifig-pin bad or not would be an example Jan 17 16:30:27 symlinks to the pinmux-helper devices in sysfs are found in /sys/bus/platform/drivers/bone-pinmux-helper/ ... I don't quite remember what kernel-version-dependent variations exist, currently it's e.g. "ocp:P8_03_pinmux" for P8_03 Jan 17 16:30:54 the variations are really maddening. Jan 17 16:31:53 I'm honestly not 100% sure whether the name actually varies, it's possible just the path varies and I solved that by using the symlinks in /sys/bus/platform/drivers/bone-pinmux-helper/, and just used the very non-specific glob as extra robustness Jan 17 16:32:47 I probably didn't like hardcoding the ocp: prefix since pimux-helper devices really don't belong inside the ocp node at all, but that's never going to change because of backwards compatibility anyway Jan 17 16:32:57 They are and I know I am asking trivial question but quality up to date information on foundational is pretty poor when it comes to all of the Beagle boards and Bones this group is all I have for information Jan 17 16:33:18 yup Jan 17 16:36:08 documentation has indeed always been a big problem Jan 17 16:36:15 unfortunately Jan 17 16:37:08 To gain the know how I wouldn't mind getting involved in elevating the documentation Jan 17 16:38:13 It just getting to know who to  communicate with and whoever they are do they need the want the documentation help Jan 17 16:38:30 * SJFriedl and many others would sure be grateful for better doco Jan 17 16:39:29 I can't help you with that, I'm also just a random beaglebone user Jan 17 16:41:16 I work with MircoChip and  some of the other SBC's and the documentation is not as and I am afraid to say as colloquial Jan 17 16:42:03 uhh I can't parse that sentence Jan 17 16:42:16 Zmatt you are very smart and its obvious you have provided tid bits of information for me and thanks Jan 17 16:44:27 colloquial meaning the information is kept local to  the person that knows the information. The information is not generally publicly available Jan 17 16:44:57 that's not what that word means Jan 17 16:46:12 perhaps you meant "confidential" instead, but I still don't know what you were trying to say Jan 17 16:46:44 confidential / proprietary / undocumented Jan 17 16:55:34 Information known by one or a group and is local access only. Proprietary to an individual would be  the type of application I used for the word. A slang is known to a group or a person so is information is specific in its origin and access Jan 17 16:58:09 ??? Jan 17 16:58:11 That's why this group exists.  How else would the experience each of you have would be shared Jan 17 16:58:52 oh you're saying that your experience with other SBCs is that people don't really share information? Jan 17 16:59:36 (I'm really just guessing here what you're trying to say, I'm having a lot of trouble understanding you) Jan 17 17:04:04 Really never mind. All I was doing today is looking for C code examples I could view? That I can use to program the BeagleBone at a pure "C" level and not have to venture out of the C ecosystem.  So let me ask the group and as straight forward as possible again is there a C api available that I can use. If not I will look at Python and Javascript Jan 17 17:04:04 to convert to see. Jan 17 17:04:41 thats to "C" not see Jan 17 17:05:14 I've never seen one of those libraries but would sure love one. Jan 17 17:05:55 There just isn't that kind of ecosystem as far as I can tell: it's mostly built around Python or node.js, and even if you found simple pinmux bindings - which seems straightforward enough - you'd still need next-level hardware support Jan 17 17:06:28 such as talking to an LCD or a temp sensor or a servo driver or whatever. These are commonly provided in Python (Adafruit is very active in this). Jan 17 17:15:25 Hmm, I'm using Python and Adafruit_BBIO, and when I try to change the I/O mode of P9_12, it works fine as an output, but for input it fails w/ a device-not-found error Jan 17 17:15:53 P9_12 is GPIO_60, and many other /sys/devices/platform/ocp/ocp:P9_*_pinmux exist, but not P9_12 Jan 17 17:21:42 #!/usr/bin/python3 Jan 17 17:21:43 import Adafruit_BBIO.GPIO as GPIO Jan 17 17:21:43 GPIO.setup("P9_12", GPIO.IN, pull_up_down = GPIO.PUD_UP) Jan 17 17:22:31 /sys/devices/platform/ocp/ocp:*_pinmux is for pin configuration and has nothing to do with gpio Jan 17 17:22:51 running strace on the code shows that it's involved. Jan 17 17:23:01 .... crap, let me grab popcorn. Jan 17 17:24:17 well that's Adafruit_BBIO's problem :P but normally P9.12 should be reconfigurable though, if it's not then that would suggest the pin is in use by something, such as a cape Jan 17 17:25:09 check what my show-pins utility ( https://github.com/mvduin/bbb-pin-utils/blob/master/show-pins ) has to say about the pin Jan 17 17:25:14 ehh Jan 17 17:25:23 https://github.com/mvduin/bbb-pin-utils/#show-pins Jan 17 17:25:28 that was the link I meant to give Jan 17 17:26:47 That's a handy tool Jan 17 17:27:36 Hmm, does this suggest it's used by Bluetooth? Jan 17 17:27:37 P9.12 30 fast up 7 gpio 1.28 you're using a beaglebone green wireless? Jan 17 17:27:53 yup +1 to making a device tree overlay. outside of being a bit tricky to debug, it's pretty straight forward how to declare to the linux kernel that you are using x pin for y peripheral and have that driver loaded into the devicetree. Jan 17 17:27:57 looks like green wireless.. Jan 17 17:28:01 yes that's me. Jan 17 17:28:20 I haven't yet disabled Bluetooth like I usually do on this one. Jan 17 17:28:22 SJFriedl: show-pins actually has a separate green-wireless branch: https://github.com/mvduin/bbb-pin-utils/tree/green-wireless#show-pins Jan 17 17:28:23 that explains it I think Jan 17 17:28:52 and yeah, my condolences, the green-wireless hogs a bunch of expansion header pins because it's been misdesigned Jan 17 17:29:09 awesome. Jan 17 17:29:10 (while leaving the pins that were freed up by removing ethernet mostly unused) Jan 17 17:29:34 I have used this in a few projects and it's been mostly ok, I must have not used that particular i/O pin before. Jan 17 17:29:52 P9.12 is never available unless wifi/bt is completely disabled Jan 17 17:30:01 SJFriedl, with tricks, you can get a few of hte pins back.. (switch the WiFi from 4bit to 1bit..) and disable ble if your not using it. Jan 17 17:30:19 I only need a few pins, there are plenty for me. I just chose... poorly :-) Jan 17 17:30:26 disabling bluetooth actually doesn't free up anything I think Jan 17 17:30:45 I'm disabling it for security reasons, and I can always pick a different pin. I only need a couple. Jan 17 17:31:03 SJFriedl: overview of pin differences: https://pastebin.com/Fi8Vh0n5 Jan 17 17:31:23 SJFriedl, just remove the BLE firmware.. it wont' work. ;) Jan 17 17:31:30 oh never mind, bluetooth does use pins Jan 17 17:31:53 basically the same ones as hdmi audio on the BBB (+ one more pin, P9.30) Jan 17 17:31:53 is there any reason I would prefer the BBGW instead of BBBW ? Only thing I care about is wifi. Jan 17 17:32:24 these are for small industrial control purposes but I don't use them quite enough to get really good at them. Jan 17 17:32:36 The BBBW came out mostly because of the pin messup of BBGW... Jan 17 17:32:57 my advice on the BBGW would generally be: don't Jan 17 17:33:20 that's super helpful information; I'll order a bunch of them so I have them in stock. Jan 17 17:33:38 and thankfully Mouser has them in stock. Jan 17 17:33:49 the bbgw also has the mcsasp wired to the ble... so in theory (it was shown to work once) ble audio... Jan 17 17:34:15 Understand some need that, I don't. Jan 17 17:34:27 no one's needed it. ;) Jan 17 17:34:28 you can use software decoding as alternative anyway Jan 17 17:36:07 SJFriedl: anyway, if you install the green-wireless version of my show-pins script, it'll mention BBGW-specific pin usage in the description column Jan 17 17:37:22 SJFriedl, Mark posed a nice guide of the pins used by the inteface.. https://elinux.org/EBC_Exercise_10b_Green_Wireless_Pins_Used Jan 17 17:37:50 zmatt, this was helpful, this one seems to be used by wifi so I can't very well use that. Jan 17 17:38:40 I either went through this two years ago when I built the first thing, or just happened to have chosen available pins by accident. Jan 17 17:38:51 it's an inexcusable embarrassment that seed doesn't highlight this issue in the pin overviews at https://wiki.seeedstudio.com/BeagleBone_Green_Wireless/ Jan 17 17:39:17 I guess "WTF?" would be in order? :-) Jan 17 17:40:00 the only thing worse than no documentation is wrong documentation Jan 17 17:41:46 I need to either do this *more* (where I'd get good at it) or *less* (where I wouldn't trip over these kinds of things) :-) Jan 17 17:42:15 rcn-ee: it's not correct though, P8.14 (wifi enable) and P9.12 (bluetooth enable) are in use whenever the level shifter is enabled, regardless of whether you have any need for wifi or bluetooth respectively Jan 17 17:43:24 the only way to recover them is by deasserting the I/O enable (P8.26) Jan 17 17:43:51 (which obviously means losing both wifi and bluetooth) Jan 17 17:44:44 and P9.30 is part of the audio interface (if it's declared as gpio, that's a DT mistake) Jan 17 17:46:55 should I be concerned that the current that the latest IoT image is almost two years old? Jan 17 17:47:44 SJFriedl, https://forum.beagleboard.org/tag/bbbio_debian Jan 17 17:48:18 These are take-your-chances snapshots? Jan 17 17:48:44 I'm looking for smooth-ride rather than bleeding-edge Jan 17 17:48:51 so far I've seen no reports of spontaneous combustion ;) Jan 17 17:48:57 generally, how would I take a root filesystem on an existing beagle and tar it up to make a backup and put the same image on another system Jan 17 17:49:05 SJFriedl, then choose Buster.. Jan 17 17:49:11 can I just tar it up and leave junk in /proc and /dev Jan 17 17:49:15 Yah, I'm using Buster. Jan 17 17:49:32 hays, you can certainly omit /proc Jan 17 17:49:39 but keep /dev I think Jan 17 17:49:40 hays: making a tarball of a root filesystem is very delicate Jan 17 17:49:42 SJFriedl, Buster is the same base as the 2 year old release, just more updates.. Jan 17 17:49:49 don't keep any mounted filesystem Jan 17 17:49:53 Bullseye is v5.10.x-ti with a big rewrite.. Jan 17 17:50:26 hays: I know there's a script to turn the eMMC contents into a flasher SD card Jan 17 17:51:21 hays, https://github.com/rcn-ee/repos/blob/master/bb-beagle-flasher/suite/bullseye/debian/beagle-flasher#L263 Jan 17 17:52:36 (if you ever do use something like tar to pack or unpack a root filesystem, be sure to test whether ping still works for non-root users :) Jan 17 17:57:26 just ordered three BBBW to keep them around. Jan 17 18:01:38 rcn-ee: oh ew, why is ping setuid root on the buster-iot image? it's not on any other debian system I have (including our beaglebones) Jan 17 18:01:48 and it's fixed if I update/reinstall iputils-ping via apt Jan 17 18:02:20 zmatt, oh it was set years ago.. can we finally drop that hack? Jan 17 18:02:30 rcn-ee: dunno why you had it in the first place Jan 17 18:03:00 unless you made the mistake of tarballing a rootfs without the necessary flags :) Jan 17 18:03:19 6 years ago... https://github.com/RobertCNelson/omap-image-builder/commit/885864baa1003779794d83db4c5d3850f2d00796 Jan 17 18:03:28 we could nuke it.. Jan 17 18:03:54 "capabilities does not survive tar" ... that's what I meant with missing the right flags Jan 17 18:04:49 for tarring a rootfs I use --numeric-owner --acls --xattrs Jan 17 18:05:19 image is tar'ed by: sudo tar cvf ${export_filename}.tar ./${export_filename} Jan 17 18:05:28 for untar I use --numeric-owner --acls --xattrs-include='*' Jan 17 18:06:07 for untar: tar --numeric-owner --preserve-permissions --verbose -xf "${DIR}/${ROOTFS}" -C ${TEMPDIR}/disk/ Jan 17 18:06:55 that indeed does not suffice for ping to survive intact Jan 17 18:07:02 it's not the only thing either tohugh Jan 17 18:07:04 *though Jan 17 18:07:07 wow, no kidding BBGW uses a lot of the I/O pin. I'd have had a miserable time. Jan 17 18:07:25 thank you Jan 17 18:07:38 SJFriedl: yep, and totally unnecessary... the pins that are freed up by removing ethernet contains _exactly_ the functionality needed for the wifi/bluetooth chip Jan 17 18:08:21 but they left those unused (and unusable for other purposes) while pointlessly stealing a whole bunch of expansion header pins Jan 17 18:08:28 That seems obvious enough that *I* could have figured that out, and I'm an amateur. Jan 17 18:09:48 maybe they were thinking "We'll eventually add in Ethernet as well"? Jan 17 18:10:13 rcn-ee: the fact that specifying --xattrs when untarring is not sufficient to actually preserve capabilities is highly non-obvious, it's something I ran into too Jan 17 18:10:21 SJFriedl: no they used a few of the pins Jan 17 18:10:48 ugh. so just bad design with no "I guess I can see their point" factor? Jan 17 18:10:57 correct Jan 17 18:11:01 ugh. Jan 17 18:11:24 rcn-ee: I didn't include --preserve-permissions since it's the default for root Jan 17 18:12:09 and I used --numeric-owner to avoid any risks of mismatching uids/gids between the host and target systems Jan 17 18:12:31 though that depends on how the rootfs is made I guess Jan 17 18:13:35 updated https://github.com/beagleboard/image-builder/commit/7e14f14c5fd9f5d293408e1dc6bac7a472315113 Jan 17 18:14:41 shouldn't be tweaking code, after tooth surgery... need to swap that commit.. Jan 17 18:15:03 live it up a bit :-) Jan 17 18:15:04 not the time to bite into this code? ;-) Jan 17 18:16:29 defintelly not.. Jan 17 18:18:31 okay all pushed.. https://github.com/beagleboard/image-builder/commits/master Jan 17 18:35:21 Hey! Is there a reason the Bullseye images don't have CONFIG_UIO_PRUSS set? Jan 17 18:35:34 I'm trying to run some older code and don't want to port it to rproc, which seems to be quite a pain Jan 17 18:36:01 the trivial changes needed to make uio-pruss work probably haven't been forward-ported yet Jan 17 18:36:24 the mainline uio-pruss doesn't include am335x support Jan 17 18:36:29 ahhh. :( Jan 17 18:36:45 I've been meaning to look at this, but haven't gotten around to it Jan 17 18:37:02 Which image should I be running then? I'm running into that CDC-ECM issue on macOS (which I don't believe is intentional breakage on the part of Apple, so I filed a feedback under FB9848616) Jan 17 18:37:15 (since imho uio is superior to remoteproc) Jan 17 18:37:36 the latest buster-testing image presumably fixes that Jan 17 18:37:54 or you can use bullseye with a 4.19-ti kernel Jan 17 18:38:03 I'm (partly) trying to port https://www.pdp8online.com/mfm/ / https://github.com/dgesswein/mfm to a newer image, since the image he's providing still requires that unsigned RNDIS driver even on Windows Jan 17 18:38:27 but yeah, it's UIO and pasm based Jan 17 18:38:58 I think I got most of the code converted to clpru, but now I have to figure out how to use the linker. There isn't as much documentation as I wish... the TI stuff isn't the most user friendly Jan 17 18:39:36 I'm fine running buster-testing; Jan 17 18:39:44 but... where should I be getting the image from? Jan 17 18:40:07 https://rcn-ee.net/rootfs/bb.org/testing/2022-01-01/buster-iot/ — I guess? Jan 17 18:40:51 rcn-ee: what do you recommend for buster? (with cdc-ncm instead of cdc-ecm) Jan 17 18:41:10 (re the cdc-ecm problem, feel free to file another bug with Apple, more duplicate bugs helps) Jan 17 18:41:22 (I can see that the Apple driver loads but then crashes for some reason) Jan 17 18:41:27 balrog: of course connecting via ethernet would dodge the issue Jan 17 18:41:42 zmatt: yeah I'm doing that anyway, but I don't like running an image *that* old :) Jan 17 18:42:03 like I said, you can also just downgrade the kernel on bullseye Jan 17 18:43:20 I'll try that first :) Jan 17 18:43:29 I'm actually running bullseye with a 4.14 kernel on our development beaglebone since I haven't gotten around to forward-porting our kernel patches Jan 17 18:43:37 which kernel package is the right one? Jan 17 18:43:45 bbb.io-kernel-4.19-ti or bbb.io-kernel-4.19-ti-am335x? Jan 17 18:45:49 I'm unfamiliar with rcn's kernel metapackages, they're quite new Jan 17 18:46:41 looks like they pull in the same kernel but the -am335x one has additional 'Recommends' dependencies on the sgx modules and u-boot Jan 17 18:48:17 hmm do I need to get anything special to get /dev/uio stuff to show up? Jan 17 18:48:34 zmatt, Mac doesn't like ecm anymore, everything should be ncm on usb1.. Jan 17 18:48:44 rcn-ee: yes I know, that's why I asked Jan 17 18:48:55 I think ecm is still default on the released image Jan 17 18:48:58 rcn-ee: yeah I know, I'm saying I think it's an Apple bug so I reported it, I can see the driver attempting to load and crashing in the Mac logs Jan 17 18:49:03 so we changed the default 2 years ago... Jan 17 18:49:24 rcn-ee: I also filed a separate bug report asking Apple to implement RNDIS, but I'm not holding my breath Jan 17 18:49:49 they're not going to, RNDIS is microsoft-proprietary Jan 17 18:50:11 just like microsoft is probably never going to care about or implement actual standards Jan 17 18:50:26 Apr 9, 2020 that was our change... any image before that assumes ecm... everything after is ncm.. Jan 17 18:50:28 It is and it isn't — Microsoft has documented it rather well. It's a huge annoyance because many Android phones only support RNDIS and don't support ECM/NCM for tethering, so people end up using HoRNDIS which at this point I want to kill off Jan 17 18:50:35 (I helped maintain it for a bit) Jan 17 18:50:55 balrog: anyway, uio-pruss needs to be enabled through an overlay in /boot/uEnv.txt Jan 17 18:50:56 (I could port it to a Driver Extension but I don't want to) Jan 17 18:51:23 zmatt: does the overlay have to be before the cmdline? Jan 17 18:51:50 cmdline has nothing to do with overlays Jan 17 18:51:58 balrog, on older images, just do: cd /opt/scripts/ ; git pull Jan 17 18:52:14 only asking because I had already added it at the end of the uEnv.txt and it didn't seem to have any effect Jan 17 18:52:16 that'll update the ecm -> ncm change over... today it's ncm by default. Jan 17 18:52:21 uboot_overlay_pru = /lib/firmware/AM335X-PRU-UIO-00A0.dtbo Jan 17 18:52:27 rcn-ee: I see Jan 17 18:52:57 balrog, do you have serial log over j1? if so we can see why it failed.. Jan 17 18:53:45 balrog: I haven't tried the bullseye image yet so I don't know what if anything has changed in u-boot... Jan 17 18:54:04 maybe I should just roll back then :) Jan 17 18:54:19 balrog: but, did you test with a 4.19 kernel? Jan 17 18:54:26 I'm booted with a 4.19 kernel now Jan 17 18:54:37 the correct modules for uio load when I modprobe them, but I think there's some dtb stuff going on Jan 17 18:54:50 balrog: you shouldn't have to modprobe them Jan 17 18:55:04 yeah, that's what I expected -- they should load based on the overlay Jan 17 18:55:15 modules for drivers load automatically, if they didn't then manually modprobing them will accomplish nothing Jan 17 18:55:34 rcn-ee: is uboot_overlay_pru no longer supported? Jan 17 18:55:34 do I need to rebuild the initrd after updating uEnv.txt? Jan 17 18:55:40 I guess you can use a random other overlay variable Jan 17 18:55:48 no that has nothing to do with each other Jan 17 18:55:51 nope, ok Jan 17 18:56:07 that option should still exist.. Jan 17 18:56:25 I don't have serial debug set up but I could with a bit of effort Jan 17 18:57:28 serial debug for what exactly? for the usb thing? can't you just login via ethernet and pull the kernel log Jan 17 18:57:50 balrog, if everything is new enough, this should print out what loaded.. (use pastebin..) sudo /opt/scripts/tools/version.sh Jan 17 18:58:41 rcn-ee: /opt/scripts doesn't exist. note that I'm running this image https://rcn-ee.net/rootfs/debian-armhf/2022-01-15/bone-debian-11.2-iot-armhf-2022-01-15-4gb.img.xz Jan 17 18:59:02 balrog, ah! sudo beagle-version ;) Jan 17 18:59:20 https://gist.github.com/d235j/2496a56585ac50ca94b2da61e768002c Jan 17 19:00:13 So u-boot on eMMC might be breaking it... remove the "spaces" in uboot_overlay_pru = /lib/firmware/AM335X-PRU-UIO-00A0.dtbo not sure how smart u-boot is.. Jan 17 19:01:00 you can update u-boot on the emmc via: sudo /opt/u-boot/bb-u-boot-am335x-evm/install.sh Jan 17 19:01:10 or just wipe eMMC with sudo blkdiscard /dev/mmcblk1 Jan 17 19:01:18 if there's nothing on it you care about Jan 17 19:02:32 I had previously flashed the board with another image, hmm lemme check Jan 17 19:02:46 pretty sure with https://debian.beagleboard.org/images/bone-eMMC-flasher-debian-10.3-iot-armhf-2020-04-06-4gb.img.xz Jan 17 19:03:12 anyway taking out the space and retrying Jan 17 19:03:55 question: is there any good documentation on moving from pasm to clpru? is it even recommended? Jan 17 19:04:18 rcn-ee: yes, taking out the spaces did it. Jan 17 19:04:46 balrog, awesome! yeah u-boot enviroment import is pretty basic.. Jan 17 19:06:08 so I'm probably good at least for uio Jan 17 19:07:02 any ideas about the PRU compiler/assembler stuff? Jan 17 19:07:21 I see that pasm is open source and it doesn't seem that clpru is, but I don't know if that really matters Jan 17 19:07:54 i know ti doesn't really want to support pru anymore.. Jan 17 19:08:29 they put giant PRU subsystems on all of their latest SoCs though Jan 17 19:08:39 balrog: I personally prefer pasm over clpru Jan 17 19:09:26 zmatt, when asking for support, we threatened that zmatt would figure it out, so just release the details.. Jan 17 19:09:31 lol Jan 17 19:09:45 rcn-ee: I kinda still want to make uio-eve or something ;) Jan 17 19:09:55 zmatt: I see there's also a gcc port too, which I suppose comes with gas? Jan 17 19:10:04 so eve is more dead... the c7 mma is suppost to replace it.. Jan 17 19:10:22 balrog: gcc doesn't even support the ABI properly Jan 17 19:10:40 this user has done much of the gcc stuff... https://github.com/dinuxbg Jan 17 19:10:58 the "gcc-pru" in Buster and Bullseye is from him.. Jan 17 19:11:00 zmatt: you mean the clpru abi? Jan 17 19:11:17 balrog: PRU EABI yeah Jan 17 19:11:20 right, ok Jan 17 19:11:27 is pasm and supporting libs in Bullseye? Jan 17 19:11:37 pasm doesn't have supporting libs Jan 17 19:11:59 I mean libprussdrv Jan 17 19:12:19 those are separate and not really related things Jan 17 19:12:40 they're trivial to compile anyway Jan 17 19:13:28 fair point Jan 17 19:14:20 instructions for pasm are in the README of my py-uio project: https://github.com/mvduin/py-uio (at the bottom of the uio_pruss section) Jan 17 19:15:17 yeah I have it, was only wondering if there was a package :) Jan 17 19:15:30 no idea, would be nice Jan 17 19:16:18 balrog, so we install, this package: https://git.ti.com/gitweb?p=pru-software-support-package/pru-software-support-package.git;a=summary i don't think TI included pasm in it.. Jan 17 19:16:19 I think it used to be there as `am335x-pru-package` Jan 17 19:16:35 the old am335x_pru_package was a very old fork of ti's project.. Jan 17 19:16:57 ah... Jan 17 19:17:23 rcn-ee: that thing seems to be remoteproc based Jan 17 19:17:28 rcn-ee: the pru support package is just for clpru and remoteproc Jan 17 19:17:29 the old am335x-pru-package is meant for uio Jan 17 19:17:57 exactly... 6.0.1 is rproc only (5.10.x-ti) and 5.9.x seems work form v4.14-ti -> 5.4.x-ti.. Jan 17 19:18:45 is capemgr dead? Jan 17 19:19:04 replaced by u-boot overlays and cape autodetection in u-boot Jan 17 19:19:07 got it Jan 17 19:19:14 balrog, it's not 100% dead... they are still discusising it mainline.. Jan 17 19:19:24 probally for another 10 years... Jan 17 19:20:11 honestly, clpru and remoteproc are kinda dumb, the PRU architecture was never designed to be targeted by a C compiler, and using C/C++ or using remoteproc's rpmsg mechanism destroys the deterministic timing which is PRU's key asset Jan 17 19:20:21 yep Jan 17 19:20:22 At this point, the best supported "capemgr" is in Renesa's ARM mainline tree, he's still actively using it.. and has time to suport it. ;) Jan 17 19:20:25 (I'm not familiar with rpmsg) Jan 17 19:20:46 (but I get the C/C++ part. It would only work with heavy inline asm, and do they even support that?) Jan 17 19:20:52 balrog: rpmsg is basically a kind of socket interface implemented using an extremely convoluted ringbuffer system in DDR3 memory Jan 17 19:20:59 *WHY* Jan 17 19:22:11 inline asm doesn't really help, you'd need to put the timing-critical parts entirely in separate asm code... and that's generally most of the code anyway Jan 17 19:22:36 but I'll be fair, there are some use-cases where C/C++ is fine Jan 17 19:23:29 like, if people need stuff done "within a few microseconds" or something, something that's so trivial for PRU that you can afford to waste undefined amount of time, yet which are too timing-critical for linux userspace Jan 17 19:23:58 and "WHY" is the only correct reaction to rpmsg Jan 17 19:24:22 it's an abomination Jan 17 19:25:42 I looked into how it works because I thought about implementing it in py-uio just for fun and to be able to run most if not all code designed for remoteproc-pru via uio-pruss instead Jan 17 19:26:22 but after seeing how it works, I realized I was a happier person back when I didn't know Jan 17 19:54:10 how do you load an extra dtbo overlay without capemgr Jan 17 19:54:12 ? Jan 17 19:55:18 via one of uboot_overlay_addr4..7 or dtb_overlay ... they're all equivalent but each only accepts one overlay path (I'm not sure why there isn't simply one variable that accepts a list of overlays) Jan 17 19:55:32 but it does require a reboot? Jan 17 19:56:08 yes, runtime loading of overlays is theoretically still supported but it has always been buggy and is deprecated Jan 17 19:56:19 aha, got it Jan 17 19:56:38 basically, there's too much kernel code that was never designed to cope with the DT changing at runtime Jan 17 20:09:16 oof, I see Jan 17 20:18:03 came across this https://github.com/beagleboard/bb.org-overlays/issues/138 Jan 17 20:18:07 (not the bug, just the query) Jan 17 20:49:16 balrog, dtb_overlay was the first variable name i came up with when starting on u-boot overlays, it only exists as i told users to try it.. it's still enabled.. Jan 17 20:50:21 in the order of execution, it's the last one to load.. Jan 17 21:15:41 rcn-ee: got it :) Jan 17 21:15:46 can you set up gpio direction in an overlay? Jan 17 21:30:59 balrog: with a gpio-of-helper yes, see this example in my overlay-utils: https://github.com/mvduin/overlay-utils/blob/master/gpio-demo.dtsi (beware that overlay-utils uses pinmux macros that are different from bb.org-overlays) Jan 17 21:31:32 you'd need to make sure cape-universal is disabled however Jan 17 21:32:12 since there's currently no way to disable individual gpios of cape-universal's gpio-of-helper device Jan 17 21:33:04 or wait... did I write a patch for that? rcn-ee? Jan 17 21:39:21 yeah I did write a 2-line patch for that, and rcn-ee merged it Jan 17 21:41:56 balrog: so with a sufficiently recent kernel it's possible to declare your own gpio-of-helper without being forced to disable cape-universal entirely, you can disable individual gpios in cape-universal Jan 17 21:44:48 e.g. &ocp { cape-universal { P8_03 { status = "disabled"; }; }; }; Jan 17 22:03:20 zmatt: how recent? Jan 17 22:03:30 like, would a "stable" image be recent enough? Jan 17 22:04:58 if you update the kernel to the latest within its series (4.19-ti for current stable images except TIDL images) Jan 17 22:14:51 explicit list of kernel versions that support this: https://pastebin.com/2w2XtJBP Jan 17 22:15:06 of course if you don't need cape-universal then any kernel will do Jan 17 22:15:29 do you need the pins defined in both exclusive-use and in am33xx_pinmux? Jan 17 22:15:34 (well, any -ti or -bone kernel that's not suuuuper ancient I mean) Jan 17 22:15:39 I kinda wish there was a central source of documentation here) Jan 17 22:16:08 https://github.com/dgesswein/mfm/blob/master/mfm/mfm_read-00A0.dts -- what I'm looking at :) Jan 17 22:16:09 exclusive-use is metadata for the overlay manager, and actually ignored by u-boot overlays Jan 17 22:16:14 ahhhh! Jan 17 22:16:33 yeah, these overlays were meant to be run by the overlay manager, but that means it's stuck on an ancient kernel and image Jan 17 22:16:54 all properties at the top level (/) of an overlay are purely metadata Jan 17 22:17:13 also, that overlay is broken Jan 17 22:17:46 it has multiple references to the same pinmux node Jan 17 22:18:10 is there an overlay validator? Jan 17 22:18:29 that would be nice, wouldn't it Jan 17 22:18:52 yeah... Jan 17 22:18:55 given how simple this overlay is, you may want to consider rewriting it using my overlay-utils... using macros instead of magic hex constants will make things a lot more readable Jan 17 22:19:02 plus the overall structure/syntax is nicer Jan 17 22:19:07 yeah, I agree Jan 17 22:19:15 this thing is really the sort of project where it works so no one's touching it Jan 17 22:19:18 no fragment@N or __overlay__ nodes Jan 17 22:20:07 (the "thing" itself is a board that emulates or reads a vintage MFM hard drive) Jan 17 22:21:07 one reason I asked about pasm being packaged... is that it *is* BSD-licensed open source, while the "newer" TI compiler is not Jan 17 22:23:06 note btw that the IN and OUT in the pinmux block is misleading... pinmux nodes have no influence over direction, that's controlled by the peripheral to which the pin is muxed Jan 17 22:23:59 what it actually sets is whether the input receiver is enabled or disabled... if disabled the pin will always appear to be low Jan 17 22:25:15 (as far as I know there's no reason to disable the receiver other than a miniscule amount of power saving, hence the macros in overlay-utils always simply enable the receiver) Jan 17 22:49:46 zmatt: got it, I'll keep you updated :) Jan 17 23:57:29 zmatt: does the state of the receiver affect the pin impedance? Jan 17 23:58:17 seems unlikely Jan 18 00:57:09 zmatt: is overlay-utils packaged? Jan 18 00:57:24 no, seems pointless since it's primarily a set of examples Jan 18 00:57:37 fair Jan 18 00:58:24 and you should be using git for your own overlays anyway :P cloning the git repo makes it easy to merge updates Jan 18 00:58:33 apt ain't gonna do a 3-way merge for you **** ENDING LOGGING AT Tue Jan 18 02:59:56 2022