New NAND chip IDs

PATCH In review Michal Suchanek 3 participants 10 messages Jul 28, 2015

Subsystems (2)

Memory technology devices (MTD) NAND flash

lore

Share & tools

lore

Michal Suchanek

author

2015-07-28 14:39 UTC #0 lore raw

cover New NAND chip IDs

Hello,

the NAND chips on Cubietech boards are not known to Linux.

I used Petros Angelatos' patch from sunxi experimental tree for one chip and added another chip.

I hope it's ok to send both patches to avoid merge conflict.

Thanks

Michal

Michal Suchanek (1):
mtd: nand: add Samsung K9GBG08U0A chip id

Petros Angelatos (1):
mtd: nand: add Samsung's K9GBG08U0B to nand_ids table

 drivers/mtd/nand/nand_ids.c | 6 ++++++
 1 file changed, 6 insertions(+)

Signature · 1 line

2.1.4

Michal Suchanek

author

2015-07-28 14:39 UTC #1 lore raw

PATCH 1/2 mtd: nand: add Samsung's K9GBG08U0B to nand_ids table

From: Petros Angelatos <[email protected]>
Date: Mon, 25 Aug 2014 23:54:57 +0200

Add the full description of the Samsung K9GBG08U0B NAND chip in the nand_ids table so that we can later use the NAND ECC infos and ONFI timings mode in controller drivers.

Signed-off-by Petros Angelatos <[email protected]>

---
 drivers/mtd/nand/nand_ids.c | 3 +++
 1 file changed, 3 insertions(+)

drivers/mtd/nand/nand_ids.c +3 -0

index 7124400..749a3e0 100644
@@ -48,6 +48,9 @@ struct nand_flash_dev nand_flash_ids[] = {
 		{ .id = {0xad, 0xde, 0x94, 0xda, 0x74, 0xc4} },
 		  SZ_8K, SZ_8K, SZ_2M, 0, 6, 640, NAND_ECC_INFO(40, SZ_1K),
 		  4 },
+	{"K9GBG08U0B 32G 3.3V 8-bit",
+		{ .id = {0xec, 0xd7, 0x94, 0x7e, 0x64, 0x44} },
+		  SZ_8K, SZ_4K, SZ_1M, 0, 6, 1024, NAND_ECC_INFO(40, SZ_1K) },
 
 	LEGACY_ID_NAND("NAND 4MiB 5V 8-bit",   0x6B, 4, SZ_8K, SP_OPTIONS),
 	LEGACY_ID_NAND("NAND 4MiB 3,3V 8-bit", 0xE3, 4, SZ_8K, SP_OPTIONS),

Signature · 1 line

2.1.4

Michal Suchanek

author

2015-07-28 14:39 UTC #2 lore raw

PATCH 2/2 mtd: nand: add Samsung K9GBG08U0A chip id

In reply to Michal Suchanek

Nand reportedly uses 30MHz clock but according to datasheet some timings are on the slow side. Onfi 0 timing should work at least.

The chip ID in datasheet is different. Allwinner code uses multiple IDs:

0xec, 0xd7, 0x94, 0x76, 0xff, 0xff, 0xff, 0xff
0xec, 0xd7, 0x94, 0x7A, 0xff, 0xff, 0xff, 0xff

Signed-off-by Michal Suchanek <[email protected]>

---
 drivers/mtd/nand/nand_ids.c | 3 +++
 1 file changed, 3 insertions(+)

drivers/mtd/nand/nand_ids.c +3 -0

index 749a3e0..76e545b 100644
@@ -48,6 +48,9 @@ struct nand_flash_dev nand_flash_ids[] = {
 		{ .id = {0xad, 0xde, 0x94, 0xda, 0x74, 0xc4} },
 		  SZ_8K, SZ_8K, SZ_2M, 0, 6, 640, NAND_ECC_INFO(40, SZ_1K),
 		  4 },
+	{"K9GBG08U0A 32G 3.3V 8-bit", /* Note: other IDs probably exist */
+		{ .id = {0xec, 0xd7, 0x94, 0x7a, 0x54, 0x43} },
+		  SZ_8K, SZ_4K, SZ_1M, 0, 6, 640, NAND_ECC_INFO(40, SZ_1K) },
 	{"K9GBG08U0B 32G 3.3V 8-bit",
 		{ .id = {0xec, 0xd7, 0x94, 0x7e, 0x64, 0x44} },
 		  SZ_8K, SZ_4K, SZ_1M, 0, 6, 1024, NAND_ECC_INFO(40, SZ_1K) },

Signature · 1 line

2.1.4

Hans de Goede

2015-07-28 14:50 UTC #3 lore raw

In reply to Michal Suchanek

Hi,

Quoted 8 lines · Michal Suchanek

Hello,
the NAND chips on Cubietech boards are not known to Linux.
I used Petros Angelatos' patch from sunxi experimental tree for one chip and added another chip.
I hope it's ok to send both patches to avoid merge conflict.

