<kettenis>
did the bisection using the odroid-c4 target running on the hc4
<kettenis>
chewitt: now that I have fixed OpenBSD to match on the "amlogic,meson-sm1-mmc" I see issues with reboot as well
<chewitt>
ahh, good :)
<chewitt>
I hate being the odd one out when it comes to bugs
<kettenis>
sdio read data fail
<kettenis>
reset...
<chewitt>
I am also chasing a possible regression with SDIO wifi
<chewitt>
reverting "mmc: meson-gx: check for scatterlist size alignment in block mode" partially resolved some issues I was seeing
<chewitt>
an S905X2 device that refused to boot with that commit, now boots (although then has further issues I can't see, I need to get uart pins attached)
<chewitt>
mentioning that because .. SDIO is in the HC4 error message
<kettenis>
that is probably just an inaccurate message
<kettenis>
the amount of rubbish that the early boot stages print is somewhat astounding
<chewitt>
no comment :)
<kettenis>
anyway I thought this issue was fixed by using the open-drain config for the TFLASH_VDD' regulator
<chewitt>
I spun an image for C4 using the same sources .. and I have no reboot issue
<kettenis>
hmm, so maybe C4 needs open drain and HC4 doesn't?
<chewitt>
easy to test
sputnik_ has quit [Ping timeout: 268 seconds]
<narmstrong>
Maybe HC4 has a different reboot issue
<kettenis>
no, changing it back the active high makes the issue worse
<chewitt>
I end up at SM1:BL:511f6b:81ca2f
<kettenis>
same here (although it prints some more cryptic information after that)
<kettenis>
sd/emmc cmd 18 arg 0x000001e1 status 01f2200f
<kettenis>
that seems to be the command that fails
<kettenis>
(printed by one of the early boot stages)
<kettenis>
for me it doesn't always happen
<chewitt>
looks like I won't be testing SD cards any further with C4
<chewitt>
I attached power .. nice puff of smoke from the PCB
<chewitt>
it partially boots from an emmc module
plntyk has quit [Quit: Leaving]
ballerburg9005 has quit [Ping timeout: 246 seconds]