Messages in this thread | | | From | <> | Subject | Re: 回信: Re: [RFC 2/3] mtd: spi-nor : core: compare JEDEC bytes to already fou nd flash info | Date | Wed, 23 Jun 2021 08:33:15 +0000 |
| |
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). >> >> 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?
| |