[U-Boot] [PATCH v2 17/18] SPL: Enhance drivers/mtd/nand/nand_spl_load.c

[Tom Rini]

On Fri, Aug 24, 2012 at 04:30:45PM -0500, Scott Wood wrote:
> On 08/24/2012 04:20 PM, Tom Rini wrote:
> > On Fri, Aug 24, 2012 at 04:09:13PM -0500, Scott Wood wrote:
> >> On 08/20/2012 11:45 AM, Tom Rini wrote:
> >>> diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
> >>> index 29dc20e..5475c8c 100644
> >>> --- a/drivers/mtd/nand/Makefile
> >>> +++ b/drivers/mtd/nand/Makefile
> >>> @@ -27,12 +27,7 @@ LIB	:= $(obj)libnand.o
> >>>  
> >>>  ifdef CONFIG_CMD_NAND
> >>>  ifdef CONFIG_SPL_BUILD
> >>> -ifdef CONFIG_SPL_NAND_SIMPLE
> >>> -COBJS-y += nand_spl_simple.o
> >>> -endif
> >>> -ifdef CONFIG_SPL_NAND_LOAD
> >>> -COBJS-y	+= nand_spl_load.o
> >>> -endif
> >>> +COBJS-$(CONFIG_SPL_NAND_SIMPLE) += nand_spl_simple.o nand_spl_load.o
> >>
> >> OK, I was wrong, I will complain. :-)
> >>
> >> The commit message didn't mention you were changing
> >> CONFIG_SPL_NAND_SIMPLE.  That needs to be able to support small SPLs.
> >> Is your new "enhanced" nand_spl_load small enough (with proper
> >> configuration) to work with all the SPLs that currently use
> >> nand_spl/nand_boot.c (e.g. PPC 44x)?
> > 
> > OK, I suspect it would be close-to-fail.  There's a "few" bytes overhead
> > to parse the header and so forth, but it also allows for direct Linux
> > booting.  Is that something you want for these machines or no?
> 
> I don't think there's room for any new features at all.  The SPL must
> fit in 4K.  Canyonlands is at 4020 bytes currently.
> 
> Why can't the new functionality be conditionally built?

I'm not sure there would be a point.  The nand_boot() method is read
u-boot.bin from nand, read env from nand and read redundant env from
nand, boot u-boot.  The spl_nand_load_image method doesn't boot u-boot,
reads the image header, parses, reads the image.  In short, I don't
think a modified version would gain us anything more than a lot of
complex #ifdefs :(

> > It wouldn't be hard to put the enhanced version nand_spl_simple.c and leave
> > nand_spl_load.c alone.
> 
> nand_spl_simple.c is what I'm talking about needing to not expand.  Why
> does the new stuff need to be bound to a specific NAND boot implementation?

Sorry, I got it backwards.  I mean (and did locally) leave the very tiny
and simple approach alone, add to the version where we have a little,
but not a lot, of space.

-- 
Tom