On Fri, Jan 6, 2012 at 12:03 PM, Scott Wood <[email protected]> wrote: > On 01/05/2012 06:41 PM, Tom Rini wrote: >> On Thu, Jan 5, 2012 at 4:04 PM, Scott Wood <[email protected]> wrote: >>> Whatever the set of things is that you want to pull in for these SPLs, >>> it needs to be a separate config option from the one that enables >>> libnand.o to be included, so that other SPLs can pull in smaller NAND >>> implementations. >>> >>> Is there any reason to keep defines like CONFIG_SPL_NAND_SUPPORT (versus >>> LIBS-y += drivers/mtd/nand/libnand.o), if everything within that >>> directory needs a separate config symbol to enable it inside an SPL >>> (just like a normal build)? >> >> I think you've got it backwards. What CONFIG_SPL_NAND_SUPPORT enables >> today is more bloated than required as our 'magic' isn't working. > > I realize this isn't the case today -- but it's where we need to go, > since gc-sections doesn't do the job. I was saying that I think we can > get rid of CONFIG_SPL_NAND_SUPPORT once we change to a model where every > bit of code within the directory needs some other config symbol to pull > it in.
Ah, OK. But maybe this also means we need to rethink other parts of SPL too? I'd imagine this isn't a NAND subsystem specific issue we're running into. -- Tom _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
