Tartarus changed the topic of #u-boot to: SOURCE MOVED TO https://source.denx.de/u-boot/u-boot.git / U-Boot v2022.04 is OUT / Merge Window is OPEN until 25 April 2022 / Release v2022.07 is scheduled for 4 July 2022 / http://www.denx.de/wiki/U-Boot / Channel archives at https://libera.irclog.whitequark.org/u-boot
littlebobeep has quit [Ping timeout: 240 seconds]
thopiekar has quit [Ping timeout: 240 seconds]
thopiekar has joined #u-boot
darkapex has quit [Ping timeout: 256 seconds]
littlebobeep has joined #u-boot
littlebobeep has quit [Ping timeout: 240 seconds]
littlebobeep has joined #u-boot
littlebobeep has quit [Ping timeout: 240 seconds]
Zapy has quit [Ping timeout: 256 seconds]
littlebobeep has joined #u-boot
jlu has joined #u-boot
jlu has quit [Remote host closed the connection]
jlu has joined #u-boot
littlebobeep has quit [Remote host closed the connection]
littlebobeep has joined #u-boot
jlu has quit [Ping timeout: 276 seconds]
sstiller has joined #u-boot
zibolo has joined #u-boot
akaWolf has quit [Ping timeout: 240 seconds]
akaWolf has joined #u-boot
sstiller has quit [Read error: Connection reset by peer]
mckoan|away is now known as mckoan
zibolo has quit [Ping timeout: 256 seconds]
zibolo has joined #u-boot
zibolo has quit [Quit: bye]
zibolo has joined #u-boot
sszy has joined #u-boot
michalkotyla has quit [Quit: michalkotyla]
michalkotyla has joined #u-boot
matthias_bgg has quit [Ping timeout: 256 seconds]
matthias_bgg has joined #u-boot
kettenis has joined #u-boot
mmu_man has joined #u-boot
littlebobeep has quit [Ping timeout: 240 seconds]
akaWolf has quit [Ping timeout: 240 seconds]
mckoan is now known as mckoan|away
akaWolf has joined #u-boot
torez has joined #u-boot
akaWolf has quit [Ping timeout: 240 seconds]
brujah has joined #u-boot
akaWolf has joined #u-boot
akaWolf has quit [Ping timeout: 272 seconds]
akaWolf has joined #u-boot
alan_o has quit [Ping timeout: 250 seconds]
zkrx has quit [Quit: zkrx]
prabhakarlad has quit [Quit: Client closed]
alan_o has joined #u-boot
mps has quit [Ping timeout: 250 seconds]
mps has joined #u-boot
mmu_man has quit [Ping timeout: 248 seconds]
monstr has joined #u-boot
mmu_man has joined #u-boot
mmu_man has quit [Ping timeout: 240 seconds]
mmu_man has joined #u-boot
vagrantc has joined #u-boot
NishanthMenon[m] has quit [Quit: You have been kicked for being idle]
monstr has quit [Remote host closed the connection]
sszy has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
Zapy has joined #u-boot
Xogium has joined #u-boot
<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)
<Xogium> Tartarus: here's the console https://paste.xogium.me/ut.txt
<Tartarus> OK, so, failed to load zImage
<Xogium> in that context I thought it meant, failed to load because bad magic ?
<Tartarus> Did you write the boot.scr or is that from something else?
<Xogium> I mean given the error is printed right after…
<Xogium> hmm was provided in buildroot
<Tartarus> Right, the bad magic is that there's no zImage at the expected address :)
<Xogium> huh
<Xogium> oh
<Xogium> why would that be
<Xogium> the script is this one
<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-> yes
<beanbag-> cost a bit more but nice
<Xogium> oh
<Xogium> you managed to use the smart data from them ?
<beanbag-> no I have not but they support it
<beanbag-> I might get one for my orangePI eventually
<Xogium> I wonder if any tools in linux is made to handle that… I'll have to check
<beanbag-> I think smartmontools *MIGHT*
<beanbag-> lemem check
<beanbag-> oh this is neat
<beanbag-> thx
<beanbag-> just learned about mmc utils
<beanbag-> dunno if it can do smart ye
<beanbag-> bah I will have to look more later
mthall has quit [Read error: Connection reset by peer]
<Xogium> mmc-utils is eMMC specific, ironically
<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
<Xogium> beanbag-: thank you :D
mthall has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
mthall has joined #u-boot
<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
<Tartarus> thanks
<marex> Tartarus: thanks
<beanbag-> this is cool
<beanbag-> wonder if u-boot supports it
<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
vagrantc has joined #u-boot