Hi Matthias,
On 15.02.2022 19:19, Matthias Brugger wrote:
On 15/02/2022 15:55, Matthias Brugger wrote:
On 18/02/2022 03:44, Jaehoon Chung wrote:
On 22. 2. 14. 20:25, Marek Szyprowski wrote:
The fdt_addr env have meaning only for the current runtime and it depends on the dtb size or firmware version. If one save the environment to disk and the loads it on the latter boot, the fdt_addr might change, what result in passing incorrect dtb address to the kernel. Fix this by always setting the fdt_addr env. This fixes system operation after saving the env to disk and updating i.e. dtb files or firmware.
Signed-off-by: Marek Szyprowski m.szyprowski@samsung.com
Reviewed-by: Jaehoon Chung jh80.chung@samsung.com
Could we keep the discussion where we left it the last time you submitted the patch?
I forgot to add the link to the old discussion: https://patchwork.ozlabs.org/project/uboot/patch/20210512123945.25649-1-m.sa...
Well, I'm still not convinced that this is a good idea.
I found this issue while debugging something else and I must admit that the current behavior is really counterintuitive. I was surprised that after setting some really unrelated things in u-boot's envs (like additional kernel arguments to increase debug level) and saving such config, I got completely broken system. Right, I've also updated DTB in meantime because I was bisecting some kernel related issue, but still this is something that a typical user might face during system update.
If we want to keep current behavior, the 'saveenv' command should print a large banner that one has to first delete the 'fdt_addr' env if he wants to have a working system.
I will check if it would be possible to use some flags for the 'fdt_addr' env to mark it as 'do-not-save-unless-changed-manually'.
Best regards