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

From: Takahiro Kuwano <tkuw584924@gmail.com>
To: Tudor.Ambarus@microchip.com, linux-mtd@lists.infradead.org
Cc: pratyush@kernel.org, michael@walle.cc, miquel.raynal@bootlin.com,
	richard@nod.at, vigneshr@ti.com, Bacem.Daassi@infineon.com,
	Takahiro.Kuwano@infineon.com
Subject: Re: [PATCH 8/8] mtd: spi-nor: spansion: Add support for Infineon
Date: Mon, 8 Aug 2022 15:41:09 +0900	[thread overview]
Message-ID: <4a182200-cff3-94e7-12a3-379638a52560@gmail.com> (raw)
In-Reply-To: <80b5e707-23b3-e357-c7ae-f78b6c75f2f6@microchip.com>

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

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.

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

Thanks,
Takahiro

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/