[PATCH] mtd: rawnand: add support for Toshiba TC58NVG0S3HTA00 NAND flash

[PATCH] mtd: rawnand: add support for Toshiba TC58NVG0S3HTA00 NAND flash

[Andreas Böhler]

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>
---
 drivers/mtd/nand/raw/nand_ids.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/mtd/nand/raw/nand_ids.c b/drivers/mtd/nand/raw/nand_ids.c
index 6e41902be35f..d64adbd1ce6b 100644
--- 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[] = {
 	{"TC58NVG0S3E 1G 3.3V 8-bit",
 		{ .id = {0x98, 0xd1, 0x90, 0x15, 0x76, 0x14, 0x01, 0x00} },
 		  SZ_2K, SZ_128, SZ_128K, 0, 8, 64, NAND_ECC_INFO(1, SZ_512), },
+	{"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), },
 	{"TC58NVG2S0F 4G 3.3V 8-bit",
 		{ .id = {0x98, 0xdc, 0x90, 0x26, 0x76, 0x15, 0x01, 0x08} },
 		  SZ_4K, SZ_512, SZ_256K, 0, 8, 224, NAND_ECC_INFO(4, SZ_512) },
-- 
2.35.1


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

Re: [PATCH] mtd: rawnand: add support for Toshiba TC58NVG0S3HTA00 NAND flash

[Miquel Raynal]

On Wed, 2022-04-20 at 10:40:34 UTC, =?utf-8?q?Andreas_B=C3=B6hler?= 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>

Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git nand/next, thanks.

Miquel

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

Re: [PATCH] mtd: rawnand: add support for Toshiba TC58NVG0S3HTA00 NAND flash

[Christian Lamparter]

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).

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 :-( .
||

|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>





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

Re: [PATCH] mtd: rawnand: add support for Toshiba TC58NVG0S3HTA00 NAND flash

[Miquel Raynal]

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/

[PATCH] Revert "mtd: rawnand: add support for Toshiba TC58NVG0S3HTA00 NAND flash"

[Christian Lamparter]

This reverts commit 3380557fc7e28d9bce7607e16d98f123d36da4ca.

It turned out this "4-byte" ID might have been an honest mistake.
Regrettably, the chip Andreas has might be a counterfeit or is
damaged in some other way and shouldn't have ended up in a router.

Andreas reported his chip is returning just four bytes:
"98 f1 80 15 00 00 00 00".

However, according to Kioxia/Toshiba's datasheet, there should
have been at least another byte that would have contained the
correct OOB size that Andreas needed.

Thanks to Peter-vdL for reporting this issue and Hannu Nyman
as well as neg2led who did the debugging.

Cc: Andreas B<C3><B6>hler <dev@aboehler.at>
BugLink: https://github.com/openwrt/openwrt/issues/9962
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
---
 drivers/mtd/nand/raw/nand_ids.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/mtd/nand/raw/nand_ids.c b/drivers/mtd/nand/raw/nand_ids.c
index 88c2440b47d8..dacc5529b3df 100644
--- a/drivers/mtd/nand/raw/nand_ids.c
+++ b/drivers/mtd/nand/raw/nand_ids.c
@@ -29,9 +29,6 @@ struct nand_flash_dev nand_flash_ids[] = {
 	{"TC58NVG0S3E 1G 3.3V 8-bit",
 		{ .id = {0x98, 0xd1, 0x90, 0x15, 0x76, 0x14, 0x01, 0x00} },
 		  SZ_2K, SZ_128, SZ_128K, 0, 8, 64, NAND_ECC_INFO(1, SZ_512), },
-	{"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), },
 	{"TC58NVG2S0F 4G 3.3V 8-bit",
 		{ .id = {0x98, 0xdc, 0x90, 0x26, 0x76, 0x15, 0x01, 0x08} },
 		  SZ_4K, SZ_512, SZ_256K, 0, 8, 224, NAND_ECC_INFO(4, SZ_512) },
-- 
2.36.1


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

Re: [PATCH] Revert "mtd: rawnand: add support for Toshiba TC58NVG0S3HTA00 NAND flash"

[Miquel Raynal]

Hi Christian,

chunkeey@gmail.com wrote on Mon,  6 Jun 2022 21:29:52 +0200:

> This reverts commit 3380557fc7e28d9bce7607e16d98f123d36da4ca.
> 
> It turned out this "4-byte" ID might have been an honest mistake.
> Regrettably, the chip Andreas has might be a counterfeit or is
> damaged in some other way and shouldn't have ended up in a router.
> 
> Andreas reported his chip is returning just four bytes:
> "98 f1 80 15 00 00 00 00".
> 
> However, according to Kioxia/Toshiba's datasheet, there should
> have been at least another byte that would have contained the
> correct OOB size that Andreas needed.

Maybe here we should mention the other alternative and explain why we
went for an immediate revert instead (knowing that we wnat to buy time
to eventually properly fix it and possibly inventory the broken chips. 

> Thanks to Peter-vdL for reporting this issue and Hannu Nyman
> as well as neg2led who did the debugging.

Maybe you can refer here to OpenWRT tools otherwise the names do not
mean anything?

> Cc: Andreas B<C3><B6>hler <dev@aboehler.at>

Looks like there is an issue with Andreas' name, I can fix it inline if
you don't know how to proceed, and if you give me the right character
to put there.

> BugLink: https://github.com/openwrt/openwrt/issues/9962

Link: is enough :)

> Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
> ---
>  drivers/mtd/nand/raw/nand_ids.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/drivers/mtd/nand/raw/nand_ids.c b/drivers/mtd/nand/raw/nand_ids.c
> index 88c2440b47d8..dacc5529b3df 100644
> --- a/drivers/mtd/nand/raw/nand_ids.c
> +++ b/drivers/mtd/nand/raw/nand_ids.c
> @@ -29,9 +29,6 @@ struct nand_flash_dev nand_flash_ids[] = {
>  	{"TC58NVG0S3E 1G 3.3V 8-bit",
>  		{ .id = {0x98, 0xd1, 0x90, 0x15, 0x76, 0x14, 0x01, 0x00} },
>  		  SZ_2K, SZ_128, SZ_128K, 0, 8, 64, NAND_ECC_INFO(1, SZ_512), },
> -	{"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), },
>  	{"TC58NVG2S0F 4G 3.3V 8-bit",
>  		{ .id = {0x98, 0xdc, 0x90, 0x26, 0x76, 0x15, 0x01, 0x08} },
>  		  SZ_4K, SZ_512, SZ_256K, 0, 8, 224, NAND_ECC_INFO(4, SZ_512) },


Thanks,
Miquèl

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

[PATCH v2] Revert "mtd: rawnand: add support for Toshiba TC58NVG0S3HTA00 NAND flash"

[Christian Lamparter]

This reverts commit 3380557fc7e28d9bce7607e16d98f123d36da4ca.

It turned out this "4-byte" ID might have been an honest mistake.
Regrettably, the chip Andreas has might be a counterfeit or is
damaged in some other way and shouldn't have ended up in a router.

Andreas reported his chip is returning just four bytes:
"98 f1 80 15 00 00 00 00".

However, according to Kioxia/Toshiba's datasheet, there should
have been at least another byte that would have contained the
correct OOB size that Andreas needed.

Miquel and Andreas are both favoring reverting the patch over
further, possibly hacky modifications:
"[Reverting] is the safest option here. Apart from this device, we
do not know how many devices have these damaged/counterfeit chips.
If it is just a couple and only on Fritzboxes, as suggested in the
Github issue the patch could be carried through OpenWrt[...]"

Thanks to several users on the openwrt forum and github issue,
who stayed along for the ride:
 - Peter-vdL for reporting the issue and testing patches.
 - neg2led and Hannu Nyman who did all the
   datasheet digging and debugging.

Cc: Andreas Boehler <dev@aboehler.at>
Suggested-by: Andreas Boehler <dev@aboehler.at>
Suggested-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://github.com/openwrt/openwrt/issues/9962
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
---

v1->v2
 - replaced the o-umlaut in Andreas' last name with "oe"
   <https://en.wikipedia.org/wiki/%C3%96>
   "In other languages that do not have the letter as part of
   the regular alphabet or in limited character sets such as
   ASCII, o-umlaut is frequently replaced with the digraph oe"
 - added note about why the revert option was taken
  (If the shout-out at the end is a problem, please just drop it
   then. I don't want to cause any privacy related stomage aches).
---
 drivers/mtd/nand/raw/nand_ids.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/mtd/nand/raw/nand_ids.c b/drivers/mtd/nand/raw/nand_ids.c
index 88c2440b47d8..dacc5529b3df 100644
--- a/drivers/mtd/nand/raw/nand_ids.c
+++ b/drivers/mtd/nand/raw/nand_ids.c
@@ -29,9 +29,6 @@ struct nand_flash_dev nand_flash_ids[] = {
 	{"TC58NVG0S3E 1G 3.3V 8-bit",
 		{ .id = {0x98, 0xd1, 0x90, 0x15, 0x76, 0x14, 0x01, 0x00} },
 		  SZ_2K, SZ_128, SZ_128K, 0, 8, 64, NAND_ECC_INFO(1, SZ_512), },
-	{"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), },
 	{"TC58NVG2S0F 4G 3.3V 8-bit",
 		{ .id = {0x98, 0xdc, 0x90, 0x26, 0x76, 0x15, 0x01, 0x08} },
 		  SZ_4K, SZ_512, SZ_256K, 0, 8, 224, NAND_ECC_INFO(4, SZ_512) },
-- 
2.36.1


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

Re: [PATCH v2] Revert "mtd: rawnand: add support for Toshiba TC58NVG0S3HTA00 NAND flash"

[Miquel Raynal]

On Tue, 2022-06-07 at 18:59:18 UTC, Christian Lamparter wrote:
> This reverts commit 3380557fc7e28d9bce7607e16d98f123d36da4ca.
> 
> It turned out this "4-byte" ID might have been an honest mistake.
> Regrettably, the chip Andreas has might be a counterfeit or is
> damaged in some other way and shouldn't have ended up in a router.
> 
> Andreas reported his chip is returning just four bytes:
> "98 f1 80 15 00 00 00 00".
> 
> However, according to Kioxia/Toshiba's datasheet, there should
> have been at least another byte that would have contained the
> correct OOB size that Andreas needed.
> 
> Miquel and Andreas are both favoring reverting the patch over
> further, possibly hacky modifications:
> "[Reverting] is the safest option here. Apart from this device, we
> do not know how many devices have these damaged/counterfeit chips.
> If it is just a couple and only on Fritzboxes, as suggested in the
> Github issue the patch could be carried through OpenWrt[...]"
> 
> Thanks to several users on the openwrt forum and github issue,
> who stayed along for the ride:
>  - Peter-vdL for reporting the issue and testing patches.
>  - neg2led and Hannu Nyman who did all the
>    datasheet digging and debugging.
> 
> Cc: Andreas Boehler <dev@aboehler.at>
> Suggested-by: Andreas Boehler <dev@aboehler.at>
> Suggested-by: Miquel Raynal <miquel.raynal@bootlin.com>
> Link: https://github.com/openwrt/openwrt/issues/9962
> Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git mtd/fixes, thanks.

Miquel

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

Re: [PATCH] mtd: rawnand: add support for Toshiba TC58NVG0S3HTA00 NAND flash

[Christian Lamparter]

Hi Miquèl,

On 06/06/2022 15:59, Miquel Raynal wrote:
> christian.lamparter@isd.uni-stuttgart.de wrote on Sun, 5 Jun 2022
>> 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?

So far no. I just heard about the (new?) AVM FritzBox 7530 revisions. These
were probably created because of shortages/price hikes? From what I can
tell (being somewhat biased there) the Fritz!Box 7530 and their variants
(there are cut-down 7520 and 7510 models) as well as rebranded models
from various ISPs in Germany.

One thing I want to point out is that Andreas mentioned in the github issue:
"I also found out that AVM matches just the four-byte ID in its GPL source code."

No idea what to think about this? Could AVM know about this
to some degree?

Is there a way to contact Toshiba/Kioxia? The e-mail address I found in
a previous patch seems to be dead :(. Anyone?

(Kioxia seems to have a B2B website about this topic:
https://personal.kioxia.com/en-emea/support/parallel-import.html

Though, I don't think this is geared towards us, the end-users...)

> 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.

Ok, I'll move Andreas modified patch around and add it to the
ipq40xx' device-support patch heap.

> 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?

Yes, should be in your inbox.

Regards,
Christian

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