[PATCH 1/7] arm: juno: Fix Juno address variables

[André Przywara]

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.przywara at arm.com>
>> Reviewed-by: Liviu Dudau <liviu.dudau at 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