why fdt_addr_r is 0x88000000?

[pdp7]

fdt_addr_r=0x88000000 is set in include/configs/starfive-vic7100.h

https://github.com/starfive-tech/u-boot/blob/93099a61c7b048ba1926152629284f8810cb6940/include/configs/starfive-vic7100.h#L114

@lbmeng @MichaelZhuxx @tekkamanninja @davidlt @mcd500 do you know why 0x88000000 was choosen?

@tpetazzoni discovered that this did not work when building u-boot for BeagleV Starlight in upstream buildroot. Thomas created this patch to change fdt_addr_r to 0x90000000. https://github.com/buildroot/buildroot/blob/master/board/beaglev/patches/uboot/0001-include-configs-starfive-vic7100-adjust-fdt_addr_r.patch

I can confirm that the system does not boot without changing fdt_addr_r to 0x90000000.

Does anyone understand why fdt_addr_r=0x88000000 is only a problem for the buildroot setup?

my buildroot beaglev_defconfig is using:

• OpenSBI: https://github.com/starfive-tech/opensbi/commit/2524b0ecd8684b42bc7a4c69794f40f11cbbe2a5 by @tekkamanninja
• u-boot: https://github.com/starfive-tech/u-boot/commit/93099a61c7b048ba1926152629284f8810cb6940 by @lbmeng (plus the patch to change fdt_addr_r to 0x90000000)

[trini]

The problem is that earlier you set fdt_high=0xffffffffffffffff which disables relocation of the device tree (and initrd_high does similar) so that even when U-Boot can see there's an overlap and you're gonna have the fdt be overwritten, we just let it happen. That line needs to be remove anyhow as checkpatch.pl throws an error over it.

[pdp7]

@trini thank you for the insights. Yes, I see now that checkpatch does warn about that in u-boot/include/configs/starfive-vic7100.h:

    ERROR: fdt or initrd relocation disabled at boot time
    +       "fdt_high=0xffffffffffffffff\0" \

    ERROR: fdt or initrd relocation disabled at boot time
    +       "initrd_high=0xffffffffffffffff\0" \

[tekkamanninja]

fdt_addr_r=0x88000000 is set in include/configs/starfive-vic7100.h

https://github.com/starfive-tech/u-boot/blob/93099a61c7b048ba1926152629284f8810cb6940/include/configs/starfive-vic7100.h#L114

@lbmeng @MichaelZhuxx @tekkamanninja @davidlt @mcd500 do you know why 0x88000000 was choosen?

@pdp7 , sorry for late response I did not choose this, I just copied it from sifive-fu540.h (include/configs/sifive-unleashed.h for now), and this address is accessable for Starlight. so I just used it .

@tpetazzoni discovered that this did not work when building u-boot for BeagleV Starlight in upstream buildroot. Thomas created this patch to change fdt_addr_r to 0x90000000. https://github.com/buildroot/buildroot/blob/master/board/beaglev/patches/uboot/0001-include-configs-starfive-vic7100-adjust-fdt_addr_r.patch

I can confirm that the system does not boot without changing fdt_addr_r to 0x90000000.

Does anyone understand why fdt_addr_r=0x88000000 is only a problem for the buildroot setup?

my buildroot beaglev_defconfig is using:

* OpenSBI: [starfive-tech/opensbi@2524b0e](https://github.com/starfive-tech/opensbi/commit/2524b0ecd8684b42bc7a4c69794f40f11cbbe2a5) by @tekkamanninja

* u-boot: [93099a6](https://github.com/starfive-tech/u-boot/commit/93099a61c7b048ba1926152629284f8810cb6940) by @lbmeng  (plus the patch to change `fdt_addr_r` to `0x90000000`)

[trini]

To better understand the addresses used for fdt_addr_r / kernel_addr_r / etc in U-Boot, it helps to read https://www.kernel.org/doc/Documentation/arm64/booting.rst and unfortunately there's not a similar rST for RISC-V, but ti would be very helpful if someone with the knowledge could do that. In short, the kernel should be placed in memory so that any relocation to text_offset will not result in a problematic memmove, then the device tree needs to be within whatever range / alignment is dictated.

I suspect that 0x88000000 comes from the DEFAULT_LINUX_BOOT_ENV section of include/configs/ti_armv7_common.h which is a heavily commented list of addresses, albeit for arm32 to use that meet all of the constraints.