Removing "fdt_high=0xffffffff" from board environments

[Tom Rini]

On Tue, Jan 28, 2020 at 10:48:29AM -0500, Tom Rini wrote:

> Hey all,
> 
> Relatively recently it's been highlighted that a number of boards are
> disabling relocation of the device tree image in memory and this in turn
> leading to various difficult to resolve bugs.  At heart, disabling
> device tree relocation at boot is something that should be used in rare
> circumstances (and more generally fdt_high / initrd_high set to where
> they are already residing in memory, as a known, correct and aligned
> address).
> 
> I would like to ask everyone to update their board config file to use
> the bootm_size (or set CONFIG_SYS_BOOTMAPSZ) to the amount of memory
> (size, not location) available to safely contain a kernel, device tree
> and initrd for relocation.  Thanks all!

To offer a additional guidance here, in
include/configs/ti_armv7_common.h I did the following a while ago:
/*
 * We setup defaults based on constraints from the Linux kernel, which should
 * also be safe elsewhere.  We have the default load at 32MB into DDR (for
 * the kernel), FDT above 128MB (the maximum location for the end of the
 * kernel), and the ramdisk 512KB above that (allowing for hopefully never
 * seen large trees).  We say all of this must be within the first 256MB
 * as that will normally be within the kernel lowmem and thus visible via
 * bootm_size and we only run on platforms with 256MB or more of memory.
 */
#define DEFAULT_LINUX_BOOT_ENV \
        "loadaddr=0x82000000\0" \
        "kernel_addr_r=0x82000000\0" \
        "fdtaddr=0x88000000\0" \
        "fdt_addr_r=0x88000000\0" \
        "rdaddr=0x88080000\0" \
        "ramdisk_addr_r=0x88080000\0" \
        "scriptaddr=0x80000000\0" \
        "pxefile_addr_r=0x80100000\0" \
        "bootm_size=0x10000000\0" \
        "boot_fdt=try\0
Note that these platforms have a DRAM base of 0x8000_0000.  The offsets
described above are based on Documentation/arm/booting.rst in the Linux
Kernel and were the best-generic-fit I could come up with given those
constraints and suggestions.  I don't know of a best-practices example
for arm64 platforms right now.  While I believe that cmd/booti.c makes
sure to follow the requirements of Documentation/arm64/booting.rst it
would be good to audit it again for any recent updates.

Hope this helps and thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200129/1f03d17e/attachment.sig>