<jbrunet>
don't see anything pointing toward a mmc issue
<lissyx>
jbrunet, right, but no /dev/mmcblk1 exists at all, and yet it seems like U-Boot was able to find the sdcard
<lissyx>
I'll try to capture dmesg better, this is what minicom -C got me :(
<jbrunet>
maybe my eyes are not that good but I don't see anything about mmc1 in your log
<lissyx>
jbrunet, at the end: ALERT! /dev/mmcblk1p1 does not exist. Dropping to a shell!
<jbrunet>
never seen that before
<lissyx>
ok, so that's not the same issue as you were referring, that answers my question
<jbrunet>
the issue I mentioned would manifest with -110 (timeout) error in loop, which clears if you unplug-plug the sdcard
<jbrunet>
(not a solution , I reckon)
<lissyx>
I'm debugging spurious boot like that on some of my boards
<lissyx>
context: I've setup a system of six RPi3B+ and six LePotato, powered by and (old) ATX PSU
<lissyx>
hooking +5V from the PSU to microUSB (and +12V for two switches and fans)
<jbrunet>
To be honest, I did not follow armbian that closely so I don't really with which then have taken or not
<jbrunet>
know - which patch (sorry)
<lissyx>
what i'm seeing is one or two board, on powerup of the whole system, not booting properly. PLugging the UART gave me the log earlier
<lissyx>
my best hypothesis for now would be power surge making some boards failing
<jbrunet>
Did you check your supply rating for each rail ? we tried the ATX approach for another project at baylibre, with a 500W supply
<lissyx>
but I wanted to make sure I was not facing that issue you mentionned
<jbrunet>
it seemed more than enough
<lissyx>
yes
<lissyx>
it's rated 30A on +5V
<jbrunet>
looking more closely, we saw that each rails was limited to 10A
<jbrunet>
maybe your supply is better :)
<lissyx>
I've just tested adding a 5.0 delay in uboot, my first attempt is a better success
<lissyx>
hm second test, not good
<jbrunet>
not so lucky :) don't go to the casino tonight
<jbrunet>
Can you hook the uart ?
<jbrunet>
oops, from your log, it looks like you already have it
<jbrunet>
could you add "earlycon debug" to your command line ?
<jbrunet>
to get a few more messages ... there isn't much hints the log you sent
<lissyx>
in boot.cmd ?
<lissyx>
jbrunet, what about "libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND" ?
<jbrunet>
wherever you define it ... u-boot maybe ?
<lissyx>
I'm not touching u-boot at all
<lissyx>
as much as I understood it's handled in boot/boot.cmd
<jbrunet>
I guess ... still you must define a command line somewhere
<lissyx>
well, there's kernel cmdline there :)
<jbrunet>
Only one way to know for sure
<jbrunet>
:)
<lissyx>
jbrunet, ok, I do see earlycon, but most of the boot log is missing :(
cthugha is now known as ldevulder
cthugha has joined #linux-amlogic
ldevulder has quit [Ping timeout: 240 seconds]
<lissyx>
sleep in uboot seems not effective
Elpaulo_m has quit [Ping timeout: 248 seconds]
afaerber has quit [Quit: Leaving]
a5m has quit [Remote host closed the connection]
afaerber has joined #linux-amlogic
cthugha has quit [Quit: Leaving]
jbrunet has quit []
focus has joined #linux-amlogic
<lissyx>
narmstrong, ok, so swapping everything around, I end up at the same conclusion: there's just one board that often (but not 100% of the time) boots improperly