Comment 9 for bug 517841

Root caused the initramfs issue, actually caused by zImage being
decompressed and the initramfs data area is overwritten. After modifying
kexec-tools to load initramfs to some place far away from where the
decompressing of zImage and relocation of kernel happens, it now boots
OK. A bad co-work between kexec and zImage!

The layout is basically as follows (offset is based against physical DRAM
starting address):

0x0000_0000 +------------+
           | Not Used |
0x0000_1000 +------------+
           | ATAGS |
0x0000_8000 +------------+
           | |
           | |
           | zImage |
           | |
                ...
                ...
           | |
0x0080_0000 +------------+
           | |
           | |
           | initrd |
           | |
           | |

0x0000_8000 - 0x0080_0000 is reserved for zImage, decompressing will
possibly overwrite the initrd area if zImage is large enough (which is true
in our case). My trial of moving initrd from 0x0080_0000 to 0x0800_0000
solved this issue.

So there are actually two workarounds:

1. a modified kexec, which put initramfs data far behind the zImage area
2. loading an executable vmlinux directly instead of using zImage, thus
no decompressing involved (saving some time to decompress), and no
overwriting will occur.

Option 2) may require some time to work and verify so a quick and dirty
solution would be 1).

And this apparently affects imx51 as well.