All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Walle <michael@walle.cc>
To: Tudor.Ambarus@microchip.com
Cc: sr@denx.de, vigneshr@ti.com, jaimeliao@mxic.com.tw,
	richard@nod.at, esben@geanix.com, linux@rasmusvillemoes.dk,
	knaerzche@gmail.com, Nicolas.Ferre@microchip.com,
	linux-mtd@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org, macromorgan@hotmail.com,
	miquel.raynal@bootlin.com, heiko.thiery@gmail.com,
	zhengxunli@mxic.com.tw, p.yadav@ti.com, mail@david-bauer.net,
	code@reto-schneider.ch
Subject: Re: [PATCH v4 3/6] mtd: spi-nor: macronix: Handle ID collision b/w MX25L3233F and MX25L3205D
Date: Thu, 03 Mar 2022 16:33:14 +0100	[thread overview]
Message-ID: <6bb1aafe7e156db8dfcf77f04a9d100e@walle.cc> (raw)
In-Reply-To: <d6e3dae6-fc46-1697-e496-33ab11469807@microchip.com>

Am 2022-03-03 16:28, schrieb Tudor.Ambarus@microchip.com:
> On 3/1/22 23:57, Michael Walle wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know 
>> the content is safe
>> 
>> Am 2022-02-28 14:45, schrieb Tudor Ambarus:
>>> Macronix has a bad habbit of reusing flash IDs. While MX25L3233F
>>> supports
>>> RDSFDP opcode, MX25L3205D does not support it and does not recommend
>>> issuing opcodes that are not supported ("It is not recommended to 
>>> adopt
>>> any other code not in the command definition table, which will
>>> potentially
>>> enter the hidden mode.").
>>> 
>>> We tested the RDSFDP on the MX25L3205D and the conclusion is that the
>>> flash didn't reply anything. Given that it is unlikely that RDSFDP 
>>> will
>>> cause any problems for the old MX25L3205D, differentiate between the
>>> two
>>> flashes by parsing SFDP.
>>> 
>>> Tested MX25L3233F. Generated a 256 Kbyte random data and did an 
>>> erase,
>>> write, read back and compare test. The flash uses for reads
>>> SPINOR_OP_READ_1_4_4 0xeb, for erases SPINOR_OP_BE_4K 0x20, and for
>>> writes
>>> SPINOR_OP_PP 0x02.
>>> 
>>> Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
>>> Acked-by: Pratyush Yadav <p.yadav@ti.com>
>>> ---
>>> #  cat
>>> /sys/devices/platform/ahb/ahb:apb/f0020000.spi/spi_master/spi1/spi1.0/spi-nor/jedec_id
>>> c22016
>>> # cat
>>> /sys/devices/platform/ahb/ahb:apb/f0020000.spi/spi_master/spi1/spi1.0/spi-nor/manufacturer
>>> macronix
>>> # cat
>>> /sys/devices/platform/ahb/ahb:apb/f0020000.spi/spi_master/spi1/spi1.0/spi-nor/partname
>>> mx25l3233f
>>> # cat
>>> /sys/devices/platform/ahb/ahb:apb/f0020000.spi/spi_master/spi1/spi1.0/spi-nor/sfdp
>>> > mx25l3233f-sfdp
>>> 
>>> 
>>> # xxd -p mx25l3233f-sfdp
>>> 53464450000101ff00000109300000ffc2000104600000ffffffffffffff
>>> ffffffffffffffffffffffffffffffffffffe520f1ffffffff0144eb086b
>>> 083b04bbeeffffffffff00ffffff00ff0c200f5210d800ffffffffffffff
>>> ffffffffffff003650269cf97764fecfffffffffffff
>> 
>> Is quad enable working or has this the same problem as
>> the macronix flash in patch 4? Judging by the length of the SFDP
>> this also lacks the required information to select an
>> appropriate enable method. I haven't had closer look though.
> 
> it worked, yes. As I specified in the commit message, I tested it and 
> it used
> SPINOR_OP_READ_1_4_4 0xeb opcode for reads.

I'm confused, why is Heiko reporting that the CR/SR writing isn't
working because a wrong quad_enable method is chosen, but here it
will work. What am I missing?

-michael

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

WARNING: multiple messages have this Message-ID (diff)
From: Michael Walle <michael@walle.cc>
To: Tudor.Ambarus@microchip.com
Cc: sr@denx.de, vigneshr@ti.com, jaimeliao@mxic.com.tw,
	richard@nod.at, esben@geanix.com, linux@rasmusvillemoes.dk,
	knaerzche@gmail.com, linux-mtd@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org, macromorgan@hotmail.com,
	miquel.raynal@bootlin.com, heiko.thiery@gmail.com,
	zhengxunli@mxic.com.tw, figgyc@figgyc.uk, p.yadav@ti.com,
	mail@david-bauer.net, code@reto-schneider.ch
Subject: Re: [PATCH v4 3/6] mtd: spi-nor: macronix: Handle ID collision b/w MX25L3233F and MX25L3205D
Date: Thu, 03 Mar 2022 16:33:14 +0100	[thread overview]
Message-ID: <6bb1aafe7e156db8dfcf77f04a9d100e@walle.cc> (raw)
In-Reply-To: <d6e3dae6-fc46-1697-e496-33ab11469807@microchip.com>

Am 2022-03-03 16:28, schrieb Tudor.Ambarus@microchip.com:
> On 3/1/22 23:57, Michael Walle wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know 
>> the content is safe
>> 
>> Am 2022-02-28 14:45, schrieb Tudor Ambarus:
>>> Macronix has a bad habbit of reusing flash IDs. While MX25L3233F
>>> supports
>>> RDSFDP opcode, MX25L3205D does not support it and does not recommend
>>> issuing opcodes that are not supported ("It is not recommended to 
>>> adopt
>>> any other code not in the command definition table, which will
>>> potentially
>>> enter the hidden mode.").
>>> 
>>> We tested the RDSFDP on the MX25L3205D and the conclusion is that the
>>> flash didn't reply anything. Given that it is unlikely that RDSFDP 
>>> will
>>> cause any problems for the old MX25L3205D, differentiate between the
>>> two
>>> flashes by parsing SFDP.
>>> 
>>> Tested MX25L3233F. Generated a 256 Kbyte random data and did an 
>>> erase,
>>> write, read back and compare test. The flash uses for reads
>>> SPINOR_OP_READ_1_4_4 0xeb, for erases SPINOR_OP_BE_4K 0x20, and for
>>> writes
>>> SPINOR_OP_PP 0x02.
>>> 
>>> Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
>>> Acked-by: Pratyush Yadav <p.yadav@ti.com>
>>> ---
>>> #  cat
>>> /sys/devices/platform/ahb/ahb:apb/f0020000.spi/spi_master/spi1/spi1.0/spi-nor/jedec_id
>>> c22016
>>> # cat
>>> /sys/devices/platform/ahb/ahb:apb/f0020000.spi/spi_master/spi1/spi1.0/spi-nor/manufacturer
>>> macronix
>>> # cat
>>> /sys/devices/platform/ahb/ahb:apb/f0020000.spi/spi_master/spi1/spi1.0/spi-nor/partname
>>> mx25l3233f
>>> # cat
>>> /sys/devices/platform/ahb/ahb:apb/f0020000.spi/spi_master/spi1/spi1.0/spi-nor/sfdp
>>> > mx25l3233f-sfdp
>>> 
>>> 
>>> # xxd -p mx25l3233f-sfdp
>>> 53464450000101ff00000109300000ffc2000104600000ffffffffffffff
>>> ffffffffffffffffffffffffffffffffffffe520f1ffffffff0144eb086b
>>> 083b04bbeeffffffffff00ffffff00ff0c200f5210d800ffffffffffffff
>>> ffffffffffff003650269cf97764fecfffffffffffff
>> 
>> Is quad enable working or has this the same problem as
>> the macronix flash in patch 4? Judging by the length of the SFDP
>> this also lacks the required information to select an
>> appropriate enable method. I haven't had closer look though.
> 
> it worked, yes. As I specified in the commit message, I tested it and 
> it used
> SPINOR_OP_READ_1_4_4 0xeb opcode for reads.

I'm confused, why is Heiko reporting that the CR/SR writing isn't
working because a wrong quad_enable method is chosen, but here it
will work. What am I missing?

-michael

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-03-03 15:34 UTC|newest]

Thread overview: 80+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-28 13:44 [PATCH v4 0/6] mtd: spi-nor: Handle ID collisions Tudor Ambarus
2022-02-28 13:44 ` Tudor Ambarus
2022-02-28 13:45 ` [PATCH v4 1/6] mtd: spi-nor: core: Report correct name in case of " Tudor Ambarus
2022-02-28 13:45   ` Tudor Ambarus
2022-03-01 21:38   ` Michael Walle
2022-03-01 21:38     ` Michael Walle
2022-04-05 19:41   ` Pratyush Yadav
2022-04-05 19:41     ` Pratyush Yadav
2022-02-28 13:45 ` [PATCH v4 2/6] mtd: spi-nor: core: Handle ID collisions between SFDP & non-SFDP flashes Tudor Ambarus
2022-02-28 13:45   ` Tudor Ambarus
2022-03-01 21:52   ` Michael Walle
2022-03-01 21:52     ` Michael Walle
2022-03-03 14:41     ` Tudor.Ambarus
2022-03-03 14:41       ` Tudor.Ambarus
2022-03-03 14:51       ` Michael Walle
2022-03-03 14:51         ` Michael Walle
2022-03-03 15:25         ` Tudor.Ambarus
2022-03-03 15:25           ` Tudor.Ambarus
2022-03-03 15:42           ` Michael Walle
2022-03-03 15:42             ` Michael Walle
2022-03-03 16:03             ` Tudor.Ambarus
2022-03-03 16:03               ` Tudor.Ambarus
2022-03-03 16:39               ` Michael Walle
2022-03-03 16:39                 ` Michael Walle
2022-02-28 13:45 ` [PATCH v4 3/6] mtd: spi-nor: macronix: Handle ID collision b/w MX25L3233F and MX25L3205D Tudor Ambarus
2022-02-28 13:45   ` Tudor Ambarus
2022-03-01 21:57   ` Michael Walle
2022-03-01 21:57     ` Michael Walle
2022-03-03 15:28     ` Tudor.Ambarus
2022-03-03 15:28       ` Tudor.Ambarus
2022-03-03 15:33       ` Michael Walle [this message]
2022-03-03 15:33         ` Michael Walle
     [not found]         ` <CAEyMn7aN+wJnYkTJU_nWA9bPzF1sezA9_=E5YG5rnPBLMAmabA@mail.gmail.com>
2022-03-03 16:45           ` Michael Walle
2022-03-03 16:45             ` Michael Walle
2022-03-04  0:36             ` Tudor.Ambarus
2022-03-04  0:36               ` Tudor.Ambarus
2022-03-04 14:36               ` Michael Walle
2022-03-04 14:36                 ` Michael Walle
2022-04-05 19:50                 ` Pratyush Yadav
2022-04-05 19:50                   ` Pratyush Yadav
2022-02-28 13:45 ` [PATCH v4 4/6] mtd: spi-nor: macronix: Handle ID collision b/w MX25L12805D and MX25L12835F Tudor Ambarus
2022-02-28 13:45   ` Tudor Ambarus
2022-03-01  7:55   ` Heiko Thiery
2022-03-01  7:55     ` Heiko Thiery
2022-03-01  8:52     ` Tudor.Ambarus
2022-03-01  8:52       ` Tudor.Ambarus
2022-03-01  9:31       ` Heiko Thiery
2022-03-01  9:31         ` Heiko Thiery
2022-02-28 13:45 ` [PATCH v4 5/6] mtd: spi-nor: Introduce Manufacturer ID collisions driver Tudor Ambarus
2022-02-28 13:45   ` Tudor Ambarus
2022-03-01 22:19   ` Michael Walle
2022-03-01 22:19     ` Michael Walle
2022-03-03 16:12     ` Tudor.Ambarus
2022-03-03 16:12       ` Tudor.Ambarus
2022-03-03 21:38       ` Michael Walle
2022-03-03 21:38         ` Michael Walle
2022-03-04  7:07         ` Tudor.Ambarus
2022-03-04  7:07           ` Tudor.Ambarus
2022-03-04 14:10           ` Michael Walle
2022-03-04 14:10             ` Michael Walle
2022-03-04 21:20   ` George Brooke
2022-03-04 21:20     ` George Brooke
2022-03-07  7:07     ` Tudor.Ambarus
2022-03-07  7:07       ` Tudor.Ambarus
2022-02-28 13:45 ` [PATCH v4 6/6] mtd: spi-nor: manuf-id-collisions: Add support for xt25f128b Tudor Ambarus
2022-02-28 13:45   ` Tudor Ambarus
2022-03-01 22:23   ` Michael Walle
2022-03-01 22:23     ` Michael Walle
2022-03-03 21:04     ` Chris Morgan
2022-03-03 21:04       ` Chris Morgan
2022-03-03 23:50       ` Tudor.Ambarus
2022-03-03 23:50         ` Tudor.Ambarus
2022-03-04  2:23         ` Chris Morgan
2022-03-04  2:23           ` Chris Morgan
2022-02-28 13:55 ` [PATCH v4 0/6] mtd: spi-nor: Handle ID collisions Michael Walle
2022-02-28 13:55   ` Michael Walle
2022-02-28 15:39   ` [PATCH] mtd: spi-nor: Move XMC to manufacturer ID collisions driver Tudor Ambarus
2022-02-28 15:39     ` Tudor Ambarus
2022-03-01  6:47   ` [PATCH v2] " Tudor Ambarus
2022-03-01  6:47     ` Tudor Ambarus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6bb1aafe7e156db8dfcf77f04a9d100e@walle.cc \
    --to=michael@walle.cc \
    --cc=Nicolas.Ferre@microchip.com \
    --cc=Tudor.Ambarus@microchip.com \
    --cc=code@reto-schneider.ch \
    --cc=esben@geanix.com \
    --cc=heiko.thiery@gmail.com \
    --cc=jaimeliao@mxic.com.tw \
    --cc=knaerzche@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=macromorgan@hotmail.com \
    --cc=mail@david-bauer.net \
    --cc=miquel.raynal@bootlin.com \
    --cc=p.yadav@ti.com \
    --cc=richard@nod.at \
    --cc=sr@denx.de \
    --cc=vigneshr@ti.com \
    --cc=zhengxunli@mxic.com.tw \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.