-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/19/2013 11:41 AM, Philip Paeps wrote:
On 2013-04-19 17:21:49 (+0200), Benoît Thébaudeau benoit.thebaudeau@advansee.com wrote:
On Friday, April 19, 2013 5:09:59 PM,Philip Paeps wrote:
On 2013-04-19 16:48:42 (+0200), Philip Paeps philip@paeps.cx wrote:
A first build with CONFIG_SPL_FRAMEWORK came out to nearly 4K. Large contributors being (unsurprisingly) libcommon and libgeneric. I had to get rid of a puts() in libspl to make it build without those libraries. Unfortunately, that still came out to 2.2K. Close. :-)
I couldn't identify any obvious 100 bytes to scrap from glancing at u-boot-spl.map or objdump -D u-boot-spl, but I'll take a look.
Just as I hit 'send', it occurred to me that this configuration is with a fairly lengthy lowlevel_init.S to support external boot. Paring that to the bare minimum gives a u-boot-spl.bin of 1821 bytes.
But this requires a board-specific lowlevel_init() and a hack for puts() (which is perhaps already solved by Andreas' series), just to bloat the SPL with stuff useless for those boards, vs. a simple nand_boot() that can be made common to all SPLs with size restrictions.
Comparing the contents of "framework" SPL with "old" SPL, it looks like the only thing we gain is support for booting uImage files. At the cost of significantly reduced room for flexibility in lowlevel_init().
I agree that a simple nand_boot() is probably the way forward.
Note that PowerPC has had to deal with this as well, see drivers/mtd/nand/fsl_elbc_spl.c and I suspect some amount of that should be made more easily borrowable for the case where SPL doesn't (or can't/won't) deal with image headers.
- -- Tom