[U-Boot] [PATCH] NAND: Updating the NAND README
From: Sandeep Paulraj s-paulraj@ti.com
This patch updates the README for NAND. There were some good updates made to the driver.
Signed-off-by: Sandeep Paulraj s-paulraj@ti.com --- doc/README.nand | 42 ++++++++++++++++++++++++++++++++++++++++-- 1 files changed, 40 insertions(+), 2 deletions(-)
diff --git a/doc/README.nand b/doc/README.nand index 8eedb6c..57da255 100644 --- a/doc/README.nand +++ b/doc/README.nand @@ -147,6 +147,44 @@ NAND locking command (for chips with active LOCKPRE pin) "nand unlock [offset] [size]" unlock consecutive area (can be called multiple times for different areas)
+MTD NAND 64 bit support: +======================== + +The MTD NAND infrastructure in U-Boot(until release 2009.11) used only +32 bit values to represent device size. As a result of which if we use +a NAND device of size 4 GB and above, the MTD NAND driver will not detect +such a NAND device due to overflow. +NANDs comes in various flavours. There are some NANDs which are +internally 2 devices and have 2 chipselects. If the SOC specific +NAND driver is designed to treat each NAND device as a separate device +then we will still be able to detect the entire 4GB of a NAND device. +Each chipselect being responsible for 2 GB address space. +But if at the U-Boot level we want to have access to the entire 4GB address +space then the only way to achieve this is to update the MTD and NAND drivers +with 64 bit values. +The Linux kernel was updated with 64 bit values sometime in December '08. +The core NAND driver is now similar to the core NAND driver in the kernel. +We appropriately update the MTD layer in U-Boot. +In the process of syncing up with the kernel we have also updated the +NAND driver with other enhancements that made its way to the NAND driver. + +After these features were added, testing was performed on a wide +range of NAND devices with page size of 64 KiB, 128KiB, 256KiB and 512 +KiB. Also 2 separate 4GB NAND devices(one from SAMSUNG and one from MICRON) +were successfully tested. U-Boot was able to correctly detect the device +and read bad blocks. + +What is lacking? +================ + +We need to add 64 bit support in cmd_nand.c and env_nand.c as well. +Without this certain diagnostcis will fail. For example, +issuing a "nand bad" command results in the same bad blocks being +found infinite times. This happens if we use a 4 GB NAND device. +This will not occur if NANDs of smalles than 4 GB are used. +At this point of time it appears as if the entire common folder +needs to be updated with 64 bit values. + + +
-I have tested the code with board containing 128MiB NAND large page chips -and 32MiB small page chips.
On Tue, Dec 01, 2009 at 01:06:07PM -0500, s-paulraj@ti.com wrote:
+MTD NAND 64 bit support: +========================
+The MTD NAND infrastructure in U-Boot(until release 2009.11) used only +32 bit values to represent device size. As a result of which if we use +a NAND device of size 4 GB and above, the MTD NAND driver will not detect +such a NAND device due to overflow. +NANDs comes in various flavours. There are some NANDs which are +internally 2 devices and have 2 chipselects. If the SOC specific +NAND driver is designed to treat each NAND device as a separate device +then we will still be able to detect the entire 4GB of a NAND device. +Each chipselect being responsible for 2 GB address space. +But if at the U-Boot level we want to have access to the entire 4GB address +space then the only way to achieve this is to update the MTD and NAND drivers +with 64 bit values. +The Linux kernel was updated with 64 bit values sometime in December '08. +The core NAND driver is now similar to the core NAND driver in the kernel. +We appropriately update the MTD layer in U-Boot. +In the process of syncing up with the kernel we have also updated the +NAND driver with other enhancements that made its way to the NAND driver.
+After these features were added, testing was performed on a wide +range of NAND devices with page size of 64 KiB, 128KiB, 256KiB and 512 +KiB. Also 2 separate 4GB NAND devices(one from SAMSUNG and one from MICRON) +were successfully tested. U-Boot was able to correctly detect the device +and read bad blocks.
Hmm, not sure we need to describe here what was, rather than what is.
+What is lacking? +================
+We need to add 64 bit support in cmd_nand.c and env_nand.c as well. +Without this certain diagnostcis
typo
will fail. For example, +issuing a "nand bad" command results in the same bad blocks being +found infinite times. This happens if we use a 4 GB NAND device. +This will not occur if NANDs of smalles than 4 GB are used.
s/of smalles than/smaller than/
+At this point of time it appears as if the entire common folder +needs to be updated with 64 bit values.
Yeah... If you want to put a concise note about this here, I'll add it, though an actual bug tracking system would be nice. :-)
-Scott
On Tue, Dec 01, 2009 at 01:06:07PM -0500, s-paulraj@ti.com wrote:
+MTD NAND 64 bit support: +========================
+The MTD NAND infrastructure in U-Boot(until release 2009.11) used only +32 bit values to represent device size. As a result of which if we use +a NAND device of size 4 GB and above, the MTD NAND driver will not
detect
+such a NAND device due to overflow. +NANDs comes in various flavours. There are some NANDs which are +internally 2 devices and have 2 chipselects. If the SOC specific +NAND driver is designed to treat each NAND device as a separate device +then we will still be able to detect the entire 4GB of a NAND device. +Each chipselect being responsible for 2 GB address space. +But if at the U-Boot level we want to have access to the entire 4GB
address
+space then the only way to achieve this is to update the MTD and NAND
drivers
+with 64 bit values. +The Linux kernel was updated with 64 bit values sometime in December
'08.
+The core NAND driver is now similar to the core NAND driver in the
kernel.
+We appropriately update the MTD layer in U-Boot. +In the process of syncing up with the kernel we have also updated the +NAND driver with other enhancements that made its way to the NAND
driver.
+After these features were added, testing was performed on a wide +range of NAND devices with page size of 64 KiB, 128KiB, 256KiB and 512 +KiB. Also 2 separate 4GB NAND devices(one from SAMSUNG and one from
MICRON)
+were successfully tested. U-Boot was able to correctly detect the
device
+and read bad blocks.
Hmm, not sure we need to describe here what was, rather than what is.
Let me know what parts you want removed. I just decided to put as much info as possible with a little history as well.
+What is lacking? +================
+We need to add 64 bit support in cmd_nand.c and env_nand.c as well. +Without this certain diagnostcis
typo
will fail. For example, +issuing a "nand bad" command results in the same bad blocks being +found infinite times. This happens if we use a 4 GB NAND device. +This will not occur if NANDs of smalles than 4 GB are used.
s/of smalles than/smaller than/
I'll fix the typos
+At this point of time it appears as if the entire common folder +needs to be updated with 64 bit values.
Yeah... If you want to put a concise note about this here, I'll add it, though an actual bug tracking system would be nice. :-)
Again let me know what sections are not required.
-Scott
I'll send an updated patch after your reply.
Sandeep
Paulraj, Sandeep wrote:
+At this point of time it appears as if the entire common folder +needs to be updated with 64 bit values.
Yeah... If you want to put a concise note about this here, I'll add it, though an actual bug tracking system would be nice. :-)
Again let me know what sections are not required.
-Scott
I'll send an updated patch after your reply.
Just keep it short and simple. Maybe something like:
64-bit offsets (i.e. devices which are 4GiB or larger) are not yet fully supported -- in particular, the code in common/cmd_nand.c and common/env_nand.c will have problems.
-Scott
participants (3)
-
Paulraj, Sandeep -
s-paulraj＠ti.com
-
Scott Wood