Re: 回信: Re: [RFC 2/3] mtd: spi-nor: core: compare JEDEC bytes to already found flash_info

[Rasmus Villemoes]

On 23/06/2021 10.33, Tudor.Ambarus@xxxxxxxxxxxxx wrote:
> On 6/23/21 10:17 AM, jaimeliao@xxxxxxxxxxx wrote:
>> You don't often get email from jaimeliao@xxxxxxxxxxx. Learn why this is important<http://aka.ms/LearnAboutSenderIdentification>
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>> Hi Michael and Rasmus
>>
>>
>>>
>>> Re: [RFC 2/3] mtd: spi-nor: core: compare JEDEC bytes to already
>>> found flash_info
>>>
>>> [+ some people from MXIC as they are ones who posted to the ML
>>> lately. Feel free to forward this mail to the corresponding people.]
>>>
>>> Am 2021-06-21 17:23, schrieb Rasmus Villemoes:
>>>> Macronix engineers, in their infinite wisdom, have a habit of reusing
>>>> JEDEC ids for different chips. There's already one
>>>> workaround (MX25L25635F v MX25L25635E), but the same problem exists
>>>> for MX25L3205D v MX25L3233F, the latter of which is not currently
>>>> supported by linux.
>>>>
>>>> AFAICT, that case cannot really be handled with any of the ->fixup
>>>> machinery: The correct entry for the MX25L3233F would read
>>>>
>>>>         { "mx25l3233f",  INFO(0xc22016, 0, 64 * 1024,  64, SECT_4K |
>>>> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ ) },
>>>>
>>>> while the existing one is
>>>>
>>>>    { "mx25l3205d",  INFO(0xc22016, 0, 64 * 1024,  64, SECT_4K) },
>>>>
>>>> So in spi_nor_init_params(), we won't even try reading the sfdp
>>>> info (i.e. call spi_nor_sfdp_init_params), and hence
>>>> spi_nor_post_sfdp_fixups() has no way of distinguishing the
>>>> chips.
>>>>
>>>> Replacing the existing entry with the mx25l3233f one to coerce the
>>>> core into issuing the SPINOR_OP_RDSFDP is also not really an option,
>>>> because the data sheet for the mx25l3205d explicitly says not to issue
>>>> any commands not listed ("It is not recommended to adopt any other
>>>> code not in the command definition table, which will potentially enter
>>>> the hidden mode.", whatever that means).
>>>

> Do any of these flashed define an extended ID, i.e. more that 3 bytes of ID?
> Rasmus, would you please try to read more bytes of ID?
> 

No, neither mx25l3205d nor mx25l3233f do according to their data sheets.

And when actually reading more bytes, one gets as expected just the c2
20 16 repeating all over.

Rasmus