The default kernel loadaddr=0x84000000.
The default ramdisk_addr_r=0x83200000.
That leaves only 14MB for an initramfs. I’d suggest moving the kernel up to 0x85000000.
That leaves about 30MB which os more than enough. Seems to work fine with just setting the loadaddr=0x85000000 in u-boot and saving the environment but updating u-boot with the new default would make it survive a flash.
EDIT: Of course, you could also move the kernel lower and move the ramdisk after the kernel.
Hi,
We moved the ramdisk address back in last year due to a bug in which uboot couldn’t support large kernel. Thus, if we change the ramdisk/kernel address to support large initrd, we may probably hit that problem again.
Since you already had a fix for your system, you can use that as your permanent solution.
Ah. What specifically was the uboot issue? Was it that the kernel was extending into a memory region uboot wasn’t happy with? Do you happen to know what the limit was?
Hi, @gtj
I made the U-Boot change, and as I remember it, we had some huge test kernels (w/debug symbols, or stack-check/code coverage assist, etc., don’t remember what exactly), and when loaded by U-Boot the kernel would overwrite the DTB address(es). What we have now works up to a 120MB kernel. I couldn’t move the fdt_addr because it comes from CBoot, so I had to massage the other addresses.
Since you have the U-Boot source, you can adjust these as you wish, or use a preboot script/env load to adjust the kernel & ramdisk addresses. You can also adjust them from U-Boot using setenv, then save them using saveenv, but they’ll change back again if you do a full flash/wipe out the env portion in QSPI.
HTH,
Tom
Thanks Tom. That’s good info.