Okay, and if you're writing to 0x800000 later you're clobbering any image bigger than 0x7F0000.
Not a problem, the last 64Kbytes are empty in every tested kernel and, just to be sure it's not the problem, the tested kernel was compiled with "space optimization" with a size of
7.5 MBHowever, although the size is 7.5MB, even this kernel doesn't boot when load_addr="0x0090.0000", no matter where you tftpload it in ram, in fact, I have just modified u-boot to disable the FPGA so I reassigned its ram up to 0x0400.0000, and tftploading at 0x0100.0000 and 0x0200.0000 doesn't solve anything.
this doesn't work:
tftpload uImage (not compressed) -> 0x0200.0000
bootm from 0x0200.0000, copies the wrapper (7.5MB) into 0x0090.0000 (load_addr)
the wrapper copies the kernel into 0x0000.0000 and invokes kentry
the kernel dies immediately without showing anything
this does work:
tftpload uImage (not compressed) -> 0x0200.0000
bootm from 0x0200.0000, copies the wrapper (7.5MB) into 0x0080.0000 (load_addr)
the wrapper copies the kernel into 0x0000.0000 and invokes kentry
the kernel boots
Here the problem is somehow related to
load_addrI also tried load_addr =
{
0x0081.0000 8M + 64K -> it works
0x0082.0000 8M + 128K -> it works
0x0084.0000 8M + 256K -> it works
0x0088.0000 8M + 512K -> it works
0x0090.0000 8M + 1M -> it doesn't works
}