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?
I moved these posts to a separate topic in https://hub.mender.io/c/general-discussions
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.
Nice, please let us know if the patch fixes your problems and in that case we should include it in meta-mender.
Have not really seen this problem in Yocto and that is why ths patch is only applied when using mender-convert.
I suspect that there has been some boot firmware change recently that triggered this problem
As a C# / .NET Developer, only learning yocto because I have to, I’d think, that if we can live without that variable, we should do it? (Or is that reasoning too easy?)
How would I apply this patch as part of my yocto build?
You can take a look at how it is done in our layers,