lkml.org 
[lkml]   [2021]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: 回信: Re: [RFC 2/3] mtd: spi-nor : core: compare JEDEC bytes to already fou nd flash info
    Date
    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?

    \
     
     \ /
      Last update: 2021-06-23 10:34    [W:4.571 / U:0.092 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site