[U-Boot] [PATCH] NAND: Updating the NAND README

[U-Boot] [PATCH] NAND: Updating the NAND README

[s-paulraj at ti.com]

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

[U-Boot] [PATCH] NAND: Updating the NAND README

[Scott Wood]

On Tue, Dec 01, 2009 at 01:06:07PM -0500, s-paulraj at 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

[U-Boot] [PATCH] NAND: Updating the NAND README

[Paulraj, Sandeep]

> 
> On Tue, Dec 01, 2009 at 01:06:07PM -0500, s-paulraj at 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

[U-Boot] [PATCH] NAND: Updating the NAND README

[Scott Wood]

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