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

Open Source and information security mailing list archives

Message-ID: <443a6b01-a8f0-198e-e6bf-c8693a177f45@microchip.com>
Date:   Wed, 16 Aug 2017 14:43:31 +0300
From:   m18063 <Claudiu.Beznea@...rochip.com>
To:     Cyrille Pitchen <cyrille.pitchen@...ev4u.fr>,
        <marek.vasut@...il.com>, <dwmw2@...radead.org>,
        <computersforpeace@...il.com>,
        <boris.brezillon@...e-electrons.com>, <richard@....at>
CC:     <linux-mtd@...ts.infradead.org>, <linux-kernel@...r.kernel.org>,
        <nicolas.ferre@...rochip.com>
Subject: Re: [PATCH] mtd: spi-nor: add support for Microchip sst26vf064b QSPI
 memory


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@...rochip.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/
>>
>

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives