Unexpected RPi5 Behavior with Saved U-Boot Environment

Unexpected RPi5 Behavior with Saved U-Boot Environment

[Richard Weinberger]

Hi!

We recently started using U-Boot on various Raspberry Pi 5 boards
with different hardware configurations.

While testing, Simon noticed unusual boot failures, such as the kernel
failing to boot with no output or U-Boot reporting:
"ERROR: Did not find a cmdline Flattened Device Tree."

Today, I spent time investigating these issues. It appears that U-Boot
retrieves several variables from the Raspberry Pi firmware, with fdt_addr
being particularly important.
If the environment is saved, fdt_addr gets stored and takes precedence
over what the firmware provides to U-Boot.

Interestingly, the RPi firmware seems to modify fdt_addr based on connected
hardware.  Our experiments showed that even attaching an RPi camera module
changes the computed fdt_addr and U-Boot reads from the wrong memory location.

As a result, saving the environment, whether via the saveenv command in U-Boot
or fw_setenv in Linux, can lead to boot failures if the hardware configuration changes.

Do you have any suggestions for mitigating this issue?
In my opinion, U-Boot should not override such critical variables.

Thanks,
//richard

-- 
​​​​​sigma star gmbh | Eduard-Bodem-Gasse 6, 6020 Innsbruck, AUT UID/VAT Nr:
ATU 66964118 | FN: 374287y

Re: Unexpected RPi5 Behavior with Saved U-Boot Environment

[Mauro Salvini]

On 27/03/25 16:54, Richard Weinberger wrote:
> Hi!
> 
> We recently started using U-Boot on various Raspberry Pi 5 boards
> with different hardware configurations.
> 
> While testing, Simon noticed unusual boot failures, such as the kernel
> failing to boot with no output or U-Boot reporting:
> "ERROR: Did not find a cmdline Flattened Device Tree."
> 
> Today, I spent time investigating these issues. It appears that U-Boot
> retrieves several variables from the Raspberry Pi firmware, with fdt_addr
> being particularly important.
> If the environment is saved, fdt_addr gets stored and takes precedence
> over what the firmware provides to U-Boot.
> 
> Interestingly, the RPi firmware seems to modify fdt_addr based on connected
> hardware.  Our experiments showed that even attaching an RPi camera module
> changes the computed fdt_addr and U-Boot reads from the wrong memory location.
> 
> As a result, saving the environment, whether via the saveenv command in U-Boot
> or fw_setenv in Linux, can lead to boot failures if the hardware configuration changes.
> 
> Do you have any suggestions for mitigating this issue?
> In my opinion, U-Boot should not override such critical variables.
> 
> Thanks,
> //richard
> 

Hi Richard,

could be related tho this [1]?

I sent this patch some years ago but was never accepted in u-boot tree.
But meta-rpi uses it in u-boot recipe [2].

Regards

[1] https://lists.denx.de/pipermail/u-boot/2021-May/449609.html
[2] 
https://github.com/agherzan/meta-raspberrypi/blob/master/recipes-bsp/u-boot/files/0001-rpi-always-set-fdt_addr-with-firmware-provided-FDT-address.patch

-- 
Mauro

Re: Unexpected RPi5 Behavior with Saved U-Boot Environment

[Richard Weinberger]

On Donnerstag, 27. März 2025 17:24 Mauro Salvini wrote:
> could be related tho this [1]?
> 
> I sent this patch some years ago but was never accepted in u-boot tree.
> But meta-rpi uses it in u-boot recipe [2].

Uh, good point!
In our initial experiments we have used meta-raspberrypi but now we don't.
This would explain it.

IMHO this patch needs to be reconsidered.

Thanks,
//richard

-- 
​​​​​sigma star gmbh | Eduard-Bodem-Gasse 6, 6020 Innsbruck, AUT UID/VAT Nr:
ATU 66964118 | FN: 374287y

Re: Unexpected RPi5 Behavior with Saved U-Boot Environment

[Mauro Salvini]

On 27/03/25 17:31, Richard Weinberger wrote:
> On Donnerstag, 27. März 2025 17:24 Mauro Salvini wrote:
>> could be related tho this [1]?
>>
>> I sent this patch some years ago but was never accepted in u-boot tree.
>> But meta-rpi uses it in u-boot recipe [2].
> 
> Uh, good point!
> In our initial experiments we have used meta-raspberrypi but now we don't.
> This would explain it.
> 
> IMHO this patch needs to be reconsidered.
> 

Hi Richard,

glad that the patch was helpful.

Here [1] the original discussion about the patch.

[1] 
https://patchwork.ozlabs.org/project/uboot/patch/20210512123945.25649-1-m.salvini@koansoftware.com/

-- 
Mauro

Re: Unexpected RPi5 Behavior with Saved U-Boot Environment

[Simon Glass]

Hi,

