**** BEGIN LOGGING AT Wed Sep 15 02:59:56 2021 Sep 15 08:55:31 Anyone tried the vanilla kernel v5.15-rc1 on beaglebone black? Mine fails to boot. The v5.14 booted Ok. Any changes known to break things with old uBoot or configs? Sep 15 08:55:55 (kernel configs) Sep 15 08:57:57 Last thing I see in serial logs is loading the kernel and device-tree from tftp-server && the booting kernel print. Nothing after that. Sep 15 17:35:06 hey guys, I am running debian 9.5, kernel 4.14.108-ti-r36, on a beaglebone black rev C. I am trying to figure out how to change the boot configuration of the GPIO pins using boot overlays. I followed the instructions here: https://learn.adafruit.com/introduction-to-the-beaglebone-black-device-tree/compiling-an-overlay Sep 15 17:36:05 was able to compile the file successfully on my host computer, then moved the compiled .dtbo file to /lib/firmware Sep 15 17:37:04 modified the /boot/uEnv.txt file so that "enable_uboot_overlays=1" is uncommented, and all the override capes lines are commented except for one I added under custom cape: Sep 15 17:37:17 dtb_overlay=/lib/firmware/test_dtbo_overlay.dtbo Sep 15 17:38:18 then I downloaded the show-pins utility to verify whether or not it's working. I looked at P9.17, because the example I downloaded I believe is supposed to modify that one's configuration: Sep 15 17:38:19 0x150 0x30 /* spi0_sclk, INPUT_PULLUP | MODE0 */ Sep 15 17:38:32 (I think 0x150 is the P9.17) Sep 15 17:39:24 I'm not sure exactly what to set the second hex value to, I tried 0x10, 0x20, 0x70, and compared the show-pins output of P9.17 in each case, but don't see a difference. Recompiled/adjusted /boot/uEnv.txt and rebooted in between each test Sep 15 17:40:08 I always get: P9.17 / spi boot cs 87 fast rx up 7 gpio 0.05 << hi P9_17 (pinmux_P9_17_default_pin) Sep 15 17:43:27 anyone know what I'm doing wrong? Sep 15 17:45:44 I wasn't able to follow the instructions from the original tutorial on exporting the overlay; I think they're out of date: https://learn.adafruit.com/introduction-to-the-beaglebone-black-device-tree/exporting-and-unexporting-an-overlay because there is no /sys/devices/bone_capemgr.*/slots directory Sep 15 17:46:03 so I did the part where I enabled it in the /boot/uEnv.txt thing instead Sep 15 17:47:28 you're also running a pretty old version of debian ... maybe the instructions are too new? Sep 15 17:49:46 that's an interesting point Sep 15 17:50:05 yeah I wanted to run 10 but the people on my project want to run this one cause they've used it succesfully before Sep 15 17:51:03 and i would guess debian bullseye (11) should have support for the beaglebone black too... Sep 15 17:52:24 I think 11 is a little bit too bleeding edge; I tried it the other day and was having a bunch of issues. Sep 15 17:52:38 but yeah, for now, I'm stuck with 9.5 unless I can show that I can't make it work Sep 15 17:52:44 any ideas how to do the overlay there? Sep 15 17:53:55 sorry, haven't worked much with beagle* lately Sep 15 17:54:28 other's might chime in ... wait a while :) Sep 15 17:57:50 for sure! to summarize for others, having trouble getting boot overlays to work for GPIO pin configurations, on debian 9.5, kernel 4.14.108-ti-r36, mostly following these instructions: https://learn.adafruit.com/introduction-to-the-beaglebone-black-device-tree/exporting-and-unexporting-an-overlay and using show-pins to verify Sep 15 18:13:21 the_person48, do you have a usb-serial adapter plugged into J1? Otherwise u-boot overlays are impossible to debug... Sep 15 18:15:18 I do not Sep 15 18:15:36 Adafruit's spi overlay is buggy, that was written before we found out spi had bug, all pins need to be input for spi to work.. Sep 15 18:15:38 interesting, what does the usb-serial adapter do for uboot overlays? Sep 15 18:15:40 gotcha Sep 15 18:16:01 is there another one that you would suggest instead? Sep 15 18:16:21 the_person48, it allows you to see this: https://gist.github.com/RobertCNelson/4cf3614923fc92a826dca1f611841c0d Sep 15 18:17:17 the_person48, your choice: https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-SPIDEV0-00A0.dts or https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-SPIDEV1-00A0.dts both are installed by default in later images.. Sep 15 18:17:41 yeah I see how that could be helpful Sep 15 18:17:50 and you can't get that with just a regular micro-USB to USB cable? Sep 15 18:18:28 the_person48, no... the USB port serial adapter is created by the Linux Gadget driver... so 10seconds "after" the board booted... Sep 15 18:18:32 the_person48, cable options: https://elinux.org/Beagleboard:BeagleBone_Black_Serial Sep 15 18:18:58 ahhh Sep 15 18:19:40 ok, so I'll try these two example dts files you linked, then if they work, great, and if not will look into getting this cable for further troubleshooting Sep 15 18:19:42 ? Sep 15 18:20:01 if all you want is 'spidev', just flash the latest image: https://rcn-ee.net/rootfs/bb.org/testing/2021-09-01/buster-iot/ and set BB-SPIDEV*.dtbo as one of hte overlays Sep 15 18:20:06 it looks like the links you have are just dts files so I'm guessing you mean for me to use pretty much the same process, just a different file, yeah? Sep 15 18:20:42 well unfortunately I need to try to make it work on 9.5, at least for now Sep 15 18:20:52 this is what my coworkers have requested Sep 15 18:21:08 if I try for a while and show it can't be done or is impratically difficult, then I can argue for a later image Sep 15 18:21:09 the_person48, no, adafruit's dtc directions won't work, we are using a preprocessor.. they are already pre-built, or you can install the "bb-cape-overlays" debian packages Sep 15 18:21:27 the_person48, ps, i'm done with 9.x so no more packages... Sep 15 18:21:35 (that haven't already ben built..) Sep 15 18:21:35 yeah, that's fine Sep 15 18:21:47 ok, I'm still a little confused then Sep 15 18:21:58 so I install the "bb-cape-overlay" package Sep 15 18:21:59 about what? Sep 15 18:22:01 one of the two you linked Sep 15 18:22:12 sudo apt update ; sudo apt install bb-cape-overlay Sep 15 18:22:14 and then that provides a separate way of loading the overlays? Sep 15 18:22:26 "it" provides /lib/firmware/*.dtbo Sep 15 18:22:38 all of these: https://github.com/beagleboard/bb.org-overlays/tree/master/src/arm Sep 15 18:23:10 ok, and then I can try loading some of those using /boot/uEnv.txt method? Sep 15 18:23:15 correct.. Sep 15 18:23:19 ok great Sep 15 18:23:20 will do Sep 15 18:23:25 as long as u-boot isn't ancient.. Sep 15 18:23:44 is there a way to check how old it is? Sep 15 18:24:11 sudo /opt/scripts/tools/version.sh Sep 15 18:25:44 ok, do you want that whole output? Sep 15 18:26:10 also, I updated and tried to apt install bb-cape-overlay but it says it can't find the package Sep 15 18:26:15 maybe I have to clone manually? Sep 15 18:26:41 Hey, has anyone had a bit of trouble with remoteproc messages and storing bytes in memory from a register (SBCO)? I am writing 12 bytes (3 times 4 byte SBCOs, offset by 4 bytes each time) to 0x0000 with a 200 byte offset in order to read data obtained through ASM in the C portion of the code, and that seems to make pru_rpmsg_send break on the 9th Sep 15 18:26:41 the_person48, put it on pastebin so you can share it.. Sep 15 18:26:41 time I do it (times out, "output:id 16 out of range") Sep 15 18:31:17 https://pastebin.com/xzwvdwFy Sep 15 18:31:21 here's the output Sep 15 18:32:13 [ 0.975774] pinctrl-single 44e10800.pinmux: pin PIN84 already requested by ocp:P9_22_pinmux; cannot claim for 48030000.spi Sep 15 18:33:16 so multiple interfering overlays or something like that? Sep 15 18:33:40 the_person48, remove your /boot/uENv.txt dtb_overlay=/lib/firmware/test_dtbo_overlay2.dtbo and run: sudo apt-get update ; sudo apt-get install bb-cape-overlays Sep 15 18:33:42 the_person48: you need to disable cape-universal's pinmux helper for any pin your overlay uses Sep 15 18:34:02 ok, and is that done in /boot/uEnv.txt? or in the actual overlay file? Sep 15 18:34:09 in the overlay Sep 15 18:34:25 his stack is soo old, i don't remember if i backported all the pinremoving... Sep 15 18:34:36 comment out the enable_uboot_cape_universal in /boot/uEnv.txt Sep 15 18:34:37 my overlay-utils has a nice macro for it: https://github.com/mvduin/overlay-utils/blob/master/i2c1.dtsi#L3-L4 Sep 15 18:34:46 or you can disable cape-universal entirely yeah Sep 15 18:35:23 (in which case you can't use config-pin and are forced to do all pinmux setup using one or more overlays) Sep 15 18:35:51 the_person48, do you need anything other then spi? Sep 15 18:35:55 that's ok, I will just disable it for now at least Sep 15 18:36:09 yeah I need to configure a lot of of the pins. I was just trying to get an example working before I expanded it Sep 15 18:36:31 yeah, then just disable it outright, so you don't have to fight it.. Sep 15 18:36:48 Guilherme: your description is rather vague... where exactly is your assembly code writing stuff? have you made sure that that the compiler knows about this and doesn't use that memory itself? Sep 15 18:36:55 ok cool, will do Sep 15 18:37:35 Guilherme: since if you're scribbling onto memory that's used by your C code or any library it uses, then yeah you will break things undoubtedly Sep 15 18:38:37 Yea, I tried to condense it as much as possible and missed on some details. I had a guess that could be it as well, I'm writing to the PRU's own DRAM (or at least trying to) at 0x0200, a 200 byte offset to avoid the heap and stack entirely, however, I didn't find much documentation on that at first Sep 15 18:39:00 So my belief is that indeed I'm writing to portions of memory that are used by my C code Sep 15 18:40:31 there's a few ways you can fix this Sep 15 18:40:34 However, are there any other slightly more elegant ways to transfer about 16 bytes of data as a message? I could return by writing to r14, but from what I found, that is limited to a single word Sep 15 18:40:57 Oh, yea, any way that I could fix this is AOK Sep 15 18:41:50 transfer from assembly code on the pru to C code on the same pru? the other pru? linux code? Sep 15 18:42:15 Oh, from ASM to C code on the same PRU Sep 15 18:43:44 same way you'd do so from C code to C code, have the caller pass a pointer to the location where the callee should put the data Sep 15 18:44:02 ok, commenting enable_uboot_cape_universal seems to have worked! Sep 15 18:44:21 P9.17 is definitely different now Sep 15 18:44:21 P9.17 / spi boot cs 87 fast up 0 spi 0 cs 0 spi@48030000 (spi0_pins_s0) Sep 15 18:45:25 So I could pass a 32 bit pointer through the parameter registers and write to it or would you suggest other way? Sep 15 18:46:33 here's the new output of /opt/scripts/tools/version.sh: https://pastebin.com/Dc5j9trM Sep 15 18:47:32 yeap, spi should work now.. Sep 15 18:47:34 Guilherme: I mean, that's the simplest and most obvious way, unless you have very specific reasons to favor an alternate solution Sep 15 18:48:06 Yea, I don't remember why I wanted to write to an absolute place in memory in the first place, thanks a ton for the help Sep 15 18:48:34 still unable to install bb-cape-overlay though; it says E: Unable to locate package bb-cape-overlay Sep 15 18:48:36 Guilherme: C also supports passing large structs by value, but that actually just uses a pointer behind the scenes Sep 15 18:48:45 the_person48: bb-cape-overlays I think? Sep 15 18:49:39 ah that's working Sep 15 18:50:19 return struct by value I mean Sep 15 18:50:34 (passing large structs uses the stack) Sep 15 18:52:06 actually now that I think of it I'm not sure what the C calling conventions are on PRU, I only use assembly for PRU Sep 15 18:53:59 I used to stick to ASM as well, but with remoteproc, I had to move some stuff to C to adhere to new standards Sep 15 18:54:19 remoteproc sucks, it's slow and bloated Sep 15 18:54:40 ok, so I got bb-cape-overlays installed. Now I'm trying to extend the overlay to set a bunch of the GPIO pins to the modes I want. Is the easiest way to do that just modifying the Adafruit .dts overlay file I already have, or should I be doing something new with the bb-cape-overlays package? Sep 15 18:54:51 Yea, I agree, I've lost quite a bit of performance but we're using the new kernel for other stuff, so I'm min-maxing everywhere I can Sep 15 18:54:59 and any use of it will destroy the deterministic performance that's normally the biggest asset for pru Sep 15 18:55:20 new kernel? how new? Sep 15 18:55:32 by "new" I mean new to us, the TI kernel with Buster (4.19) Sep 15 18:55:39 4.19 supports uio-pruss just fine Sep 15 18:55:58 you can switch between remoteproc-pru and uio-pruss in /boot/uEnv.txt Sep 15 18:56:11 Wasn't remoteproc supposed to be the standard moving forward and UIO would slowly lose support over time? Sep 15 18:56:37 I mean, this is the biggest driving force for any change right now, and that was what I've read on a few blogs and docs Sep 15 18:56:39 well it's a trivial driver to forward-port Sep 15 18:56:59 I see Sep 15 18:57:06 and I personally don't have any intention to switch to remoteproc-pru, it's just objectively worse in almost every way Sep 15 18:57:42 It really is, it's been a pain for the last 3 days for some specific stuff, and some instructions are kinda "borked", such as QBBC Sep 15 18:58:20 I've already helped to forward-port uio-pruss once, I fully intend to do it more as needed Sep 15 18:58:20 You cannot use model #1 for example, which makes defines less "powerful" in a sense Sep 15 18:58:36 ah you're talking about the clpru assembler vs pasm? Sep 15 18:58:45 also that, yes Sep 15 18:58:52 it's more of a tangent to the whole thing Sep 15 18:59:35 it also wouldn't be hard to adapt from using the uio-pruss driver to using the uio-pdrv-genirq driver that's been a part of mainline linux since prehistory and will no doubt be around forever more Sep 15 19:00:02 adding support for that (with DT example) to my py-uio project is still on my to-do list Sep 15 19:00:24 I'm probably going to look into that on saturday as well, seems more promising than remoteproc for the moment being Sep 15 19:00:37 and for any other moment, for that matter Sep 15 19:00:47 for 4.19 you can just switch back to uio-pruss and be done Sep 15 19:01:24 I'm probably gonna do both, thanks for the heads up regarding the whole situation Sep 15 19:01:36 Both as in leave both options open moving forward for other devs Sep 15 19:02:55 it's funny, I've seen other projects that felt pressure to switch from uio-pruss to remoteproc-pru. and then proceeded to use /dev/mem for shared memory.... at which point you've lost all benefits of remoteproc-pru and are just doing what uio-pruss does but way worse Sep 15 19:04:48 Actually, the original project did use shared memory and we moved away from it in this new iteration precisely because of that Sep 15 19:05:10 We didn't really need shared memory initially, but it was a "nice-to-have" in that specific case Sep 15 19:05:50 I mean, remoteproc also uses shared memory, just with an elaborate and inefficient messaging protocol on top of it Sep 15 19:07:12 Yea, it's pretty much a massive "zealous gift wrap" kind of situation right now with rpmsg Sep 15 19:07:51 and remoteproc also always puts the ringbuffers in ddr3 memory, forcing pru to perform reads that have slow and non-deterministic timing Sep 15 19:13:02 I dug into how rpmsg works since I wanted to add support for it to py-uio ( https://github.com/mvduin/py-uio/ ) but learning how it works made me less motivated to implement it :P Sep 15 19:13:59 (so it can currently load ELF executables produced by clpru (in addition to raw pasm binaries) but without support for rpmsg or anything in the resource table) Sep 15 19:20:44 The more I look into rpmsg, the more I start to think this wasn't a good idea Sep 15 19:21:07 very little about remoteproc-pru was a good idea Sep 15 19:23:31 using C on pru also isn't a good idea, the pru instruction set was designed to be programmed by humans in assembly, not to be targeted by a C compiler, which is probably in part why the code output of clpru is so shit (though it cannot excuse all of the dumb things I've seen clpru do) Sep 16 00:58:26 Guest72: Did you see what I typed? Sep 16 00:59:00 I have not got the Native_SDK working yet on the BBAI. I think I am close but faltering so far w/ updates and upgrades. Sep 16 00:59:49 in particular, the cmake --build . , command is beating me b/c of something. I am working w/ the SGX people slowly to wonder and ponder. Sep 16 01:00:10 Then, on to LCD! Yikes. Sep 16 01:14:52 jkridner: I do wonder why TI chose to put lpddr4 on the j721 instead of something with better availability like ddr3 or ddr4... I can't imagine that saving a bit of power consumption on ram is that important in automotive applications **** ENDING LOGGING AT Thu Sep 16 03:00:05 2021