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