On Thu, 27 Mar 2025 at 10:32, Richard Weinberger <richard@sigma-star.at> wrote:
>
> On Donnerstag, 27. März 2025 17:24 Mauro Salvini wrote:
> > could be related tho this [1]?
> >
> > I sent this patch some years ago but was never accepted in u-boot tree.
> > But meta-rpi uses it in u-boot recipe [2].
>
> Uh, good point!
> In our initial experiments we have used meta-raspberrypi but now we don't.
> This would explain it.
>
> IMHO this patch needs to be reconsidered.

It seems i hit the same problem when I sent this series:

https://lore.kernel.org/u-boot/20241220003447.2913443-1-sjg@chromium.org/

>
> Thanks,
> //richard
>
> --
> sigma star gmbh | Eduard-Bodem-Gasse 6, 6020 Innsbruck, AUT UID/VAT Nr:
> ATU 66964118 | FN: 374287y
>
>

Regards,
Simon

Re: Unexpected RPi5 Behavior with Saved U-Boot Environment

[Peter Robinson]

Hi Mauro,

> > We recently started using U-Boot on various Raspberry Pi 5 boards
> > with different hardware configurations.
> >
> > While testing, Simon noticed unusual boot failures, such as the kernel
> > failing to boot with no output or U-Boot reporting:
> > "ERROR: Did not find a cmdline Flattened Device Tree."
> >
> > Today, I spent time investigating these issues. It appears that U-Boot
> > retrieves several variables from the Raspberry Pi firmware, with fdt_addr
> > being particularly important.
> > If the environment is saved, fdt_addr gets stored and takes precedence
> > over what the firmware provides to U-Boot.
> >
> > Interestingly, the RPi firmware seems to modify fdt_addr based on connected
> > hardware.  Our experiments showed that even attaching an RPi camera module
> > changes the computed fdt_addr and U-Boot reads from the wrong memory location.
> >
> > As a result, saving the environment, whether via the saveenv command in U-Boot
> > or fw_setenv in Linux, can lead to boot failures if the hardware configuration changes.
> >
> > Do you have any suggestions for mitigating this issue?
> > In my opinion, U-Boot should not override such critical variables.
> >
> > Thanks,
> > //richard
> >
>
> Hi Richard,
>
> could be related tho this [1]?
>
> I sent this patch some years ago but was never accepted in u-boot tree.
> But meta-rpi uses it in u-boot recipe [2].

After digging into this and a discussion with Tom we decided this is
the correct fix so I've pulled that patch in for 2025.07.

Thanks,
Peter

> Regards
>
> [1] https://lists.denx.de/pipermail/u-boot/2021-May/449609.html
> [2]
> https://github.com/agherzan/meta-raspberrypi/blob/master/recipes-bsp/u-boot/files/0001-rpi-always-set-fdt_addr-with-firmware-provided-FDT-address.patch
>
> --
> Mauro

Re: Unexpected RPi5 Behavior with Saved U-Boot Environment

[Mauro Salvini]

On 21/04/25 12:15, Peter Robinson wrote:
> Hi Mauro,
> 
>>> We recently started using U-Boot on various Raspberry Pi 5 boards
>>> with different hardware configurations.
>>>
>>> While testing, Simon noticed unusual boot failures, such as the kernel
>>> failing to boot with no output or U-Boot reporting:
>>> "ERROR: Did not find a cmdline Flattened Device Tree."
>>>
>>> Today, I spent time investigating these issues. It appears that U-Boot
>>> retrieves several variables from the Raspberry Pi firmware, with fdt_addr
>>> being particularly important.
>>> If the environment is saved, fdt_addr gets stored and takes precedence
>>> over what the firmware provides to U-Boot.
>>>
>>> Interestingly, the RPi firmware seems to modify fdt_addr based on connected
>>> hardware.  Our experiments showed that even attaching an RPi camera module
>>> changes the computed fdt_addr and U-Boot reads from the wrong memory location.
>>>
>>> As a result, saving the environment, whether via the saveenv command in U-Boot
>>> or fw_setenv in Linux, can lead to boot failures if the hardware configuration changes.
>>>
>>> Do you have any suggestions for mitigating this issue?
>>> In my opinion, U-Boot should not override such critical variables.
>>>
>>> Thanks,
>>> //richard
>>>
>>
>> Hi Richard,
>>
>> could be related tho this [1]?
>>
>> I sent this patch some years ago but was never accepted in u-boot tree.
>> But meta-rpi uses it in u-boot recipe [2].
> 
> After digging into this and a discussion with Tom we decided this is
> the correct fix so I've pulled that patch in for 2025.07.
> 
> Thanks,
> Peter
> 

Hi Peter,

thank you.

Regards

Mauro

>> Regards
>>
>> [1] https://lists.denx.de/pipermail/u-boot/2021-May/449609.html
>> [2]
>> https://github.com/agherzan/meta-raspberrypi/blob/master/recipes-bsp/u-boot/files/0001-rpi-always-set-fdt_addr-with-firmware-provided-FDT-address.patch
>>
>> --
>> Mauro
>