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

[Scott Wood]

On 01/08/2012 03:56 AM, Mike Frysinger wrote:
> On Wednesday 04 January 2012 18:56:23 Scott Wood wrote:
>> On 12/05/2011 05:17 PM, Marek Vasut wrote:
>>> This will be beneficial for the PXA3XX NAND driver, which uses the NAND
>>> IDs to identify the chip and configure the controller accordingly.
>>>
>>> --- a/drivers/mtd/nand/Makefile
>>> +++ b/drivers/mtd/nand/Makefile
>>>
>>>  endif
>>>  else
>>>  COBJS-y += nand.o
>>> -COBJS-y += nand_bbt.o
>>> -COBJS-y += nand_ids.o
>>>  COBJS-y += nand_util.o
>>>  endif
>>> +COBJS-y += nand_bbt.o
>>> +COBJS-y += nand_ids.o
>>>  COBJS-y += nand_ecc.o
>>>  COBJS-y += nand_base.o
>>
>> So, in theory with gc-sections this shouldn't increase the size of any
>> SPL that currently successfully links (at least in the absence of things
>> like weak symbols).  However, I observed a devkit8000 build go from this:
>>
>>    text    data     bss     dec     hex filename
>>   40709    1792  197764  240265   3aa89 /tmp/u-boot-arm/spl/u-boot-spl
>>
>> to this:
>>
>>    text    data     bss     dec     hex filename
>>   42277    1792  197764  241833   3b0a9 /tmp/u-boot-arm/spl/u-boot-spl
>>
>> I verified that --function-sections/-fdata-sections/--gc-sections are
>> being used on the SPL.  It looks like strings are not getting dropped.
> 
> specifically, "anonymous" strings (or whatever the term is).  it could be made 
> to work, but it'd be ugly.  something like:
> 
> --- a/drivers/mtd/nand/nand_ids.c
> +++ b/drivers/mtd/nand/nand_ids.c
> @@ -22,6 +22,12 @@
>  +	256	256 Byte page size
>  *	512	512 Byte page size
>  */
> +
> +static const char nand_16mib_18v_8bit[] = "NAND 16MiB 1,8V 8-bit";
> +static const char nand_16mib_33v_8bit[] = "NAND 16MiB 3,3V 8-bit";
> +static const char nand_16mib_18v_16bit[] = "NAND 16MiB 1,8V 16-bit";
> +static const char nand_16mib_33v_16bit[] = "NAND 16MiB 3,3V 16-bit";
> +
>  const struct nand_flash_dev nand_flash_ids[] = {
>  
>  #ifdef CONFIG_MTD_NAND_MUSEUM_IDS
> @@ -42,10 +48,10 @@
>  	{"NAND 8MiB 3,3V 16-bit",	0x59, 512, 8, 0x2000, NAND_BUSWIDTH_16},
>  #endif
>  
> -	{"NAND 16MiB 1,8V 8-bit",	0x33, 512, 16, 0x4000, 0},
> -	{"NAND 16MiB 3,3V 8-bit",	0x73, 512, 16, 0x4000, 0},
> -	{"NAND 16MiB 1,8V 16-bit",	0x43, 512, 16, 0x4000, NAND_BUSWIDTH_16},
> -	{"NAND 16MiB 3,3V 16-bit",	0x53, 512, 16, 0x4000, NAND_BUSWIDTH_16},
> +	{nand_16mib_18v_8bit,	0x33, 512, 16, 0x4000, 0},
> +	{nand_16mib_33v_8bit,	0x73, 512, 16, 0x4000, 0},
> +	{nand_16mib_18v_16bit,	0x43, 512, 16, 0x4000, NAND_BUSWIDTH_16},
> +	{nand_16mib_33v_16bit,	0x53, 512, 16, 0x4000, NAND_BUSWIDTH_16},
>  
>  	{"NAND 32MiB 1,8V 8-bit",	0x35, 512, 32, 0x4000, 0},
>  	{"NAND 32MiB 3,3V 8-bit",	0x75, 512, 32, 0x4000, 0},

Ugly, and we'd get regressions every time someone adds a new anonymous
string that pushes an SPL over the limit.

Unless/until the toolchain can properly GC anonymous strings, I think
finer-grained conditional compilation is the way to go.

-Scott