All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Christian Lamparter <christian.lamparter@isd.uni-stuttgart.de>
Cc: linux-mtd@lists.infradead.org,
	"Yoshio Furuyama" <ytc-mb-yfuruyama7@kioxia.com>,
	"Andreas Böhler" <dev@aboehler.at>
Subject: Re: [PATCH] mtd: rawnand: add support for Toshiba TC58NVG0S3HTA00 NAND flash
Date: Mon, 6 Jun 2022 15:59:19 +0200	[thread overview]
Message-ID: <20220606155919.23001410@xps-13> (raw)
In-Reply-To: <bdd78c78-be40-1c31-f46e-41ed2a0cbd04@isd.uni-stuttgart.de>

Hi Christian,

christian.lamparter@isd.uni-stuttgart.de wrote on Sun, 5 Jun 2022
17:31:33 +0200:

> Hi,
> 
> On 20/04/2022 12:40, Andreas Böhler wrote:
> > The Toshiba TC58NVG0S3HTA00 is detected with 64 byte OOB while the flash
> > has 128 bytes OOB. This adds a static NAND ID entry to correct this.
> >
> > Tested on FRITZ!Box 7530 flashed with OpenWrt.
> >
> > Signed-off-by: Andreas Böhler <dev@aboehler.at>
> > ---
> > --- a/drivers/mtd/nand/raw/nand_ids.c
> > +++ b/drivers/mtd/nand/raw/nand_ids.c
> > @@ -29,6 +29,9 @@ struct nand_flash_dev nand_flash_ids[] = {
> > [...]
> > +	{"TC58NVG0S3HTA00 1G 3.3V 8-bit",
> > +		{ .id = {0x98, 0xf1, 0x80, 0x15} },
> > +		  SZ_2K, SZ_128, SZ_128K, 0, 4, 128, NAND_ECC_INFO(8, SZ_512), },  
> 
> @Minquel, there is more to this patch than it meets the eye.
> 
> It turned out this "4-byte" ID might have been an honest mistake.
> We have this documented in the OpenWrt Github issue #9962 [0] titled:
> "Fritzbox memory chip misdetection since 0bc794a6 (master and 22.03)"
> (some parts of this are also in the openwrt forum. But there's a link to
> the thread in the github issue).
> 
> Regrettably, I do think that Andreas chip might have been a
> counterfeit or damaged (that should have ended up in the
> garbage bin instead of his router).
> 
> His chips reports just the first four bytes of the chip ID:
> "98 f1 80 15 00 00 00 00". But according to Koxias/Toshiba's datasheet [1],
> there should have been at least another 5th non-zero byte in the ID.
> (I found a linux-mtd post [2] with the same chip and the OP reports:
> "0x98 0xf1 0x80 0x15 0x72 0x16 0x08 0x00" for the full ID).

That's bad luck...

> What to do in this situation? Because the patch as is is causing boot failures
> for devices with other Kioxia/Toshiba chips. This is because they also
> match the first four bytes but have different OOB sizes (64, instead of 128).
> 
> Andreas has proposed the following: update the id_len to 8, this will help
> fix the boot failures with other chips like the TC58BVG0S3HTA00, since it
> has different values for the chip-id after the 4th byte.|
> |
> 
> |{"TC58NVG0S3HTA00 1G 3.3V 8-bit", { .id = {0x98, 0xf1, 0x80, 0x15} }, SZ_2K, SZ_128, SZ_128K, 0, 8, 128, NAND_ECC_INFO(8, SZ_512), },|
> 
> ||Reverting would be an option, but if this is a counterfeit situation then
> similar "chips" could end up in other devices and we are just unlucky
> ones that are the first to report it :-( .

Do you have a way to probe the amount of affected devices among the
community or perhaps by talking to the vendor?

Reverting seems the safest option here, not knowing how many devices
have these damaged/counterfeit chips. If it is just a couple and only on
Fritzboxes, as suggested in the Github issue this patch could be
carried through OpenWRT and that would seem more future proof IMHO.

The second solution (enlarging the ID length) might work, but feels
dirty, that's why I would go for reverting this immediately (I will
send it through fixes), so that the support for this chip might just
disappear "silently". Then we have another release to decide whether
it is appropriate to use the 8-byte ID hack in the mainline kernel.

Can you please send a patch?

> ||
> 
> |Regards, Christian|
> 
> 
> [0] <https://github.com/openwrt/openwrt/issues/9962>
> [1] <https://media.digikey.com/pdf/Data%20Sheets/Toshiba%20PDFs/KIOXIA_TC58NVG0S3HTA00_Rev2.00_E191001C.pdf> page 35
> [2] <https://linux-mtd.infradead.narkive.com/8DRxas2M/patch-mtd-nand-detect-oob-size-for-toshiba-24nm-raw-slc>


Thanks,
Miquèl

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

  reply	other threads:[~2022-06-06 14:00 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-20 10:40 [PATCH] mtd: rawnand: add support for Toshiba TC58NVG0S3HTA00 NAND flash Andreas Böhler
2022-04-21  7:36 ` Miquel Raynal
2022-06-05 15:31 ` Christian Lamparter
2022-06-06 13:59   ` Miquel Raynal [this message]
2022-06-06 19:29     ` [PATCH] Revert "mtd: rawnand: add support for Toshiba TC58NVG0S3HTA00 NAND flash" Christian Lamparter
2022-06-07  6:13       ` Miquel Raynal
2022-06-07 18:59         ` [PATCH v2] " Christian Lamparter
2022-06-09 13:10           ` Miquel Raynal
2022-06-06 19:37     ` [PATCH] mtd: rawnand: add support for Toshiba TC58NVG0S3HTA00 NAND flash Christian Lamparter

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=20220606155919.23001410@xps-13 \
    --to=miquel.raynal@bootlin.com \
    --cc=christian.lamparter@isd.uni-stuttgart.de \
    --cc=dev@aboehler.at \
    --cc=linux-mtd@lists.infradead.org \
    --cc=ytc-mb-yfuruyama7@kioxia.com \
    /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.