Linux kernel hanging in iMX7 with big images

Hi!

Anyone experienced an issue while loading the kernel with the settings below?
fdt_addr_r=0x82000000
kernel_addr_r=0x81000000
loadaddr=0x80800000

The question is: how big can an image get while continuing to work without hang right after “Starting kernel”?

We’re using the following commands to start the kernel(loading through tftp to RAM):
tftp ${fdt_addr_r} iris_imx7.dtb && tftp ${kernel_addr_r} zImage && tftp ${loadaddr} hello_world.elf && bootaux ${loadaddr} && bootz ${kernel_addr_r} - ${fdt_addr_r}

When the image size gets close to 15MB, the kernel starts to hang. The reason?

The kernel by default unpacks itself to 0x80008000. At some point the unpack process will overwrite the not yet unpacked kernel. Since 0x81000000−0x80008000 is just under 16MiB this is the size where it starts to get problematic.

You need to set the kernel_addr_r higher to use larger kernels.

Didn’t know that the address to unpacking was 0x80008000. Thanks!
Curious that we just changed the fdt_addr_r to 0x83000000 and it worked.
So, the space from kernel unpacking address to kernel_addr_r need to be the same size of kernel_addr_r to fdt_addr_r. Right?
And what about the M4 app, which is loaded into loadaddr (0x80800000)? Won’t it be at same space of kernel?
Can you provide us the suggested addresses to avoid trouble?
Thanks again!

I actually realized that the kernel is smart about overwriting itself during uncompressing: The kernel would relocate itself before uncompressing, see head.S of the compressor code.

Your observation make sense. If your compressed kernel is more than 16MB, then it is already U-Boot which overwrites the device tree (since the image gets loaded second)…

Thanks for your answer. Any idea about the addresses(fdt_addr_r, kernel_addr_r and loadaddr) to use for an uImage with 15MB of size to prevent any data overwrite?

Just shifting everything after kernel_addr_r should be fine. E.g. fdt_addr_r=0x83000000 and ramdisk_addr_r=0x83100000.