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
