Messages in this thread | | | Subject | Re: 回信: Re: [RFC 2/3] mtd: spi-nor: co re: compare JEDEC bytes to already found flash info | From | Rasmus Villemoes <> | Date | Tue, 29 Jun 2021 09:42:15 +0200 |
| |
On 23/06/2021 10.33, Tudor.Ambarus@microchip.com wrote: > On 6/23/21 10:17 AM, jaimeliao@mxic.com.tw wrote: >> You don't often get email from jaimeliao@mxic.com.tw. 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
| |