[U-Boot] [PATCH RFC] common/image: Allow initrd_high & fdt_high to have special case no_reloc

[Tom Rini]

On Wed, Jan 18, 2017 at 02:50:28AM +0200, Tuomas Tynkkynen wrote:

> The documented way of disabling relocation of the initrd or FDT is
> setting initrd_high or fdt_high to 0xffffffff.
> However, that is actually wrong on 64-bit platforms, where
> 0xffffffffffffffff needs to be used. This is somewhat painful:
> 
>  - Some platforms (e.g. Raspberry Pi) have a common file setting fdt_high
>    or initrd_high to 0xffffffff that is included in both 32-bit builds
>    (RPi 1, 2) and 64-bit builds (RPi 3). Those are currently not doing
>    the right thing in 64-bit builds, and it wouldn't be nice to #ifdef
>    around that.
>  - Typing the 16 consecutive f's in 0xffffffffffffffff is not very
>    pleasant.
> 
> To fix these, make the initrd_high and fdt_high handling accept a special
> value "no_reloc" that does the right thing independent of the bitness.
> The old values keep working for compatibility.
> 
> Signed-off-by: Tuomas Tynkkynen <tuomas at tuxera.com>

I don't like this, in concept.  The general answer is that one should
not set initrd_high / fdt_high to disabled.  In specific and optimized
cases where one knows that there is no potential for overlap one would
load parts to the desired location and disable relocation.  But in
general I'm going to quote myself from
include/configs/ti_armv7_common.h:
/*
 * 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.
 */

The problem I have with disabling relocation is how often I've seen
people run into the problem of big kernel / big initrd / big fdt
stomping over one of the other parts of the system (most often kernel
BSS runs over whatever followed the kernel).

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170120/ad1a2f85/attachment.sig>