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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
