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? > 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? -Scott _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
