01:12 <set_> Whelp. scons built the lib. Finally.

01:12 <set_> it took everything out of me and now you know.

02:55 <set_> Sunday-Funday was short lived. I am sorry I am not more technical. I am working on it.

12:13 <set_> Well...Sunday-Funday came and went. Monday is here and time to party!

12:14 <set_> Have fun! I am off to regular mow and go.

12:14 <set_> Blah.

17:48 <lromor> Hi

17:51 <lromor> I have a problem with a beaglebone green. I've flashed the latest console version of debian for the am335x, successfully booted, after the fresh install, I can query the gpios with: config-pin -q P9.18 and that returns a value. I can also see that the pinmux devices are correctly enumerated inside /sys/devices/platform/ocp with all the PX_XX pins.

17:51 <lromor> After doing an apt-update && apt upgrade the config-pin stops working and it returns: ERROR: open() for /sys/devices/platform/ocp/ocp:P9_18_pinmux/state failed, No such file or directory.

18:05 <zmatt> hmm

18:05 <zmatt> green or green wireless?

18:08 <lromor> Fixed! Sorry:)

18:08 <zmatt> what was it?

18:08 <lromor> sudo apt install bb-u-boot-am335x-evm

18:08 <lromor> sudo /opt/u-boot/bb-u-boot-am335x-evm/install-mmcblk0.sh

18:08 <lromor> sudo /opt/u-boot/bb-u-boot-am335x-evm/install-mmcblk1.sh

18:08 <zmatt> ah, updating u-boot

18:08 <lromor> yeah

18:09 <lromor> where is u-boot stored?

18:09 <lromor> I thought it would be loaded directly from the SD

18:09 <zmatt> bootrom can load it from either eMMC or uSD, but prefers to load it from eMMC

18:10 <lromor> ah I see, so the weird thing is that it was loading the OS via the SD (the root / was on the SD card), but somehow the boot was done via eMMC?

18:10 <zmatt> so I'd generally recommend to either flash to eMMC or wipe eMMC if you intend to continue booting from SD card for some reason

18:10 <lromor> and why updating the uboot would have fixed it?

18:10 <zmatt> yes, how bootrom finds u-boot has little to nothing to do with how u-boot finds a system to boot

18:10 <lromor> I see, I'll do it

18:11 <zmatt> u-boot prefers to boot from SD card over booting from eMMC

18:12 <lromor> ahnn, that explains, so there's this "bootrom" that loads some u-boot code, preferably from the eMMC, the old-uboot then finds a system to boot first on the SD card

18:12 <zmatt> but that can unfortunately lead to a situation where an older u-boot on eMMC is used to boot a newer linux system on SD card, and subtle incompatibility between them resulting in weird issues

18:12 <lromor> is that the explanation?

18:12 <zmatt> yep... bootrom is what's baked into the SoC itself

18:13 <lromor> yes, perfect. One last question, why the uboot takes over the system-to-boot device tree overlays?

18:13 <zmatt> you mean why overlays are applied by u-boot instead of by the kernel like it used to be in ancient times?

18:13 <lromor> yes

18:14 <zmatt> kernel overlays have never been accepted by mainline and have always been buggy... basically too many drivers assume that DT cannot change ever, at all

18:15 <lromor> ah I see, so the DT is defined once, by uboot and passed as a kernel parameter or something?

18:15 <lromor> in ancient times I remember you could modify them in realtime.

18:16 <zmatt> u-boot has always been responsible for loading the DT, applying certain changes (even before overlays) and passing it to the kernel

18:17 <zmatt> dunno how it's passed exactly, it just points the kernel to where it's loaded in ram (similar to how it points the kernel to where the initramfs is loaded, when that's used)

18:17 <zmatt> in theory runtime overlays are still possible, but like I said they're buggy... especially unloading overlays has always been a recipe for kernel panics

18:17 <zmatt> and support may be dropped entirely

18:18 <zmatt> cape-universal (aka the universal overlay, the thing you configure using config-pin) has also reduced the need for runtime overlays

18:21 <lromor> I see. Do you know by chance the difference between /bbb-uEnv.txt and /boot/uEnv.txt?

18:22 <zmatt> I think /bbb-Env.txt is some ancient cruft to try to make the system bootable by truly ancient u-boot versions

18:23 <zmatt> though like the first line says it would need to be renamed to /uEnv.txt for that... you can safely ignore (or remove) that file

18:24 <zmatt> /boot/uEnv.txt is the actual config file for u-boot

18:24 <lromor> I see. But where is the u-boot stored? MBR?

18:24 <lromor> (very last question)

18:24 <zmatt> in the space between the partition table and the root filesystem partition

18:24 <lromor> perfect. How can I repay you for your time?

18:25 <lromor> other than saying thank you!

18:26 <zmatt> specifically u-boot consists of two parts: the first stage (SPL) with a special header prepended is located starting at sector 256, while the main u-boot.img is located starting at sector 768

18:27 <zmatt> this is done because bootrom will load the executable into internal SRAM which limits the size of the executable to 109K iirc, and u-boot is unable to fit its fat ass into that space hence needs a separate stage to initialize the ddr3 memory controller to have the memory available to be able to load u-boot

18:28 <zmatt> thanks will do!

18:30 <lromor> <3