I have a device here now, so can do more checks.
I compared both boot partition contents. All seem ok.
See attachment for a screenshot of what happens on the device that doesn’t boot anymore.
Cannot find valid devicetree. This is a problem. Do you have in /boot/ some dtb files?
I compared the contents of the first partition. ALl were exactly the same.
Are they stored in a subfolder?
It cannto find valid fdt_header. I guess it’s similar problem which we face on rpi0w. Can you try in u-boot console run setenv fdt_addr_r '' and reboot board if it help? Thanks.
No change.
Sorry you need to run also saveenv after changing variable otherwise variable won’t be stored.
no diff either.
Can you please post output of :
pri $fdt_addr_r
md.l $fdt_addr_r
I sent you a private message.
A bit more info. I moved from a rocko build to a thud build.
Maybe that triggers some suggestions?
I’m pretty much dead in the water with my project right now…
OK fine. Did you please try what I’ve suggested above? I think issue can be that if you update from rocko to thud there could be update on rpi firmware (if you are doing only mende update and not whole sdimg) it could happen that fdt_addr in u-boot detected by firmware (it’s written first time to uboot env)is changed and then board cannot boot. My test should clear it so new updated image should set it to proper value. We have seen this on rpi0w raspbian that on first boot it increase data partition to then end of flash and then after reboot we have same symptoms like you have. Maybe can you try to add this commit to your thud yocto to see if it helps. Or if you can share old and new image somewhere I can try to play with it here. Thanks.
I did that command, but nothing changed.
OK can you please try and post me log when command is executed:
setenv fdt_addr ''
saveenv
reset
I’m using mender to update yocto-based images on Raspberry Pi3B’s.
This works great, except for the firmware files.
I’m using the workaround script, but this still results in not-booting pi’s.
The pi’s are normally powered, no power outages are happening etc.
Am I missing something?
I’m not following @mterwoord what workaround script are you referring to? What version of Yocto are you running? What is the symptom when your boards do not boot?
I mean the script at: https://github.com/mirzak/meta-mender/commit/9d6211d585ecd7c73f11a10d503b9005516fc755
I have devices in the field, I’m updating to a new kernel etc, and then those don’t come online.
It’s difficult to say what the issue is. Do you have any means to have someone with physical access to the board provide a serial console log or at least a description of what happens on the HDMI?
FDT_ERR_BADMAGIC means that it can not find the devicetree binary file. It has been observed that the boot firmware (which initially loads the devicetree binary) can change address of where it loads it.
It does provide a variable to U-boot where it stored it, but this variable is not always read and depends on if fdt_addr is set and I believe that this is what you are experiencing as well.
You could try this patch,
Some history of the change can be found here,
Awesome. This seems to work!
Edit: By manually removing the fdt_addr value.
Next step is integrated that comit and see if it works.