Re: [PATCH 8/8] mtd: spi-nor: spansion: Add support for Infineon

Tudor.Ambarus
2022-08-08T07:35:06Z

On 8/8/22 09:41, Takahiro Kuwano wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> On 8/8/2022 3:08 PM, Tudor.Ambarus@microchip.com wrote:
>> On 8/8/22 08:42, Takahiro Kuwano wrote:
>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>>
>>> On 8/8/2022 1:47 PM, Tudor.Ambarus@microchip.com wrote:
>>>> On 8/6/22 09:34, tkuw584924@gmail.com wrote:
>>>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>>>>
>>>>> From: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
>>>>
>>>> Hi!
>>>>
>>>>>
>>>>> s25hl02gt and s25hs02gt
>>>>>
>>>>> Add ID, flags, and fixup for s25hl02gt and s25hs02gt.
>>>>> These parts are
>>>>> - Dual-die package parts
>>>>> - Not support chip erase
>>>>> - 4-byte addressing mode by default
>>>>
>>>> CFR2N[7] CFR2V[7] says that: "For the DDP or QDP devices, if ADRBYT = 0
>>>> only the first 128 Mb of die 1 can be accessed."
>>>> So there are flashes of the same family that are by default in 3 byte address
>>>> mode. You added support just for a subset of them and used a generic name,
>>>> which is not accurate, right?
>>>>
>>> We added model #15 (3-byte address mode by default) to address special
>>> requirement from a customer who needs to use bootrom with 3-byte addressing.
>>> Anyway, I overlooked model # difference. Thanks for pointing out this.
>>>
>>>> Can we instead make an algorithm to determine the current address mode?
>>>>
>>> I have just found that we can distinguish model # via BFPT DWORD16.
>>> If Hardware reset, Software reset, or Power cycle can exit 4-byte address
>>> mode, that means the device is 3-byte address mode by default.
>>
>> I don't think this will help us. It doesn't matter the default mode if you
>> have a non volatile register that can be updated and changes the default
>> mode.
>>
>> Are there any registers/data that can be read successively in 3 byte addr mode
>> and then in 4 byte addr mode? We'll then compare what we receive from the flash
>> with a known value and determine the mode.
>>
> As we discussed before [0], if address mode in the controller and device are

I remember, yes, but without determining the mode, the driver will work only
with flashes that come with the factory settings. The driver will be unusable
if someone changes the address mode in a non volatile way, right?

> different, the read data will be undetermined.
>
> But if we really want...
> Compare SR1 data read by RDSR1(05h - No Addr) and RDAR(65h - Addr 0).
> In most cases (without block protection), SR1=00h. The value of 00h would be
> awkward to determine if this is 'real' output from Flash or not. So, use> WREN(06h) and WRDI(04h) that flips BIT(1) in SR1.

Would be good to have more fixed/OPT-like bits, or if we could change more bits
to increase the chances to not hit just some undetermined data.
>
> Therefore, something like:
> 1) RDSR1
> 2) RDAR with 3-byte addr (000000h)
> 3) If #1 == #2
> 4) WREN
> 5) RDAR with 3-byte addr (000000h)
> 6) BIT(1) is SR1==1?
> ...
>
> Or simply WREN -> RDAR -> WRDI -> RDAR then check if only BIT(1) is toggled.

Both may work, yes, but making the assumption on only one bit is fragile.
Can we use the Read Any Register Command with 3 and 4 byte address modes and
compare the values? Are there any registers with fixed values?

>
> [0] https://lore.kernel.org/all/070bfe6a-00e8-1c59-c9db-52d249dfbcfe@microchip.com/
>
> Thanks,
> Takahiro

--
Cheers,
ta