
I have a Gumstix Overo (OMAP3) with a 512MiB NAND. I have been validating BCH8 ecc scheme and one of the problems I ran into is this:
arm-linux-gnueabi-ld.bfd: u-boot-spl section `.rodata' will not fit in region `.sram' arm-linux-gnueabi-ld.bfd: region `.sram' overflowed by 4092 bytes
This happens because BCH8 support increases the size of my SPL to larger than 54KiB defined by CONFIG_SPL_MAX_SIZE in ti_omap3_common.h.
My plan at the moment is to strip out unnecessary and unpopular features from SPL to save space. If I fail to fit my SPL under 54kiB, I'd like to know if it is safe to increase the size defined by config.
As per README.omap3, there is about 9KB (0x4020E000 - 0x4020BBFF) of unallocated space between the SPL data and SPL stack:
Option 2 (SPL or X-Loader): 0x40200800 - 0x4020BBFF: Area for SPL text, data and rodata 0x4020E000 - 0x4020FFFC: Area for the SPL stack.
Is this space being used for something? I'm sure there have been a good reason for this division. I would like to have some insight as to how and why.
Thanks,
Adam