From mboxrd@z Thu Jan  1 00:00:00 1970
From: Boris Brezillon <boris.brezillon@bootlin.com>
Date: Thu, 29 Nov 2018 19:52:21 +0100
Subject: [U-Boot] [RFC PATCH 1/6] mtd: spi: Port SPI NOR framework from
	Linux
In-Reply-To: <4faf9589-3324-449c-261a-2573b865844d@ti.com>
References: <20181128172607.10179-1-vigneshr@ti.com>
 <20181128172607.10179-2-vigneshr@ti.com>
 <20181129170434.6db57b74@bbrezillon>
 <4faf9589-3324-449c-261a-2573b865844d@ti.com>
Message-ID: <20181129195221.4dcc3cd8@bbrezillon>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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.