Another related issue that I was confused by is that I expected the FDT address to be in the variable fdt_addr_r but it is in fdt_addr. In the U-Boot documentation here https://u-boot.readthedocs.io/en/latest/usage/environment.html#image-locatio..., *_r variables indicate addresses in RAM whereas fdt_addr refers to a flash location. This may provide a solution to the backwards compatibility problem with this patch. I propose setting both fdt_addr and fdt_addr_r to the firmware-provided FDT in fw_dtb_pointer, and you can make it so that fdt_addr_r will be overwritten even if there is a pre-existing value for it in the environment. Thoughts?
On Mon, Feb 14, 2022 at 6:25 AM Marek Szyprowski m.szyprowski@samsung.com 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
board/raspberrypi/rpi/rpi.c | 3 --- 1 file changed, 3 deletions(-)
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c index bc3cc597adb..6d6d2e69234 100644 --- a/board/raspberrypi/rpi/rpi.c +++ b/board/raspberrypi/rpi/rpi.c @@ -347,9 +347,6 @@ static void set_fdtfile(void) */ static void set_fdt_addr(void) {
if (env_get("fdt_addr"))return;if (fdt_magic(fw_dtb_pointer) != FDT_MAGIC) return;