All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@bootlin.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC PATCH 1/6] mtd: spi: Port SPI NOR framework from Linux
Date: Thu, 29 Nov 2018 19:52:21 +0100	[thread overview]
Message-ID: <20181129195221.4dcc3cd8@bbrezillon> (raw)
In-Reply-To: <4faf9589-3324-449c-261a-2573b865844d@ti.com>

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.

  reply	other threads:[~2018-11-29 18:52 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-28 17:26 [U-Boot] [RFC PATCH 0/6] SF: Migrate to Linux SPI NOR framework Vignesh R
2018-11-28 17:26 ` [U-Boot] [RFC PATCH 1/6] mtd: spi: Port SPI NOR framework from Linux Vignesh R
2018-11-29 16:04   ` Boris Brezillon
2018-11-29 17:26     ` Vignesh R
2018-11-29 18:52       ` Boris Brezillon [this message]
2018-11-29 19:11         ` Simon Goldschmidt
2018-11-28 17:26 ` [U-Boot] [RFC PATCH 2/6] mtd spi: Switch to new SPI NOR framework Vignesh R
2018-11-28 17:26 ` [U-Boot] [RFC PATCH 3/6] spi: spi-mem: Enable all SPI modes Vignesh R
2018-11-28 17:26 ` [U-Boot] [RFC PATCH 4/6] porter_defconfig: Enable tiny printf Vignesh R
2018-11-28 17:52   ` Marek Vasut
2018-11-28 20:34     ` Simon Goldschmidt
2018-11-28 21:50       ` Marek Vasut
2018-11-29 10:44         ` Vignesh R
2018-11-29 10:56           ` Miquel Raynal
2018-11-29 11:18             ` Simon Goldschmidt
2018-11-29 15:47               ` Vignesh R
2018-11-29 11:23           ` Marek Vasut
2018-11-28 17:26 ` [U-Boot] [RFC PATCH 5/6] da8250_am18xxevm_defconfig: Enable TINY PRINTF Vignesh R
2018-11-28 17:26 ` [U-Boot] [RFC PATCH 6/6] mtd: spi: Remove unused files Vignesh R
2018-11-28 20:27 ` [U-Boot] [RFC PATCH 0/6] SF: Migrate to Linux SPI NOR framework Simon Goldschmidt
2018-11-29 10:20 ` Stefan Roese
2018-11-29 11:21   ` Simon Goldschmidt
2018-11-29 15:22 ` Tom Rini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181129195221.4dcc3cd8@bbrezillon \
    --to=boris.brezillon@bootlin.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.