Merge lp:~jcrigby/linaro-image-tools/mx51-initrd_addr-fix into lp:linaro-image-tools/11.11

[John Rigby]

This fixes bug #737321.

[Guilherme Salgado (salgado)]

Do we really need 128M or would 22M (like the omaps) be enough?

[Loïc Minier (lool)]

There's a trivial conflict with lp:~lool/linaro-image-tools/efikasb-support which I just landed, but this change looks simple enough.

John, I'd like to add some tests to ensure we reserve enough memory between kernel and initrd, but I wonder:
* can we expect the initrd address to always be higher than the kernel address?
* how many MiBs should we make sure are reserved?
* we currently run "mkimage -a load_addr -e load_addr" to generate uImage and we generate a boot.scr which has "fatload mmc kernel_addr uImage", and we run "mkimage -a 0 -e 0" to generate uInitrd and use "fatload mmc initrd_addr uInitrd"; could you advise on whether we should test kernel_addr + some M < initrd_addr, or load_addr + some M < initrd_addr or both?

In general, if you could advise on what tests would be sensible, that would be welcome; but we can merge this test right now obviously.

review: Approve

[Loïc Minier (lool)]

On Fri, Mar 18, 2011, Guilherme Salgado wrote:
> Do we really need 128M or would 22M (like the omaps) be enough?

 Some smaller offset would be enough, but I am not sure it matters, I
 think the same amount of memory is available in both cases, but I'm not
 sure whether the kernel and initrd relocate themselves, so maybe there
 is less contiguous memory if we take a larger offset -- not sure

--
Loïc Minier

[John Rigby (jcrigby)]

No we don't need 128M. The arm kernel actually reserves the initrd location early in the boot process but apparently not early enough. The scenario that failed for me had the initrd loaded above the kernel including all the bss so at first I thought the larger kernel was not the problem. I then realized that early in the boot process the kernel does allocate some boot memory. Those early allocations before the initrd memory is reserved are apparently the problem.

I believe the test should be for both kernel_addr + some M and load_addr + some M. Also if there is ever a platform that loads the initrd before the kernel and the initrd image was too large it could corrupt the kernel. Not sure if that future proofing is worth it.

For modern u-boot's (not the LT ones that are not 2010.12 or later) u-boot relocates itself to the top of ram - size calculated at runtime. For that case the best place to put the initrd is top of ram - max size of u-boot runtime - max size of initrd.

This is all really a bug in arm u-boot. PPC u-boot does this relocation for you. In fact I enabled this for ARM when adding DT support but it is only turned on with DT.

[John Rigby (jcrigby)]

One more thing. Certain platforms (not sure if any of our currently supported ones) init a framebuffer in u-boot and put a splash screen there. They then pass address of framebuffer to the kernel. So obviously this address range is another one that needs to be avoided.

[Loïc Minier (lool)]

Since I didn't want to leave this mp open for too long when there's an useful fix, I've merged your commit but changed the initrd address to 0x92000000 to be 32 MiB away of the kernel.

I checked other boards and they used these offsets before the change:
Beagle, Overo: 22MiB
Panda: 20 MiB
Ux500: 127 MiB
Mx51: 8 MiB
Mx53: 16 MiB
Vexpress: ~528 MiB
SMDKV310: ~16 MiB

I filed LP #744539 to remember to implement the checks.

=== modified file 'linaro_media_create/boards.py'
--- linaro_media_create/boards.py	2011-03-10 23:28:21 +0000
+++ linaro_media_create/boards.py	2011-03-18 04:07:07 +0000
@@ -418,7 +418,7 @@
     extra_serial_opts = 'console=tty0 console=%s,115200n8' % serial_tty
     live_serial_opts = 'serialtty=%s' % serial_tty
     kernel_addr = '0x90000000'
-    initrd_addr = '0x90800000'
+    initrd_addr = '0x98000000'
     load_addr = '0x90008000'
     kernel_suffix = 'linaro-mx51'
     boot_script = 'boot.scr'