[U-Boot] [PATCH] NAND: Allow nand_ids and nand_bbt to be compiled in SPL

Tom Rini tom.rini at gmail.com
Fri Jan 6 01:41:41 CET 2012


On Thu, Jan 5, 2012 at 4:04 PM, Scott Wood <scottwood at 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.vasut at 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


More information about the U-Boot mailing list