Add support for Microchip sst26vf064b QSPI memory.
Signed-off-by: Claudiu Beznea <[email protected]>
---
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) },
/* ST Microelectronics -- newer production may have feature updates */
{ "m25p05", INFO(0x202010, 0, 32 * 1024, 2, 0) },
--
2.7.4
Hi Claudiu,
Le 28/07/2017 à 11:41, Claudiu Beznea a écrit :
> Add support for Microchip sst26vf064b QSPI memory.
>
> Signed-off-by: Claudiu Beznea <[email protected]>
> ---
> 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) },
>
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 <[email protected]>
>> ---
>> 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 :)
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/
>
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 <[email protected]>
>>> ---
>>> 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/
>>
>