lkml.org 
[lkml]   [2017]   [Aug]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] mtd: spi-nor: add support for Microchip sst26vf064b QSPI memory
From
Date


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/
>>
>

\
 
 \ /
  Last update: 2017-08-16 13:45    [W:0.091 / U:5.620 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site