I do not think that these patches are a good idea, this will lead to an ever growing manual maintained list of ids, and that is not maintainable IMHO.

For Samsung chips we only need the ecc strength and size the rest is already detected on the fly, and I've a patch in my personal tree to get the ecc strengt and size from the nand without needing to have an entry per chip:

https://github.com/jwrdegoede/linux-sunxi/commit/53b335d33232753b7aa70298009158baadf5a6bf

This is IMHO a much better solution.

I've a bunch of nand fixes / cleanups as a result of doing some work on sunxi nand support. I'll try to submit these upstream soon.

Regards,

Hans

Boris Brezillon

2015-07-28 15:10 UTC #4 lore raw

Hi Hans,

Quoted 16 lines · On Tue, 28 Jul 2015 16:49:58 +0200 Hans de Goede <[email protected]> wrote:

Hi,
Quoted 8 lines · Michal Suchanek
Hello,
the NAND chips on Cubietech boards are not known to Linux.
I used Petros Angelatos' patch from sunxi experimental tree for one chip and added another chip.
I hope it's ok to send both patches to avoid merge conflict.
I do not think that these patches are a good idea, this will lead to an ever growing manual maintained list of ids, and that is not maintainable IMHO.

Quoted 8 lines

For Samsung chips we only need the ecc strength and size the rest is already detected on the fly, and I've a patch in my personal tree to get the ecc strengt and size from the nand without needing to have an entry per chip:
https://github.com/jwrdegoede/linux-sunxi/commit/53b335d33232753b7aa70298009158baadf5a6bf
This is IMHO a much better solution.

Hm, IMHO it's not: the nand ids table also store information about supported NAND timings, and maybe we'll have to add new things (like the read-retry implementation to use for a specific chip).

Moreover, this information can be automatically deduced from the NAND id, and we try to keep discoverable info out of the DT.

I agree that keeping a list of full IDs is not ideal, but it's far better than having to duplicate this information in all the board DTs using a given NAND chip.

Best Regards,

Boris

Signature · 3 lines

Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Boris Brezillon

2015-07-28 15:13 UTC #5 lore raw

Quoted 26 lines · On Tue, 28 Jul 2015 17:10:13 +0200 Boris Brezillon…

Hi Hans,
Quoted 21 lines · On Tue, 28 Jul 2015 16:49:58 +0200 Hans de Goede <[email protected]> wrote:
Hi,
Quoted 8 lines · Michal Suchanek
Hello,
the NAND chips on Cubietech boards are not known to Linux.
I used Petros Angelatos' patch from sunxi experimental tree for one chip and added another chip.
I hope it's ok to send both patches to avoid merge conflict.
I do not think that these patches are a good idea, this will lead to an ever growing manual maintained list of ids, and that is not maintainable IMHO.
For Samsung chips we only need the ecc strength and size the rest is already detected on the fly, and I've a patch in my personal tree to get the ecc strengt and size from the nand without needing to have an entry per chip:

Quoted 7 lines

Quoted 3 lines
https://github.com/jwrdegoede/linux-sunxi/commit/53b335d33232753b7aa70298009158baadf5a6bf
This is IMHO a much better solution.
Hm, IMHO it's not: the nand ids table also store information about supported NAND timings, and maybe we'll have to add new things (like the read-retry implementation to use for a specific chip).

Oops, sorry, I didn't look at the patch before answering, and I thought you were suggesting to put the information inside the DT. Forget my previous answer.

Signature · 3 lines

Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Hans de Goede

2015-07-28 15:16 UTC #6 lore raw

In reply to Boris Brezillon

Hi,

Quoted 28 lines · Boris Brezillon

Hi Hans,
Quoted 23 lines · On Tue, 28 Jul 2015 16:49:58 +0200 Hans de Goede <[email protected]> wrote:
Hi,
Quoted 8 lines · Michal Suchanek
Hello,
the NAND chips on Cubietech boards are not known to Linux.
I used Petros Angelatos' patch from sunxi experimental tree for one chip and added another chip.
I hope it's ok to send both patches to avoid merge conflict.
I do not think that these patches are a good idea, this will lead to an ever growing manual maintained list of ids, and that is not maintainable IMHO.
For Samsung chips we only need the ecc strength and size the rest is already detected on the fly, and I've a patch in my personal tree to get the ecc strengt and size from the nand without needing to have an entry per chip:
https://github.com/jwrdegoede/linux-sunxi/commit/53b335d33232753b7aa70298009158baadf5a6bf

Quoted 8 lines

Quoted 1 line
This is IMHO a much better solution.
Hm, IMHO it's not: the nand ids table also store information about supported NAND timings, and maybe we'll have to add new things (like the read-retry implementation to use for a specific chip).
Moreover, this information can be automatically deduced from the NAND id, and we try to keep discoverable info out of the DT.

Note I'm not advocating to add stuff to DT, I'm advocating to not add entries to the ID table unless it gives us something which we cannot get another way.

