[U-Boot] [PATCH 2/6] nand: Add SPL_NAND support to mxc_nand_spl

["Benoît Thébaudeau" <benoit.thebaudeau@advansee.com>]

Hi Philip,

On Friday, April 19, 2013 4:48:42 PM, Philip Paeps 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.

Cool. But don't forget that the build must also succeed whatever the toolchain,
so there must be a margin on the 2 kiB, perhaps 5% to 10%.

Another way around could be to just move nand_boot() to a more generic SPL
location so that other hardware having minimal SPL size requirements can use it
without duplicating it. As to hang(), it has already been handled by Andreas.

Best regards,
Beno?t