[U-Boot] [PATCH] NAND: add Samsung K9LBG08UXD identifier
The Samsung K9LBG08UXD parts are 32Gbytes x 8 bits 3.3V parts with the 0xD7 identifier. Add this to the list of known devices IDs.
Signed-off-by: Lei Wen leiwen@marvell.com --- drivers/mtd/nand/nand_ids.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/nand/nand_ids.c b/drivers/mtd/nand/nand_ids.c index 25b22ec..3d958d8 100644 --- a/drivers/mtd/nand/nand_ids.c +++ b/drivers/mtd/nand/nand_ids.c @@ -111,6 +111,9 @@ struct nand_flash_dev nand_flash_ids[] = { {"NAND 2GiB 1,8V 16-bit", 0xB5, 0, 2048, 0, LP_OPTIONS16}, {"NAND 2GiB 3,3V 16-bit", 0xC5, 0, 2048, 0, LP_OPTIONS16},
+ /* 32 Gigabit */ + {"NAND 4GiB 3,3V 8-bit", 0xD7, 0, 4096, 0, LP_OPTIONS16}, + /* * Renesas AND 1 Gigabit. Those chips do not support extended id and * have a strange page/block layout ! The chosen minimum erasesize is
Rebased version for this nand chip has one problem in detecting its page size using in nand_base.c. If we set page size 0 in nand_ids.c, we would get the calculation result as page size 2048, while the true page size is 4096.
I think it is reasonable to set the 32Gigabit nand as 4k page by default, as all nand been product in this size has more than 4k page.
The Samsung K9LBG08UXD parts are 32Gbytes x 8 bits 3.3V parts with the 0xD7 identifier. Add these to the list of known devices IDs.
Signed-off-by: Lei Wen leiwen@marvell.com --- drivers/mtd/nand/nand_ids.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/nand/nand_ids.c b/drivers/mtd/nand/nand_ids.c index 077c305..5dd4c54 100644 --- a/drivers/mtd/nand/nand_ids.c +++ b/drivers/mtd/nand/nand_ids.c @@ -110,6 +110,9 @@ struct nand_flash_dev nand_flash_ids[] = { {"NAND 2GiB 1,8V 16-bit", 0xB5, 0, 2048, 0, LP_OPTIONS16}, {"NAND 2GiB 3,3V 16-bit", 0xC5, 0, 2048, 0, LP_OPTIONS16},
+ /* 32 Gigabit */ + {"NAND 4GiB 3,3V 8-bit", 0xD7, 4096, 4096, 0, LP_OPTIONS}, + /* * Renesas AND 1 Gigabit. Those chips do not support extended id and * have a strange page/block layout ! The chosen minimum erasesize is
On Mon, Jul 19, 2010 at 8:49 PM, Lei Wen adrian.wenl@gmail.com wrote:
The Samsung K9LBG08UXD parts are 32Gbytes x 8 bits 3.3V parts with the 0xD7 identifier. Add this to the list of known devices IDs.
Signed-off-by: Lei Wen leiwen@marvell.com
drivers/mtd/nand/nand_ids.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/nand/nand_ids.c b/drivers/mtd/nand/nand_ids.c index 25b22ec..3d958d8 100644 --- a/drivers/mtd/nand/nand_ids.c +++ b/drivers/mtd/nand/nand_ids.c @@ -111,6 +111,9 @@ struct nand_flash_dev nand_flash_ids[] = { {"NAND 2GiB 1,8V 16-bit", 0xB5, 0, 2048, 0, LP_OPTIONS16}, {"NAND 2GiB 3,3V 16-bit", 0xC5, 0, 2048, 0, LP_OPTIONS16},
- /* 32 Gigabit */
- {"NAND 4GiB 3,3V 8-bit", 0xD7, 0, 4096, 0, LP_OPTIONS16},
/* * Renesas AND 1 Gigabit. Those chips do not support extended id and * have a strange page/block layout ! The chosen minimum erasesize is
On Mon, Jul 19, 2010 at 09:05:05PM +0800, Lei Wen wrote:
Rebased version for this nand chip has one problem in detecting its page size using in nand_base.c. If we set page size 0 in nand_ids.c, we would get the calculation result as page size 2048, while the true page size is 4096.
Is the ID data bad, or is there a bug in nand_get_flash_type(), or is it some new ID format that needs support?
I think it is reasonable to set the 32Gigabit nand as 4k page by default, as all nand been product in this size has more than 4k page.
"more than"? Are there larger page size NANDs out there?
And if so, wouldn't hard-coding the page size at 4096 bytes be a problem?
Is there zero possibility that a 2k page NAND in this size could be made in the future (e.g. for compatibility with controllers that don't support 4k pages)?
-Scott
On Tue, Jul 20, 2010 at 4:22 AM, Scott Wood scottwood@freescale.com wrote:
On Mon, Jul 19, 2010 at 09:05:05PM +0800, Lei Wen wrote:
Rebased version for this nand chip has one problem in detecting its page size using in nand_base.c. If we set page size 0 in nand_ids.c, we would get the calculation result as page size 2048, while the true page size is 4096.
Is the ID data bad, or is there a bug in nand_get_flash_type(), or is it some new ID format that needs support?
Samsung seem modify the ID name rule, which make the calculation method nand_get_flash_type doesn't work. In mainline linux code, it give a hardcode way to identify this type of nand with new calculation method.
I think it is reasonable to set the 32Gigabit nand as 4k page by default, as all nand been product in this size has more than 4k page.
"more than"? Are there larger page size NANDs out there?
8k page nand exists, but they are for even larger nand, like 64Gb, or 128Gb.
And if so, wouldn't hard-coding the page size at 4096 bytes be a problem?
Is there zero possibility that a 2k page NAND in this size could be made in the future (e.g. for compatibility with controllers that don't support 4k pages)?
Maybe we could post another patch for that kind of nand?...
-Scott
On Tue, 20 Jul 2010 08:43:55 +0800 Lei Wen adrian.wenl@gmail.com wrote:
On Tue, Jul 20, 2010 at 4:22 AM, Scott Wood scottwood@freescale.com wrote:
On Mon, Jul 19, 2010 at 09:05:05PM +0800, Lei Wen wrote:
Rebased version for this nand chip has one problem in detecting its page size using in nand_base.c. If we set page size 0 in nand_ids.c, we would get the calculation result as page size 2048, while the true page size is 4096.
Is the ID data bad, or is there a bug in nand_get_flash_type(), or is it some new ID format that needs support?
Samsung seem modify the ID name rule, which make the calculation method nand_get_flash_type doesn't work. In mainline linux code, it give a hardcode way to identify this type of nand with new calculation method.
Let's do the same thing Linux does, then.
It looks like it's not just writesize that is different...
Is there zero possibility that a 2k page NAND in this size could be made in the future (e.g. for compatibility with controllers that don't support 4k pages)?
Maybe we could post another patch for that kind of nand?
My point is just that we should make autodetection work if it's practical.
-Scott
2010/7/21 Scott Wood scottwood@freescale.com:
On Tue, 20 Jul 2010 08:43:55 +0800 Lei Wen adrian.wenl@gmail.com wrote:
On Tue, Jul 20, 2010 at 4:22 AM, Scott Wood scottwood@freescale.com wrote:
On Mon, Jul 19, 2010 at 09:05:05PM +0800, Lei Wen wrote:
Rebased version for this nand chip has one problem in detecting its page size using in nand_base.c. If we set page size 0 in nand_ids.c, we would get the calculation result as page size 2048, while the true page size is 4096.
Is the ID data bad, or is there a bug in nand_get_flash_type(), or is it some new ID format that needs support?
Samsung seem modify the ID name rule, which make the calculation method nand_get_flash_type doesn't work. In mainline linux code, it give a hardcode way to identify this type of nand with new calculation method.
Let's do the same thing Linux does, then.
In fact, Linux(nand_base.c) does not handle the pagesize, oobsize correctly for the new NAND. And actually, it's real difficult for providing one common caculation rule for all the NAND flash since the NAND ID data layout is not much the same as each other. Maybe, this is why there is not such patch in linux to fix this issue.
It looks like it's not just writesize that is different...
Is there zero possibility that a 2k page NAND in this size could be made in the future (e.g. for compatibility with controllers that don't support 4k pages)?
Maybe we could post another patch for that kind of nand?
My point is just that we should make autodetection work if it's practical.
-Scott
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
On Wed, 21 Jul 2010 13:59:14 +0800 Jason Liu liu.h.jason@gmail.com wrote:
2010/7/21 Scott Wood scottwood@freescale.com:
On Tue, 20 Jul 2010 08:43:55 +0800 Lei Wen adrian.wenl@gmail.com wrote:
On Tue, Jul 20, 2010 at 4:22 AM, Scott Wood scottwood@freescale.com wrote:
On Mon, Jul 19, 2010 at 09:05:05PM +0800, Lei Wen wrote:
Rebased version for this nand chip has one problem in detecting its page size using in nand_base.c. If we set page size 0 in nand_ids.c, we would get the calculation result as page size 2048, while the true page size is 4096.
Is the ID data bad, or is there a bug in nand_get_flash_type(), or is it some new ID format that needs support?
Samsung seem modify the ID name rule, which make the calculation method nand_get_flash_type doesn't work. In mainline linux code, it give a hardcode way to identify this type of nand with new calculation method.
Let's do the same thing Linux does, then.
In fact, Linux(nand_base.c) does not handle the pagesize, oobsize correctly for the new NAND.
What should it be doing instead for this chip?
And actually, it's real difficult for providing one common caculation rule for all the NAND flash since the NAND ID data layout is not much the same as each other. Maybe, this is why there is not such patch in linux to fix this issue.
It doesn't need to be one common calculation, as long as enough of the ID is common that we can figure out which calculation to use. How many variants are there, and is how complicated is it to figure out which variant it is?
Alternatively, hard-coding it may be the only way to stay sane -- but in that case, we need to make sure we've got a good enough match. Do we need to add the manufacturer to the ID table? I'm assuming that something motivated the switch away from putting writesize/erasesize in the ID table.
And it looks like if pagesize is hardcoded, erasesize must be as well.
-Scott
participants (3)
-
Jason Liu -
Lei Wen -
Scott Wood