Why is FDT relocation needed in stm32mp1 u-boot ?

[Grodriguez]

Hi all,

I am trying to understand this commit [1] in u-boot, which removes the fdt_high variable from the environment for stm32mp1 boards.

Before this commit, the FDT was initially loaded from persistent storage to address 0xc4000000, and then used in place:

## Flattened Device Tree blob at c4000000

  Booting using the fdt blob at 0xc4000000

  XIP Kernel Image ... OK

  Using Device Tree in place at c4000000, end c40160d0

After this commit, the FDT is loaded from persistent storage to address 0xc4000000, and then relocated to a different position:

## Flattened Device Tree blob at c4000000

  Booting using the fdt blob at 0xc4000000

  XIP Kernel Image

  Loading Device Tree to cffea000, end cffffc12 ... OK

Why is the extra relocation needed? What problem does it solve?

Thank you,

Guillermo

[1]: https://github.com/STMicroelectronics/u-boot/commit/ec244f6770454e8fd0bb3a33a36339de53e5f59a

[PatrickD]

Hi,

It is a direct request from Tom Rini (the U-Boot master custodian)  to every board maintainers (mail: 28 January 2020).

http://u-boot.10912.n7.nabble.com/Removing-quot-fdt-high-0xffffffff-quot-from-board-environments-tt398488.html

 But as it is just a "default" environment of STMicroelectronics board, you can override it in your design.

The only constraint is to have an aligned load address for FDT to avoid futher issue in libfdt.

FYI: this request is a consequence of "[PATCH] libfdt: Revert 6dcb8ba4 from upstream libfdt"

http://u-boot.10912.n7.nabble.com/PATCH-libfdt-Revert-6dcb8ba4-from-upstream-libfdt-tt398269.html

in this patch, the libfdt protection for unaligned FDT is removed to avoid the performance issue.

So the loaded FDT need to be ALWAYS aligned when used by libfdt.

It is guarantee only if relocation is done.

So it is not mandatory, it is just more safe.

Patrick