The current samsung nand entries in the table only add ecc strength / size info over what is already determined by the generic nand scan code, my patch adds support to get ecc strength / size for samsung nands to the generic code, this allows at least to remove the current samsung nand lines, I believe.

Regards,

Hans

Boris Brezillon

2015-07-28 15:19 UTC #7 lore raw

In reply to Hans de Goede

Hi Hans,

Here is a more appropriate answer ;-)

Quoted 16 lines · On Tue, 28 Jul 2015 16:49:58 +0200 Hans de Goede <[email protected]> wrote:

Hi,
Quoted 8 lines · Michal Suchanek
Hello,
the NAND chips on Cubietech boards are not known to Linux.
I used Petros Angelatos' patch from sunxi experimental tree for one chip and added another chip.
I hope it's ok to send both patches to avoid merge conflict.
I do not think that these patches are a good idea, this will lead to an ever growing manual maintained list of ids, and that is not maintainable IMHO.

Quoted 8 lines

For Samsung chips we only need the ecc strength and size the rest is already detected on the fly, and I've a patch in my personal tree to get the ecc strengt and size from the nand without needing to have an entry per chip:
https://github.com/jwrdegoede/linux-sunxi/commit/53b335d33232753b7aa70298009158baadf5a6bf
This is IMHO a much better solution.

Yes, indeed, this is a better approach, but AFAIR, not all Samsung chips use this layout to expose the ECC strength/size info, and I guess this is why this method is not used to retrieve the ECC requirements.

But I think we could avoid this full ids list by putting some detection code into vendor specific files, this way we could handle chips by families instead of describing all of them.

Best Regards,

Boris

Signature · 3 lines

Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Boris Brezillon

2015-07-28 15:30 UTC #8 lore raw

Quoted 28 lines · On Tue, 28 Jul 2015 17:19:40 +0200 Boris Brezillon…

Hi Hans,
Here is a more appropriate answer ;-)
Quoted 21 lines · On Tue, 28 Jul 2015 16:49:58 +0200 Hans de Goede <[email protected]> wrote:
Hi,
Quoted 8 lines · Michal Suchanek
Hello,
the NAND chips on Cubietech boards are not known to Linux.
I used Petros Angelatos' patch from sunxi experimental tree for one chip and added another chip.
I hope it's ok to send both patches to avoid merge conflict.
I do not think that these patches are a good idea, this will lead to an ever growing manual maintained list of ids, and that is not maintainable IMHO.
For Samsung chips we only need the ecc strength and size the rest is already detected on the fly, and I've a patch in my personal tree to get the ecc strengt and size from the nand without needing to have an entry per chip:

Quoted 8 lines

Quoted 3 lines
https://github.com/jwrdegoede/linux-sunxi/commit/53b335d33232753b7aa70298009158baadf5a6bf
This is IMHO a much better solution.
Yes, indeed, this is a better approach, but AFAIR, not all Samsung chips use this layout to expose the ECC strength/size info, and I guess this is why this method is not used to retrieve the ECC requirements.

At least this was true for Hynix chips (see this thread [1]).

[1]http://comments.gmane.org/gmane.linux.drivers.mtd/50252

Signature · 3 lines

Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Hans de Goede

2015-07-28 15:32 UTC #9 lore raw

Hi,

Quoted 35 lines · Boris Brezillon

Quoted 32 lines · On Tue, 28 Jul 2015 17:19:40 +0200 Boris Brezillon…
Hi Hans,
Here is a more appropriate answer ;-)
Quoted 24 lines · On Tue, 28 Jul 2015 16:49:58 +0200 Hans de Goede <[email protected]> wrote:
Hi,
Quoted 8 lines · Michal Suchanek
Hello,
the NAND chips on Cubietech boards are not known to Linux.
I used Petros Angelatos' patch from sunxi experimental tree for one chip and added another chip.
I hope it's ok to send both patches to avoid merge conflict.
I do not think that these patches are a good idea, this will lead to an ever growing manual maintained list of ids, and that is not maintainable IMHO.
For Samsung chips we only need the ecc strength and size the rest is already detected on the fly, and I've a patch in my personal tree to get the ecc strengt and size from the nand without needing to have an entry per chip:
https://github.com/jwrdegoede/linux-sunxi/commit/53b335d33232753b7aa70298009158baadf5a6bf
This is IMHO a much better solution.

Quoted 8 lines

Quoted 4 lines
Yes, indeed, this is a better approach, but AFAIR, not all Samsung chips use this layout to expose the ECC strength/size info, and I guess this is why this method is not used to retrieve the ECC requirements.
At least this was true for Hynix chips (see this thread [1]).
[1]http://comments.gmane.org/gmane.linux.drivers.mtd/50252

Correct, I tried to write a similar patch and come to the same conclusion, there is no way to reliable detect ecc strength / size in a generic manner for hynix ic-s, for samsung ic-s the bits used seem to be consistent for all samsung nands though. See the list of datasheets I checked in the commit msg.

Regards,

Hans

Quoted 1 line