09:26 <trinath> hi

17:44 <vd> 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 -> ...)

18:18 <zmatt> 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 }

18:19 <zmatt> see https://goo.gl/Jkcg0w#gid=750891223 for details about how bootrom is configured using the strapping options (sysboot0-15 aka lcd_data0-15)

18:19 <zmatt> separately from that, u-boot also has its own boot device order for finding a linux system to boot

18:20 <vd> I have a jumper on my daughter which forces either eMMC or SD card boot I think, no fallback

18:21 <zmatt> there's only a single boot mode that includes eMMC and it always has μSD as fallback

18:22 <zmatt> so your claim is literally impossible

18:28 <vd> zmatt let me check what it does on the schematics

18:29 <zmatt> probably pulls P8.43 (sysboot2) to ground, same as the S2 button on the beaglebone

18:43 <vd> zmatt: indeed that's it! P8.43 pulled to ground

18:44 <vd> so that jumper is equivalent to having the S3 button pressed all the time?

18:44 <vd> S2*

18:45 <zmatt> yeah so don't accidently configure that pin as output, in particular make sure video is disabled in /boot/uEnv.txt

18:45 <zmatt> (unless there's a series resistor (1 kΩ or larger) to limit current)

18:57 <vd> zmatt that pin (LCD_DATA2) is configured as output for well, the LCD :-s

18:57 <zmatt> then surely that jumper pulls down the line using a series resistor?

18:57 <zmatt> rather than connecting it hard to ground

18:59 <vd> let me show you

19:04 <zmatt> 10k series resistor, there you go

19:06 <zmatt> like, I know you don't know much about electronics but surely by now you can recognize the symbol for a resistor? :P

19:07 <vd> I wasn't sure about the unit ohm ^^

19:07 <zmatt> (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 )

19:07 <vd> so the pin p8.43 is pulled to ground safely I understand

19:09 <zmatt> 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

19:10 <zmatt> 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

19:43 <vd> zmatt: there's no way to determine from software if that jumper is set, right?

19:44 <zmatt> 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

19:44 <zmatt> it's also possible to briefly change the pin back to gpio, sample it, and change it back to video

19:46 <vd> 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.

19:46 <zmatt> 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

19:47 <zmatt> the bootsource used is not equivalent to whether or not the jumper is in place

19:47 <zmatt> 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

19:48 <vd> ha very true

19:48 <vd> 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)

19:49 <zmatt> yep, you'll want the bootsource rather than the jumper for that

19:51 <zmatt> 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

19:53 <zmatt> (byte 0 is sysboot0-7, byte 1 is some efuse info, byte 2 is sysboot8-15)

19:54 <zmatt> (for some reason the register is writable but not preserved across warm reset)

20:12 <vd> zmatt: ah, smart, that can be useful for diagnostics.