[PATCH v4 0/6] mtd: spi-nor: Add support for Cypress s25hl-t/s25hs-t

[Takahiro Kuwano]

On 4/8/2021 2:35 PM, Tudor.Ambarus at microchip.com wrote:
> On 4/2/21 10:13 AM, Takahiro Kuwano wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>
>> Hi Tudor,
> 
> Hi!
> 
>>
>> On 4/1/2021 3:09 PM, Tudor.Ambarus at microchip.com wrote:
>>> Hi,
>>>
>>> On 3/19/21 8:51 AM, tkuw584924 at gmail.com wrote:
>>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>>>
>>>> From: Takahiro Kuwano <Takahiro.Kuwano at infineon.com>
>>>>
>>>> The S25HL-T/S25HS-T family is the Cypress Semper Flash with Quad SPI.
>>>>
>>>> The summary datasheets can be found in the following links.
>>>> https://www.cypress.com/file/424146/download (256Mb/512Mb/1Gb, single die)
>>>> https://www.cypress.com/file/499246/download (2Gb/4Gb, dual/quad die)
>>>>
>>>> The full version can be found in the following links (registration
>>>> required).
>>>> https://community.cypress.com/t5/Semper-Flash-Access-Program/Datasheet-Semper-Flash-with-Quad-SPI/ta-p/260789?attachment-id=19522
>>>> https://community.cypress.com/t5/Semper-Flash-Access-Program/Datasheet-2Gb-MCP-Semper-Flash-with-Quad-SPI/ta-p/260823?attachment-id=29503
>>>
>>> Takahiro, looks like I can't access the dual/quad die full datasheet, not enough rights,
>>> even after creating an account.
>>>
>> My colleague helped on this. I hope you could access the datasheet.
> 
> Takahiro, I can now access the datasheet, thanks! I see that Erase Chip
> requires an address. Is the erase chip with address common to other
> manufacturers? We'll have to update the core so that these flashe
> benefit of the erase chip opcode. Otherwise we'll have to set
> SNOR_F_NO_OP_CHIP_ERASE at flash declaration, which I don't really favor.
> 
I overlooked the erase chip for multi-die package parts. Thank you for
pointing this out. I checked Micron MT25QL02GCBB datasheet and found the
part supports DIE ERASE (C4h) instead of standard CHIP ERASE.
https://media-www.micron.com/-/media/client/global/documents/products/data-sheet/nor-flash/serial-nor/mt25q/die-rev-b/mt25q_qlkt_l_02g_cbb_0.pdf?rev=43f7f66fc8da4d7d901b35fa51284c8f

To support die erase, the core needs to know die size. That will initiate
a discussion about overall support for multi-die package devices. I think
it's better to create another series of patches for that. In this series,
I would set SNOR_F_NO_OP_CHIP_ERASE as a temporary solution.

>>
>>> How are multi die ops handled when crossing a die boundary?
>>>
>> The existing erase/write ops are done by sector/page size alignment and
>> never cross a die boundary. The read ops does not care about die boundary
> 
> What do you mean? What will happen if I request to erase 512K starting from
> offset (die0 - 256K)?
> 
I meant the erase and write requests are split into multiple ops based on
sector or page size. So, if you request to erase 512K starting from there,
two erase ops will be performed. One is for the last sector in die0 and
another is for the first sector in die1.

>> but still works because the Semper dual/quad die parts continue to output
>> data from next die when crossing a die boundary.
> 
> cool
> 
>>
>>>>
>>>> Tested on Xilinx Zynq-7000 FPGA board.
>>>
>>> Have you tried to erase/read/write multiple dies with a single request?
>>>
>> Yes, I did 'mtd_debug erase/write/read' with address ranges that involve
>> two dies. You can find errata info in the datasheet about cross-die read.
>> My test does not cover the trigger condition of the failure actually.
>> I will submit another patch that work around the issue as needed.
>>
> 
> How will you differentiate between silicon revisions?
> 
No way to differentiate. So, if I apply a workaround like splitting a read
request into two read ops, that is performed for newer silicon even though
it is not needed. I would like to implement the workaround once I find it
is a real issue on many systems.

Best Regards,
Takahiro