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@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).