On Friday, April 19, 2013 5:21:49 PM, Benoît Thébaudeau wrote:
Hi Philip,
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:
On 2013-04-19 15:00:13 (+0200), Philip Paeps philip@paeps.cx wrote:
On 2013-04-19 06:10:51 (+0200), Marek Vasut marex@denx.de wrote:
To avoid the old function which are used with the nand_spl/ stuff getting in the way of NAND SPL framework, the macro CONFIG_SPL_NAND_LEGACY was introduced and two remaining legacy boards were adjusted. These board need to be either fixed or removed in the long run, but I don't have either.
It sounds like "fixing" these boards is mainly a matter of confirming that a configuration for them based around CONFIG_SPL_FRAMEWORK will fit in 2K. If so, I don't think there is any reason to keep legacy support around.
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.
Or, with Andreas' series to get rid of puts(), and with an option to make the use of spl_parse_image_header() an option (i.e. to be able to force raw binary SPL payload format), the change would be almost equivalent to using the current nand_boot(), so the size should follow.
Best regards, Benoît