<Xogium>
hi guys. Say, what are the steps to debug why u-boot is telling me that it failed to load zImage with bad magic error, if the magic is definitely in the file ?
<Xogium>
I upgraded kernel on licheepi zero, from 5.3.5 to 5.17.3, and this exploded. 5.3.5 kernel plus u-boot 2022.01 worked fine and dandy
<Xogium>
I thought it could be because the kernel and dt overlap in memory but… nop, I double checked the load addresses and there is literally 8 MB of room between both, kernel being 4.8 MB
<Tartarus>
Pastebin the full console
<Tartarus>
And... crc32 or something both what you load in to memory, and the file on the host
<Xogium>
Tartarus: sure, just a second
<Tartarus>
(rhash -C foo will crc32 a file on your host, for example)
<Tartarus>
OK, so you're expecting to boot all of this from the SD card, yes?
<Xogium>
checking the partition it mention shows that there is a zImage…
<Xogium>
yea
<Tartarus>
When the script fails, you get the u-boot prompt I assume
<Tartarus>
so, ls mmc 0:1
<Xogium>
yep dtb and zImage are both in there
<Tartarus>
If you manually do load mmc 0:1 0x41000000 zImage then what?
<Xogium>
erm… same error
* Xogium
scratches head
<Tartarus>
OK, what if you use the older u-boot ?
<Tartarus>
That would give you a u-boot to bisect down to where the failure comes from
<Xogium>
oh u-boot is fine. I haven't changed it. I only upgraded kernel
<Xogium>
but… the checksums don't match on the micro sd vs what I got on my pc
<Tartarus>
But now it's not loading the file, in U-Boot
<Xogium>
they definitely don't match at all
<Tartarus>
Wait
<Tartarus>
If you put the SD in your PC
<Tartarus>
The checksums are wrong/
<Xogium>
yes
<Xogium>
29d9f4e33601c07312d3d7b28e70fb1b76dcd597926c352cafecf9e6875bdba5 in build dir
<Xogium>
1cf4db8ab4826d412692a3bd4c6f88d75c540c954b2b246da148c83f4e8b270c on micro sd
<Tartarus>
reflash the SD card
<Tartarus>
Or, try a new SD card, that might have failed
<Xogium>
erk
<Xogium>
fudge I should have realized this sooner
<Xogium>
you'd think after 6 years of doing embedded linux I'd think of that
<Xogium>
oh jesus yeah you're absolutely right, checking dmesg now shows a ton of i/o errors
<Xogium>
that being said… if I may suggest ;) could the error there be improved a bit ? Because it makes it sound like bad magic is the reason why it won't liad zImage… At least to me. Not that it doesn't load anything and so returns bad magic
<Xogium>
*load
beanbag- has joined #u-boot
<Xogium>
sigh… Yet another dead sd card… Thank you a lot for your help in finding the issue, Tartarus
<Xogium>
really rappeciate it
<beanbag->
Xogium, wd makes industrial line and also a purple line both have smart monitoring, power loss protection etc
<Tartarus>
Welcome
<Tartarus>
Xogium: Part of the issue is the boot.scr doesn't use "&&" which works just like it does in bash
<Tartarus>
So we try something, fails, keep moving on
<Tartarus>
vs try something, fail, stop
<Tartarus>
Better error detection in the boot.scr would be good
<Xogium>
ah, I see
<Xogium>
that makse sense
<Xogium>
makes
<Xogium>
beanbag-: wd makes micro sd ? As in western digital ? :O
<beanbag->
looks like some hope at least from micron industrail cardsd
<beanbag->
hmm the wd purple 64gb is $15
<beanbag->
not bad at all
<Xogium>
in the past I delt with micro sd that had smart support, or rather tried to. Quickly found out that in linux land there was no program to handle this, and getting access to the data to be able to interpret the smart data required to sign an NDA
<Xogium>
but micron they sound nice
mthall has joined #u-boot
<beanbag->
$23 for 32gb
<beanbag->
not bad
<Xogium>
yep those are most likely pslc flash, that is probably mlc with software on top to make it behave as slc
<Xogium>
actual hardware slc is much more high in cost
<beanbag->
oh well if I find any more info I will pass along
<Tartarus>
marex: Which of those LED patches fixes the stm regression?
<Tartarus>
Or is it the 3 part series?
<marex>
Tartarus: the 3part series fixes the problem
<marex>
Tartarus: two problems in fact, see the Fixes: tags
<marex>
Tartarus: the rest of the patches are just cleanups
<marex>
Tartarus: I wanted to get something to ST to fix their bug, so I did roll that out soon, and then I started noticing other things to fix/improve, so the patches were coming in that order
<Tartarus>
OK, I'll pick them up before Monday -rc but give a bit more time for comments
<beanbag->
guess it doesn't need to be that super accurable at the first stage of booting so ntp is fine
<beanbag->
accurate
<beanbag->
marex I assume unless qemu supports it (and their ppc 4xx support is canucked), THERE's no way to test this u-boot binary before flashing is to rom
<beanbag->
I tried to loadb into ram and then I hit go whatever the loadb addresss said it was at
<beanbag->
no luck just reboots
torez has quit [Remote host closed the connection]
vagrantc has quit [Quit: leaving]
littlebobeep has joined #u-boot
littlebobeep has quit [Ping timeout: 240 seconds]
littlebobeep has joined #u-boot
zibolo has quit [Ping timeout: 240 seconds]
zibolo has joined #u-boot
littlebobeep has quit [Ping timeout: 240 seconds]
beanbag- has left #u-boot [Leaving]
apritzel has joined #u-boot
mthall has quit [Ping timeout: 276 seconds]
sbach has quit [Read error: Connection reset by peer]
sbach has joined #u-boot
brujah has quit [Quit: Leaving]
<apritzel>
Tartarus: what are the exact criteria for taking DT updates from Linux? There are patches landed in the maintainers tree (sunxi/dt-for-5.19) and also in linux-next, would that be sufficient?
<Tartarus>
apritzel: yes, that's fine. I just want them landed/reviewed somehwere
<Tartarus>
Or if it's a bad part of the cycle, posted
littlebobeep has joined #u-boot
<apritzel>
Tartarus: thanks! I mostly pushed the DT patches to Linux to get them into U-Boot ;-), and didn't want to wait for 5.19-rc1, so that's good to hear