**** BEGIN LOGGING AT Sat Sep 25 02:59:56 2021 Sep 25 10:26:27 hi Sep 25 18:44:04 is the boot order fixed on the beaglebone (depending on a button or jumper) or does the boot rom fallback to other boot entries if one fails? (e.g. eMMC -> SD Card -> ...) Sep 25 19:18:11 vd: default boot device list for bootrom is { eMMC, μSD, uart-xmodem, usb-rndis }. powering on with the S2 button held down (sampled when power-on-reset is released) changes that to { spi-flash, μSD, usb-rndis, uart-xmodem } Sep 25 19:19:04 see https://goo.gl/Jkcg0w#gid=750891223 for details about how bootrom is configured using the strapping options (sysboot0-15 aka lcd_data0-15) Sep 25 19:19:36 separately from that, u-boot also has its own boot device order for finding a linux system to boot Sep 25 19:20:31 I have a jumper on my daughter which forces either eMMC or SD card boot I think, no fallback Sep 25 19:21:56 there's only a single boot mode that includes eMMC and it always has μSD as fallback Sep 25 19:22:29 so your claim is literally impossible Sep 25 19:28:58 zmatt let me check what it does on the schematics Sep 25 19:29:42 probably pulls P8.43 (sysboot2) to ground, same as the S2 button on the beaglebone Sep 25 19:43:49 zmatt: indeed that's it! P8.43 pulled to ground Sep 25 19:44:11 so that jumper is equivalent to having the S3 button pressed all the time? Sep 25 19:44:35 S2* Sep 25 19:45:01 yeah so don't accidently configure that pin as output, in particular make sure video is disabled in /boot/uEnv.txt Sep 25 19:45:43 (unless there's a series resistor (1 kΩ or larger) to limit current) Sep 25 19:57:15 zmatt that pin (LCD_DATA2) is configured as output for well, the LCD :-s Sep 25 19:57:45 then surely that jumper pulls down the line using a series resistor? Sep 25 19:57:54 rather than connecting it hard to ground Sep 25 19:59:32 let me show you Sep 25 20:04:45 10k series resistor, there you go Sep 25 20:06:49 like, I know you don't know much about electronics but surely by now you can recognize the symbol for a resistor? :P Sep 25 20:07:30 I wasn't sure about the unit ohm ^^ Sep 25 20:07:33 (while you're at it, be aware there's two different symbols in use for resistors, the other one being https://upload.wikimedia.org/wikipedia/commons/c/c3/Resistor_symbol_IEC.svg ) Sep 25 20:07:50 so the pin p8.43 is pulled to ground safely I understand Sep 25 20:09:09 resistors are in ohm (Ω) yes, though schematics may write E instead of Ω (because they couldn't figure out how to put Ω in print I guess) and abbreviate kΩ to k Sep 25 20:10:19 yes, 10k pulldown is strong enough to override the on-board 100k pull-up, but weak enough to be essentially invisible once the pin is driven as output Sep 25 20:43:16 zmatt: there's no way to determine from software if that jumper is set, right? Sep 25 20:44:04 so, there's no way to tell if the jumper is *currently* in place while the pin is used as video output, but it is possible to software to query whether it was in place at power-on Sep 25 20:44:21 it's also possible to briefly change the pin back to gpio, sample it, and change it back to video Sep 25 20:46:08 in barebox I have bootsource (mmc) and bootsource_instance (0 or 1) to determine what bootloader was used. I'll rely on that instead, that avoids tweaking. Sep 25 20:46:49 in a baremetal environment like barebox it's really easy to determine the state of the sysboot pins, they're in a register you can directly read Sep 25 20:47:07 the bootsource used is not equivalent to whether or not the jumper is in place Sep 25 20:47:49 if the bootsource is mmc0 that can either mean the jumper was in place at power-on, or that eMMC was deemed unbootable by bootrom and it fell back to booting from sd card Sep 25 20:48:14 ha very true Sep 25 20:48:48 but in my case that's what I'll need luckily (in order to mount the correct /boot partition, the one from emmc or sd) Sep 25 20:49:07 yep, you'll want the bootsource rather than the jumper for that Sep 25 20:51:50 if it's of any interest, the sysboot pins that were sampled at power-on can be read at physical address 0x44e10040: https://pastebin.com/0jNJRrvk Sep 25 20:53:21 (byte 0 is sysboot0-7, byte 1 is some efuse info, byte 2 is sysboot8-15) Sep 25 20:54:44 (for some reason the register is writable but not preserved across warm reset) Sep 25 21:12:24 zmatt: ah, smart, that can be useful for diagnostics. **** ENDING LOGGING AT Sun Sep 26 02:59:58 2021