charlie5 has quit [Ping timeout: 265 seconds]
charlie5 has joined #beagle
thinkfat_ has quit [Ping timeout: 265 seconds]
thinkfat has joined #beagle
starblue1 has quit [Ping timeout: 252 seconds]
starblue1 has joined #beagle
ikarso has quit [Quit: Connection closed for inactivity]
Shadyman has quit [Quit: Leaving.]
buzzmarshall has quit [Remote host closed the connection]
vagrantc has quit [Ping timeout: 260 seconds]
djinni has quit [Quit: Leaving]
djinni has joined #beagle
dinuxbg has quit [Ping timeout: 240 seconds]
lucascastro has quit [Ping timeout: 252 seconds]
trinath has joined #beagle
<trinath> hi
trinath has quit [Remote host closed the connection]
otisolsen70 has joined #beagle
xet7 has quit [Remote host closed the connection]
xet7 has joined #beagle
Posterdati has quit [Read error: Connection reset by peer]
dinuxbg has joined #beagle
buzzmarshall has joined #beagle
lucascastro has joined #beagle
GenTooMan has quit [Quit: Leaving]
GenTooMan has joined #beagle
vagrantc has joined #beagle
vagrantc has quit [Quit: leaving]
starblue1 has quit [Ping timeout: 252 seconds]
vd has quit [Quit: Client closed]
starblue1 has joined #beagle
vd has joined #beagle
<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 -> ...)
starblue1 has quit [Ping timeout: 250 seconds]
starblue1 has joined #beagle
<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 }
<zmatt> see for details about how bootrom is configured using the strapping options (sysboot0-15 aka lcd_data0-15)
<zmatt> separately from that, u-boot also has its own boot device order for finding a linux system to boot
<vd> I have a jumper on my daughter which forces either eMMC or SD card boot I think, no fallback
<zmatt> there's only a single boot mode that includes eMMC and it always has μSD as fallback
<zmatt> so your claim is literally impossible
<vd> zmatt let me check what it does on the schematics
<zmatt> probably pulls P8.43 (sysboot2) to ground, same as the S2 button on the beaglebone
<vd> zmatt: indeed that's it! P8.43 pulled to ground
<vd> so that jumper is equivalent to having the S3 button pressed all the time?
<vd> S2*
<zmatt> yeah so don't accidently configure that pin as output, in particular make sure video is disabled in /boot/uEnv.txt
<zmatt> (unless there's a series resistor (1 kΩ or larger) to limit current)
starblue1 has quit [Ping timeout: 252 seconds]
<vd> zmatt that pin (LCD_DATA2) is configured as output for well, the LCD :-s
<zmatt> then surely that jumper pulls down the line using a series resistor?
<zmatt> rather than connecting it hard to ground
<vd> let me show you
starblue1 has joined #beagle
<zmatt> 10k series resistor, there you go
<zmatt> like, I know you don't know much about electronics but surely by now you can recognize the symbol for a resistor? :P
<vd> I wasn't sure about the unit ohm ^^
<zmatt> (while you're at it, be aware there's two different symbols in use for resistors, the other one being )
<vd> so the pin p8.43 is pulled to ground safely I understand
<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
<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
<vd> zmatt: there's no way to determine from software if that jumper is set, right?
<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
starblue1 has quit [Ping timeout: 260 seconds]
<zmatt> it's also possible to briefly change the pin back to gpio, sample it, and change it back to video
<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.
<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
<zmatt> the bootsource used is not equivalent to whether or not the jumper is in place
<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
<vd> ha very true
<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)
<zmatt> yep, you'll want the bootsource rather than the jumper for that
<zmatt> if it's of any interest, the sysboot pins that were sampled at power-on can be read at physical address 0x44e10040:
<zmatt> (byte 0 is sysboot0-7, byte 1 is some efuse info, byte 2 is sysboot8-15)
<zmatt> (for some reason the register is writable but not preserved across warm reset)
starblue1 has joined #beagle
<vd> zmatt: ah, smart, that can be useful for diagnostics.
vagrantc has joined #beagle
ikarso has joined #beagle
otisolsen70 has quit [Quit: Leaving]
russ has quit [Remote host closed the connection]
Shadyman has joined #beagle
russ has joined #beagle
ikarso has quit [Quit: Connection closed for inactivity]