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.szyprow...@samsung.com> >>> >>> Reviewed-by: Jaehoon Chung <jh80.ch...@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.salv...@koansoftware.com/
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 -- Marek Szyprowski, PhD Samsung R&D Institute Poland