Messages in this thread |  | | Subject | Re: [PATCH] mtd: spi-nor: add support for Microchip sst26vf064b QSPI memory | From | m18063 <> | Date | Wed, 16 Aug 2017 14:43:31 +0300 |
| |
On 14.08.2017 19:03, Cyrille Pitchen wrote: > Le 01/08/2017 à 23:57, Cyrille Pitchen a écrit : >> 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) }, >> > > Looking at the erase sector map in the SST26VF064B datasheet, the > info->sector_size should be set to 64 * 1024 instead of 4 * 1024. > > The 20h op code is supported uniformly to erase 4K sectors so the > SECT_4K flag will work just as expected with > CONFIG_MTD_SPI_NOR_USE_4K_SECTORS defined. > > On the other hand, when CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is undefined, > the D8h op code is used instead of the 20h op code for erase operations. > Then, for this op code, the memory layout of SST26 memories is: > > +------------+ > | 8K | > +------------+ > | 8K | > +------------+ > | 8K | > +------------+ > | 8K | > +------------+ > | 32K | > +------------+ > | 64K | > +------------+ > | 64K | > +------------+ > | ... | > +------------+ > | 64K | > +------------+ > | 64K | > +------------+ > | 32K | > +------------+ > | 8K | > +------------+ > | 8K | > +------------+ > | 8K | > +------------+ > | 8K | > +------------+ > > Hence if we set info->sector_size to 64K, the D8h op code would work as > expected for all but the first and last 64K blocks. > For now, we would fail to properly erase the whole first and last 64 > blocks but I think this issue should be fixed later when adding support > to the erase sector map provided by some SFDP table. > Indeed, it would be possible to erase the first and last 64K blocks and > pretend the memory is also uniform for 64K sector size since > 4 * 8 + 32 == 64 > > So please, just resend your patch with 64 * 1024 instead of 4 * 1024 :) > Thanks, Cyrille! I will send a v2 with your proposals.
Claudiu
> I think this is currently the best we can reach without support of non > uniform erase map. > > Best regards, > > Cyrille > > >> 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) }, >>> >> >> >> ______________________________________________________ >> Linux MTD discussion mailing list >> http://lists.infradead.org/mailman/listinfo/linux-mtd/ >> >
|  |