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 _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
