[U-Boot] [RFC PATCH 1/6] mtd: spi: Port SPI NOR framework from Linux

[Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>]

On 29.11.2018 19:52, Boris Brezillon wrote:
> On Thu, 29 Nov 2018 22:56:04 +0530
> Vignesh R <vigneshr@ti.com> wrote:
>
>>>> +const struct flash_info spi_nor_ids[] = {
>>>> +#ifdef CONFIG_SPI_FLASH_ATMEL		/* ATMEL */
>>>> +	/* Atmel -- some are (confusingly) marketed as "DataFlash" */
>>>> +	{ "at26df321",  INFO(0x1f4700, 0, 64 * 1024, 64, SECT_4K) },
>>>> +	{ "at25df321a", INFO(0x1f4701, 0, 64 * 1024, 64, SECT_4K) },
>>>> +
>>>> +	{ "at45db011d",	INFO(0x1f2200, 0, 64 * 1024,   4, SECT_4K) },
>>>> +	{ "at45db021d",	INFO(0x1f2300, 0, 64 * 1024,   8, SECT_4K) },
>>>> +	{ "at45db041d",	INFO(0x1f2400, 0, 64 * 1024,   8, SECT_4K) },
>>>> +	{ "at45db081d", INFO(0x1f2500, 0, 64 * 1024,  16, SECT_4K) },
>>>> +	{ "at45db161d",	INFO(0x1f2600, 0, 64 * 1024,  32, SECT_4K) },
>>>> +	{ "at45db321d",	INFO(0x1f2700, 0, 64 * 1024,  64, SECT_4K) },
>>>> +	{ "at45db641d",	INFO(0x1f2800, 0, 64 * 1024, 128, SECT_4K) },
>>>> +	{ "at26df081a", INFO(0x1f4501, 0, 64 * 1024,  16, SECT_4K) },
>>>> +#endif
>>> If you're really short in space (for the SPL build), you might want to
>>> consider fined-grained selection of the chips you want to support. One
>>> more reason to do that is that board manufacturers usually source SPI
>>> NOR parts from different vendors for the same design. With a
>>> per-manufacturer selection logic, you'll have to enable several of them
>>> to have an SPL that works on all variants.
>>>
>>> I didn't try, but you might be able to place each NOR chip in its own
>>> section and decide which one to keep at link time (will require some
>>> macros to define flash_info entries + a linker script to decide which
>>> sections you want to discard/keep at link time).
>>>    
>> IIUC, you are proposing per board linker script that will select/choose
>> which flash parts would to be supported by that board's SPL?
> Not exactly a per-board linker script. More something that would be
> automatically generated based on Kconfig option where you'd list all the
> NORs you want to support. Of course, the default would be to have
> everything enabled, but that allow people who have hard size
> constraint to shrink the spi-nor obj a bit more.

Just dropping the names (which are never used in SPL) gave me nearly 1K 
of code size reduction, but this was rejected:

https://patchwork.ozlabs.org/patch/980023/

Maybe we can doe this from the beginning when adding this new code?

Simon