On Thu, Jan 5, 2012 at 4:04 PM, Scott Wood <scottw...@freescale.com> wrote: > On 01/05/2012 08:15 AM, Tom Rini wrote: >> On Thu, Jan 5, 2012 at 2:09 AM, Marek Vasut <marek.va...@gmail.com> wrote: >>>> I'll confirm gc-sections/etc are not as awesome as we think. You can >>>> drop the size of current SPL builds (for say devkit8000) by taking >>>> things that should be dropped for us and forcing them out with #ifndef >>>> CONFIG_SPL_BUILD. >>> >>> Maybe if we had those LTO tables at the gc-sections time, it'd drop. But we >>> can't rely on those. >>> >>> So instead of compiling in the nand-ids, it'd be better to allow SPL to >>> pull in >>> the whole NAND/MTD stack. >> >> Possible, but without doing #Ifndef hacks, the size grows a good bit >> (don't have the #s handy right now), and with #ifndef hacks it's just >> a kb or so in growth. > > 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. -- Tom _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
