Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1701532 > unrolled thread

Re: [PATCH] mtd: spi-nor: add support for Microchip sst26vf064b QSPI memory

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] mtd: spi-nor: add support for Microchip sst26vf064b QSPI  memory Cyrille Pitchen <cyrille.pitchen@wedev4u.fr> - 2017-08-02 00:00 +0200

#1701532 — Re: [PATCH] mtd: spi-nor: add support for Microchip sst26vf064b QSPI memory

Hi Claudiu,

Le 28/07/2017 à 11:41, Claudiu Beznea a écrit :
> Add support for Microchip sst26vf064b QSPI memory.
> 
> Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
> ---
>  drivers/mtd/spi-nor/spi-nor.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index 196b52f..796aac4 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -1081,6 +1081,7 @@ static const struct flash_info spi_nor_ids[] = {
>  	{ "sst25wf040b", INFO(0x621613, 0, 64 * 1024,  8, SECT_4K) },
>  	{ "sst25wf040",  INFO(0xbf2504, 0, 64 * 1024,  8, SECT_4K | SST_WRITE) },
>  	{ "sst25wf080",  INFO(0xbf2505, 0, 64 * 1024, 16, SECT_4K | SST_WRITE) },
> +	{ "sst26vf064b", INFO(0xbf2643, 0,  4 * 1024, 2048, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },

I don't know what to do in this case; Marek any advice?

The issue is that Microchip SST26 memories are uniform for the 4K erase
sector size but not uniform for other sector sizes (32K, 64K, ...).

Like this, erase operations would work if
CONFIG_MTD_SPI_NOR_USE_4K_SECTOR is defined because then the 20h/21h
opcodes would be used in any case.

However when the former macro is undefined, the D8h/DCh opcodes would be
used instead. Hence erasing sectors in the middle of the memory would
not work as expected because nor->mtd.erasesize == 4 * 1024 but the
actual erase size of middle erase blocks/sectors is bigger: you may
erase more than expected.

Marek, do you think we could take this patch as is, with the known
limitations, and wait for a later patch dealing with non-uniform erase
sector map to fix them?

Also, nor->mtd.erasesize is used by above mtd layer like UBIFS to decide
the size of the Physical and Logical Erase Bloc size. Not sure if this
is still true now but I had troubles the last time I've tried to create
a UBI file-system with a spi-nor memory using a 4K erase sector size

http://lists.infradead.org/pipermail/linux-mtd/2013-July/047665.html

Best regards,

Cyrille


>  
>  	/* ST Microelectronics -- newer production may have feature updates */
>  	{ "m25p05",  INFO(0x202010,  0,  32 * 1024,   2, 0) },
> 

[toc] | [standalone]

Back to top | Article view | linux.kernel

csiph-web