On 26/03/2020 02:38, Tom Rini wrote: Hi,
> On Wed, Mar 25, 2020 at 02:46:56PM +0000, Andre Przywara wrote: > >> The U-Boot documentation explains that variables ending with "_r" hold >> addresses in DRAM, while those without that ending point to flash/ROM. >> The default variables for the Juno board pointing to the kernel and DTB >> load addresses were not complying with this scheme: they lack the >> extension, but point to DRAM. This is particularly confusing since the >> Juno board features parallel NOR flash, so there *is* a memory mapped >> NOR address holding a DTB, for instance. >> >> Fix the variables to use the proper names. On the way adjust the FDT >> load address to be situated *before* the kernel, since users happened >> to overwrite the DTB by the kernel clearing its .BSS section during >> initialisation. >> >> That fixes loading debug kernels, which happened to overwrite the DTB on >> certain setups. >> >> Signed-off-by: Andre Przywara <andre.przyw...@arm.com> >> Reviewed-by: Liviu Dudau <liviu.du...@arm.com> > [snip] >> - "fdt_addr=0x83000000\0" \ >> + "fdt_addr_r=0x80000000\0" \ >> "fdt_high=0xffffffffffffffff\0" \ >> "initrd_high=0xffffffffffffffff\0" \ > > On a related note, using fdt_high=0xff... to disable relocation is a bad > idea and can lead to U-Boot knowing we have it at an invalid (unaligned) > location but doing nothing and causing problems down the chain. Please > use bootm_size or similar (documented in the README, still) to limit > where the fdt can be. Thanks! Thanks, looks like I will drop this then. arm64 kernels before 4.2 had a limit of placing the DTB with 512MB of the kernel image, but this has been lifted since then. I might address this later shall people complain. On a related note: I just see we use initrd_* variables here, where there are more users of ramdisk_addr*. Shall I fix this here as well? Seems like only ramdisk_addr* is mentioned in README. Cheers, Andre
