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

[Tom Rini]

On Thu, Mar 26, 2020 at 04:14:03PM +0000, André Przywara wrote:
> 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.

Thanks.
 
> 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.

initrd_high is the other "do not relocate" variable.  For anything else,
yes, matching other platforms so that distro boot can be used at some
point (I assume it's not on Juno today) would be good.

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