On 6/23/21 10:17 AM, [email protected] wrote:
> You don't often get email from [email protected]. 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).
>>
>> Maybe we should ask Macronix if it is safe to send the RDSFDP command.
>> Can anyone from MXIC comment this?
>
> For this part, we have validate RDSFDP command on some different chips which
> are not support SFDP mode. The conclusion is that Flash didn't reply anything.
> But we still not suggest to using commands which are not supported on the Flash.
>
>> This is also interesting because we are discussing reading the SFDP
>> without reading the ID first.
>
> I think this idea is good but I am not sure how other vendor chips will react
> after getting the commands which are not supported on the flash.
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?
On 23/06/2021 10.33, [email protected] wrote:
> On 6/23/21 10:17 AM, [email protected] wrote:
>> You don't often get email from [email protected]. 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