[PATCH] rpi: always set fdt_addr to the correct value
m.szyprowski at samsung.com
Tue Feb 15 23:48:59 CET 2022
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
>>>> on the dtb size or firmware version. If one save the environment to
>>>> 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
>>>> 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 at samsung.com>
>>> Reviewed-by: Jaehoon Chung <jh80.chung at 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:
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'.
Marek Szyprowski, PhD
Samsung R&D Institute Poland
More information about the U-Boot