NAND ECC in linux-omap

NAND ECC in linux-omap

[Cliff Brake]

Hi,

I'm using the latest pm branch (based on linux-omap I think), and
running into the following problems.

The first is my x-loader uses software ECC.  Looking in the omap nand
driver, I made the following change which gets x-loader/u-boot working
again:

diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 133d515..1593c60 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -7,7 +7,7 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
  */
-#define CONFIG_MTD_NAND_OMAP_HWECC
+//#define CONFIG_MTD_NAND_OMAP_HWECC

 #include <linux/platform_device.h>
 #include <linux/dma-mapping.h>

But, I'm still getting a ton of ECC errors in JFFS2 flash filesystem.
Does anyone have any suggestions as to where to go from here?  I see
some patches on the mail lists from Sukumar Ghorai that make HW/SW ECC
selectable from the board file.

Thanks,
Cliff

-- 
=================
http://bec-systems.com

RE: NAND ECC in linux-omap

[Ghorai, Sukumar]

> -----Original Message-----
> From: Cliff Brake [mailto:cliff.brake@gmail.com]
> Sent: Wednesday, August 18, 2010 3:27 AM
> To: Linux OMAP Users; Ghorai, Sukumar
> Subject: NAND ECC in linux-omap
> 
> Hi,
> 
> I'm using the latest pm branch (based on linux-omap I think), and
> running into the following problems.
> 
> The first is my x-loader uses software ECC.  Looking in the omap nand
> driver, I made the following change which gets x-loader/u-boot working
> again:
> 
> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> index 133d515..1593c60 100644
> --- a/drivers/mtd/nand/omap2.c
> +++ b/drivers/mtd/nand/omap2.c
> @@ -7,7 +7,7 @@
>   * it under the terms of the GNU General Public License version 2 as
>   * published by the Free Software Foundation.
>   */
> -#define CONFIG_MTD_NAND_OMAP_HWECC
> +//#define CONFIG_MTD_NAND_OMAP_HWECC
> 
>  #include <linux/platform_device.h>
>  #include <linux/dma-mapping.h>
> 
> But, I'm still getting a ton of ECC errors in JFFS2 flash filesystem.
> Does anyone have any suggestions as to where to go from here?  I see
> some patches on the mail lists from Sukumar Ghorai that make HW/SW ECC
> selectable from the board file.
> 
> Thanks,
> Cliff
> 
[Ghorai] 
1. Can you send the git tree link and branch you are referring?
2. I am working to support the NAND BCH and not upstream yet, how you apply this patch in PM branch. 
3. which x-loader and u-boot you are referring? And no x-loader/ u-boot supports the BCH 

> --
> =================
> http://bec-systems.com

Re: NAND ECC in linux-omap

[Cliff Brake]

On Wed, Aug 18, 2010 at 12:14 AM, Ghorai, Sukumar <s-ghorai@ti.com> wrote:
> [Ghorai]
> 1. Can you send the git tree link and branch you are referring?

git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git
branch: pm
95e42b92313f229cbc9fc81bf68fe60aaee515aa

I'm pretty sure this branch tracks linux-omap.  I have not tested
linux-omap yet (git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git:master)

> 2. I am working to support the NAND BCH and not upstream yet, how you apply this patch in PM branch.

What do you mean by upstream?  I'm not sure what NAND changes are in
the above pm branch -- that is what I'm trying to figure out :-)
Perhaps you can suggest if I'm using BCH, etc.

> 3. which x-loader and u-boot you are referring? And no x-loader/ u-boot supports the BCH

I'm using the x-loader/u-boot from for the Gumstix Overo.  My
understanding is that it uses software -- likely not BCH, but I'm not
sure.

Thanks,
Cliff

-- 
=================
http://bec-systems.com

Re: NAND ECC in linux-omap

[Kevin Hilman]

Cliff Brake <cliff.brake@gmail.com> writes:

> On Wed, Aug 18, 2010 at 12:14 AM, Ghorai, Sukumar <s-ghorai@ti.com> wrote:
>> [Ghorai]
>> 1. Can you send the git tree link and branch you are referring?
>
> git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git
> branch: pm
> 95e42b92313f229cbc9fc81bf68fe60aaee515aa
>
> I'm pretty sure this branch tracks linux-omap.  

Yes, it does.

> I have not tested
> linux-omap yet (git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git:master)

the PM branch has nothing NAND/MTD related in it, so the problem should
be the same on linux-omap, but should be tested there as well to
eliminate any possible PM interactions.

Kevin

RE: NAND ECC in linux-omap

[Ghorai, Sukumar]

> -----Original Message-----
> From: Cliff Brake [mailto:cliff.brake@gmail.com]
> Sent: Wednesday, August 18, 2010 9:16 PM
> To: Ghorai, Sukumar
> Cc: Linux OMAP Users; Kamat, Nishant
> Subject: Re: NAND ECC in linux-omap
> 
> On Wed, Aug 18, 2010 at 12:14 AM, Ghorai, Sukumar <s-ghorai@ti.com> wrote:
> > [Ghorai]
> > 1. Can you send the git tree link and branch you are referring?
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git
> branch: pm
> 95e42b92313f229cbc9fc81bf68fe60aaee515aa
> 
> I'm pretty sure this branch tracks linux-omap.  I have not tested
> linux-omap yet
> (git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-
> 2.6.git:master)
> 
> > 2. I am working to support the NAND BCH and not upstream yet, how you
> apply this patch in PM branch.
> 
> What do you mean by upstream?  I'm not sure what NAND changes are in
> the above pm branch -- that is what I'm trying to figure out :-)
> Perhaps you can suggest if I'm using BCH, etc.
> 
> > 3. which x-loader and u-boot you are referring? And no x-loader/ u-boot
> supports the BCH
> 
> I'm using the x-loader/u-boot from for the Gumstix Overo.  My
> understanding is that it uses software -- likely not BCH, but I'm not
> sure.

[Ghorai] understand the problem, it's a nand ECC layout (location where ECC stors) problem, 
I think you flush the JFFS2 flash filesystem from u-boot and kernel not able to mount it. 
So let boot the image form say from MMC/SD or NFS (1st time); and use the utility after boot (flash_eraseall, nandwrite, ..) to write the JFFS2 image in NAND. And you can check JFFS2 mount or any further test.

If this does not help, send me the nanddump of the any page you write the data from u-boot.

> 
> Thanks,
> Cliff
> 
> --
> =================
> http://bec-systems.com

Re: NAND ECC in linux-omap

[Cliff Brake]

On Tue, Aug 24, 2010 at 9:51 AM, Ghorai, Sukumar <s-ghorai@ti.com> wrote:
>
>
>> -----Original Message-----
>> From: Cliff Brake [mailto:cliff.brake@gmail.com]
>> Sent: Wednesday, August 18, 2010 9:16 PM
>> To: Ghorai, Sukumar
>> Cc: Linux OMAP Users; Kamat, Nishant
>> Subject: Re: NAND ECC in linux-omap
>>
>> On Wed, Aug 18, 2010 at 12:14 AM, Ghorai, Sukumar <s-ghorai@ti.com> wrote:
>> > [Ghorai]
>> > 1. Can you send the git tree link and branch you are referring?
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git
>> branch: pm
>> 95e42b92313f229cbc9fc81bf68fe60aaee515aa
>>
>> I'm pretty sure this branch tracks linux-omap.  I have not tested
>> linux-omap yet
>> (git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-
>> 2.6.git:master)
>>
>> > 2. I am working to support the NAND BCH and not upstream yet, how you
>> apply this patch in PM branch.
>>
>> What do you mean by upstream?  I'm not sure what NAND changes are in
>> the above pm branch -- that is what I'm trying to figure out :-)
>> Perhaps you can suggest if I'm using BCH, etc.
>>
>> > 3. which x-loader and u-boot you are referring? And no x-loader/ u-boot
>> supports the BCH
>>
>> I'm using the x-loader/u-boot from for the Gumstix Overo.  My
>> understanding is that it uses software -- likely not BCH, but I'm not
>> sure.
>
> [Ghorai] understand the problem, it's a nand ECC layout (location where ECC stors) problem,
> I think you flush the JFFS2 flash filesystem from u-boot and kernel not able to mount it.
> So let boot the image form say from MMC/SD or NFS (1st time); and use the utility after boot (flash_eraseall, nandwrite, ..) to write the JFFS2 image in NAND. And you can check JFFS2 mount or any further test.
>
> If this does not help, send me the nanddump of the any page you write the data from u-boot.

Thanks for the suggestions.  I did write the JFFS2 image with the
following commands:

flash_erasall -j /dev/mtd4

I then mounted the fs with:
mount -t jffs2 /dev/mtdblock4 /media/mtdblock4

and extracted a tar archive into it.  I immediately get some ECC
errors.  If I unmount, and re-mount I get continuous streaming ECC
errors.  As Linux is managing the entire process, it seems there must
be a disconnect somewhere.  Also, note that I disabled HW ECC in
drivers/mtd/nand/omap2.c so that I could get x-load and u-boot to work
with images written with nandwrite as noted previously in this thread.

I then reverted my change that disables hw ECC, and the above
procedure worked fine.  So I guess I need to figure out some way that
I can write images to the u-boot/kernel partitions that is compatible
with my x-loader/u-boot and at the same time keep JFFS2 working.  At
the present, it seems that:

- x-loader/u-boot will only read images written in Linux with hw ECC
disabled in omap2.c
- JFFS2 will only work with hw ECC enabled in omap2.c

Again, thanks for the explanation, and I appreciate any suggestions
going forward.

Thanks,
Cliff

-- 
=================
http://bec-systems.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: NAND ECC in linux-omap

[Vimal Singh]

On Tue, Aug 24, 2010 at 8:04 PM, Cliff Brake <cliff.brake@gmail.com> wrote:
>
> flash_erasall -j /dev/mtd4

Give a try without using '-j' option... If ECC layout is the suspect..
this may help.


-- 
Regards,
Vimal Singh

Re: NAND ECC in linux-omap

[Vimal Singh]

Adding LO and MTD list too for more comments.

On Sat, Aug 28, 2010 at 1:40 AM, Vimal Singh <vimal.newwork@gmail.com> wrote:
> On Sat, Aug 28, 2010 at 12:00 AM, Cliff Brake <cliff.brake@gmail.com> wrote:
>> On Fri, Aug 27, 2010 at 2:29 PM, Cliff Brake <cliff.brake@gmail.com> wrote:
>>> On Fri, Aug 27, 2010 at 11:13 AM, Ghorai, Sukumar <s-ghorai@ti.com> wrote:
>>>>
>>>>> -----Original Message-----
>>>>> From: Vimal Singh [mailto:vimal.newwork@gmail.com]
>>>>> Sent: Tuesday, August 24, 2010 10:41 PM
>>>>> To: Cliff Brake
>>>>> Cc: Ghorai, Sukumar; Linux OMAP Users; Kamat, Nishant
>>>>> Subject: Re: NAND ECC in linux-omap
>>>>>
>>>>> On Tue, Aug 24, 2010 at 8:04 PM, Cliff Brake <cliff.brake@gmail.com>
>>>>> wrote:
>>>>> >
>>>>> > flash_erasall -j /dev/mtd4
>>>>>
>>>>> Give a try without using '-j' option... If ECC layout is the suspect..
>>>>> this may help.
>>>> [Ghorai]
>>>> Cliff,
>>>> I did not able to spend much time on it to get into the problem.
>>>> But would you please try using these additional patch(4) that yet to upstream?
>>>> https://patchwork.kernel.org/patch/116554/
>>>> https://patchwork.kernel.org/patch/116553/
>>>> https://patchwork.kernel.org/patch/116555/
>>>> https://patchwork.kernel.org/patch/116556/
>>>> And select/change the proper ECC in -
>>>> arch/arm/mach-omap2/board-flash.c: line No.148;
>>>> board_nand_data.ecc_opt         = OMAP_ECC_HAMMING_CODE_HW;
>>>
>>> Thanks for the patches.  Now I get the following:
>>>
>>> root@ts3:~# flash_eraseall /dev/mtd1
>>> Erasing 128 Kibyte @ 1c0000 -- 100 % complete.
>>> root@ts3:~# nandwrite -p /dev/mtd1 /media/mmcblk0p1/u-boot.bin
>>> Writing data to block 0 at offset 0x0
>>>
>>> And the operation hangs.
>
> Drop these patches. Please just give one more try after reverting last
> 2 commits in omap2.c driver:
> 1. omap3 nand: cleanup virtual address usages
> and
> 2. omap3 gpmc: functionality enhancement
>
> I suspect something wrong with patch '2'. I will look into it more.

I can see the problem in '1' patch only. In this patch, see below change:

------------------------------------------

static void omap_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int ctrl)
 {
        struct omap_nand_info *info = container_of(mtd,
                                        struct omap_nand_info, mtd);
-       switch (ctrl) {
-       case NAND_CTRL_CHANGE | NAND_CTRL_CLE:
-               info->nand.IO_ADDR_W = info->gpmc_cs_baseaddr +
-                                               GPMC_CS_NAND_COMMAND;
-               info->nand.IO_ADDR_R = info->gpmc_cs_baseaddr +
-                                               GPMC_CS_NAND_DATA;
-               break;
-
-       case NAND_CTRL_CHANGE | NAND_CTRL_ALE:
-               info->nand.IO_ADDR_W = info->gpmc_cs_baseaddr +
-                                               GPMC_CS_NAND_ADDRESS;
-               info->nand.IO_ADDR_R = info->gpmc_cs_baseaddr +
-                                               GPMC_CS_NAND_DATA;
-               break;
-
-       case NAND_CTRL_CHANGE | NAND_NCE:
-               info->nand.IO_ADDR_W = info->gpmc_cs_baseaddr +
-                                               GPMC_CS_NAND_DATA;
-               info->nand.IO_ADDR_R = info->gpmc_cs_baseaddr +
-                                               GPMC_CS_NAND_DATA;
-               break;
-       }

-       if (cmd != NAND_CMD_NONE)
-               __raw_writeb(cmd, info->nand.IO_ADDR_W);
+       if (cmd != NAND_CMD_NONE) {
+               if (ctrl & NAND_CLE)
+                       gpmc_nand_write(info->gpmc_cs, GPMC_NAND_COMMAND, cmd);
+
+               else if (ctrl & NAND_ALE)
+                       gpmc_nand_write(info->gpmc_cs, GPMC_NAND_ADDRESS, cmd);
+
+               else /* NAND_NCE */
+                       gpmc_nand_write(info->gpmc_cs, GPMC_NAND_DATA, cmd);
+       }
 }

---------------------------------------------

The new (changed) hwcontrol routine still can latch command and
address to correct gpmc nand registers. But it is failing to set '
info->nand.IO_ADDR_W' and 'info->nand.IO_ADDR_R'.
Which will be used by write/read routines to:  write to (IO_ADDR_W) or
read from (IO_ADDR_R).


-- 
Regards,
Vimal Singh
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: NAND ECC in linux-omap

[Vimal Singh]

Adding LO and MTD list too for more comments.

On Sat, Aug 28, 2010 at 1:40 AM, Vimal Singh <vimal.newwork@gmail.com> wrote:
> On Sat, Aug 28, 2010 at 12:00 AM, Cliff Brake <cliff.brake@gmail.com> wrote:
>> On Fri, Aug 27, 2010 at 2:29 PM, Cliff Brake <cliff.brake@gmail.com> wrote:
>>> On Fri, Aug 27, 2010 at 11:13 AM, Ghorai, Sukumar <s-ghorai@ti.com> wrote:
>>>>
>>>>> -----Original Message-----
>>>>> From: Vimal Singh [mailto:vimal.newwork@gmail.com]
>>>>> Sent: Tuesday, August 24, 2010 10:41 PM
>>>>> To: Cliff Brake
>>>>> Cc: Ghorai, Sukumar; Linux OMAP Users; Kamat, Nishant
>>>>> Subject: Re: NAND ECC in linux-omap
>>>>>
>>>>> On Tue, Aug 24, 2010 at 8:04 PM, Cliff Brake <cliff.brake@gmail.com>
>>>>> wrote:
>>>>> >
>>>>> > flash_erasall -j /dev/mtd4
>>>>>
>>>>> Give a try without using '-j' option... If ECC layout is the suspect..
>>>>> this may help.
>>>> [Ghorai]
>>>> Cliff,
>>>> I did not able to spend much time on it to get into the problem.
>>>> But would you please try using these additional patch(4) that yet to upstream?
>>>> https://patchwork.kernel.org/patch/116554/
>>>> https://patchwork.kernel.org/patch/116553/
>>>> https://patchwork.kernel.org/patch/116555/
>>>> https://patchwork.kernel.org/patch/116556/
>>>> And select/change the proper ECC in -
>>>> arch/arm/mach-omap2/board-flash.c: line No.148;
>>>> board_nand_data.ecc_opt         = OMAP_ECC_HAMMING_CODE_HW;
>>>
>>> Thanks for the patches.  Now I get the following:
>>>
>>> root@ts3:~# flash_eraseall /dev/mtd1
>>> Erasing 128 Kibyte @ 1c0000 -- 100 % complete.
>>> root@ts3:~# nandwrite -p /dev/mtd1 /media/mmcblk0p1/u-boot.bin
>>> Writing data to block 0 at offset 0x0
>>>
>>> And the operation hangs.
>
> Drop these patches. Please just give one more try after reverting last
> 2 commits in omap2.c driver:
> 1. omap3 nand: cleanup virtual address usages
> and
> 2. omap3 gpmc: functionality enhancement
>
> I suspect something wrong with patch '2'. I will look into it more.

I can see the problem in '1' patch only. In this patch, see below change:

------------------------------------------

static void omap_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int ctrl)
 {
        struct omap_nand_info *info = container_of(mtd,
                                        struct omap_nand_info, mtd);
-       switch (ctrl) {
-       case NAND_CTRL_CHANGE | NAND_CTRL_CLE:
-               info->nand.IO_ADDR_W = info->gpmc_cs_baseaddr +
-                                               GPMC_CS_NAND_COMMAND;
-               info->nand.IO_ADDR_R = info->gpmc_cs_baseaddr +
-                                               GPMC_CS_NAND_DATA;
-               break;
-
-       case NAND_CTRL_CHANGE | NAND_CTRL_ALE:
-               info->nand.IO_ADDR_W = info->gpmc_cs_baseaddr +
-                                               GPMC_CS_NAND_ADDRESS;
-               info->nand.IO_ADDR_R = info->gpmc_cs_baseaddr +
-                                               GPMC_CS_NAND_DATA;
-               break;
-
-       case NAND_CTRL_CHANGE | NAND_NCE:
-               info->nand.IO_ADDR_W = info->gpmc_cs_baseaddr +
-                                               GPMC_CS_NAND_DATA;
-               info->nand.IO_ADDR_R = info->gpmc_cs_baseaddr +
-                                               GPMC_CS_NAND_DATA;
-               break;
-       }

-       if (cmd != NAND_CMD_NONE)
-               __raw_writeb(cmd, info->nand.IO_ADDR_W);
+       if (cmd != NAND_CMD_NONE) {
+               if (ctrl & NAND_CLE)
+                       gpmc_nand_write(info->gpmc_cs, GPMC_NAND_COMMAND, cmd);
+
+               else if (ctrl & NAND_ALE)
+                       gpmc_nand_write(info->gpmc_cs, GPMC_NAND_ADDRESS, cmd);
+
+               else /* NAND_NCE */
+                       gpmc_nand_write(info->gpmc_cs, GPMC_NAND_DATA, cmd);
+       }
 }

---------------------------------------------

The new (changed) hwcontrol routine still can latch command and
address to correct gpmc nand registers. But it is failing to set '
info->nand.IO_ADDR_W' and 'info->nand.IO_ADDR_R'.
Which will be used by write/read routines to:  write to (IO_ADDR_W) or
read from (IO_ADDR_R).


-- 
Regards,
Vimal Singh

RE: NAND ECC in linux-omap

[Ghorai, Sukumar]

Vimal,

> -----Original Message-----
> From: Vimal Singh [mailto:vimal.newwork@gmail.com]
> Sent: Saturday, August 28, 2010 2:07 AM
> To: Cliff Brake
> Cc: Ghorai, Sukumar; Kamat, Nishant; linux-omap@vger.kernel.org; Linux MTD
> Subject: Re: NAND ECC in linux-omap
> 
> Adding LO and MTD list too for more comments.
> 
> On Sat, Aug 28, 2010 at 1:40 AM, Vimal Singh <vimal.newwork@gmail.com>
> wrote:
> > On Sat, Aug 28, 2010 at 12:00 AM, Cliff Brake <cliff.brake@gmail.com>
> wrote:
> >> On Fri, Aug 27, 2010 at 2:29 PM, Cliff Brake <cliff.brake@gmail.com>
> wrote:
> >>> On Fri, Aug 27, 2010 at 11:13 AM, Ghorai, Sukumar <s-ghorai@ti.com>
> wrote:
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Vimal Singh [mailto:vimal.newwork@gmail.com]
> >>>>> Sent: Tuesday, August 24, 2010 10:41 PM
> >>>>> To: Cliff Brake
> >>>>> Cc: Ghorai, Sukumar; Linux OMAP Users; Kamat, Nishant
> >>>>> Subject: Re: NAND ECC in linux-omap
> >>>>>
> >>>>> On Tue, Aug 24, 2010 at 8:04 PM, Cliff Brake <cliff.brake@gmail.com>
> >>>>> wrote:
> >>>>> >
> >>>>> > flash_erasall -j /dev/mtd4
> >>>>>
> >>>>> Give a try without using '-j' option... If ECC layout is the
> suspect..
> >>>>> this may help.
> >>>> [Ghorai]
> >>>> Cliff,
> >>>> I did not able to spend much time on it to get into the problem.
> >>>> But would you please try using these additional patch(4) that yet to
> upstream?
> >>>> https://patchwork.kernel.org/patch/116554/
> >>>> https://patchwork.kernel.org/patch/116553/
> >>>> https://patchwork.kernel.org/patch/116555/
> >>>> https://patchwork.kernel.org/patch/116556/
> >>>> And select/change the proper ECC in -
> >>>> arch/arm/mach-omap2/board-flash.c: line No.148;
> >>>> board_nand_data.ecc_opt         = OMAP_ECC_HAMMING_CODE_HW;
> >>>
> >>> Thanks for the patches.  Now I get the following:
> >>>
> >>> root@ts3:~# flash_eraseall /dev/mtd1
> >>> Erasing 128 Kibyte @ 1c0000 -- 100 % complete.
> >>> root@ts3:~# nandwrite -p /dev/mtd1 /media/mmcblk0p1/u-boot.bin
> >>> Writing data to block 0 at offset 0x0
> >>>
> >>> And the operation hangs.
> >
> > Drop these patches. Please just give one more try after reverting last
> > 2 commits in omap2.c driver:
> > 1. omap3 nand: cleanup virtual address usages
> > and
> > 2. omap3 gpmc: functionality enhancement
> >
> > I suspect something wrong with patch '2'. I will look into it more.
> 
> I can see the problem in '1' patch only. In this patch, see below change:
> 
> ------------------------------------------
> 
> static void omap_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int
> ctrl)
>  {
>         struct omap_nand_info *info = container_of(mtd,
>                                         struct omap_nand_info, mtd);
> -       switch (ctrl) {
> -       case NAND_CTRL_CHANGE | NAND_CTRL_CLE:
> -               info->nand.IO_ADDR_W = info->gpmc_cs_baseaddr +
> -                                               GPMC_CS_NAND_COMMAND;
> -               info->nand.IO_ADDR_R = info->gpmc_cs_baseaddr +
> -                                               GPMC_CS_NAND_DATA;
> -               break;
> -
> -       case NAND_CTRL_CHANGE | NAND_CTRL_ALE:
> -               info->nand.IO_ADDR_W = info->gpmc_cs_baseaddr +
> -                                               GPMC_CS_NAND_ADDRESS;
> -               info->nand.IO_ADDR_R = info->gpmc_cs_baseaddr +
> -                                               GPMC_CS_NAND_DATA;
> -               break;
> -
> -       case NAND_CTRL_CHANGE | NAND_NCE:
> -               info->nand.IO_ADDR_W = info->gpmc_cs_baseaddr +
> -                                               GPMC_CS_NAND_DATA;
> -               info->nand.IO_ADDR_R = info->gpmc_cs_baseaddr +
> -                                               GPMC_CS_NAND_DATA;
> -               break;
> -       }
> 
> -       if (cmd != NAND_CMD_NONE)
> -               __raw_writeb(cmd, info->nand.IO_ADDR_W);
> +       if (cmd != NAND_CMD_NONE) {
> +               if (ctrl & NAND_CLE)
> +                       gpmc_nand_write(info->gpmc_cs, GPMC_NAND_COMMAND,
> cmd);
> +
> +               else if (ctrl & NAND_ALE)
> +                       gpmc_nand_write(info->gpmc_cs, GPMC_NAND_ADDRESS,
> cmd);
> +
> +               else /* NAND_NCE */
> +                       gpmc_nand_write(info->gpmc_cs, GPMC_NAND_DATA,
> cmd);
> +       }
>  }
> 
> ---------------------------------------------
> 
> The new (changed) hwcontrol routine still can latch command and
> address to correct gpmc nand registers. But it is failing to set '
> info->nand.IO_ADDR_W' and 'info->nand.IO_ADDR_R'.
> Which will be used by write/read routines to:  write to (IO_ADDR_W) or
> read from (IO_ADDR_R).
[Ghorai]
1. You mean revert the old code will solve the issue mentioned by Cliff? 
2. Can you check if the problem already exists before applying these patch itself?
 
> 
> 
> --
> Regards,
> Vimal Singh
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: NAND ECC in linux-omap

[Ghorai, Sukumar]

Vimal,

> -----Original Message-----
> From: Vimal Singh [mailto:vimal.newwork@gmail.com]
> Sent: Saturday, August 28, 2010 2:07 AM
> To: Cliff Brake
> Cc: Ghorai, Sukumar; Kamat, Nishant; linux-omap@vger.kernel.org; Linux MTD
> Subject: Re: NAND ECC in linux-omap
> 
> Adding LO and MTD list too for more comments.
> 
> On Sat, Aug 28, 2010 at 1:40 AM, Vimal Singh <vimal.newwork@gmail.com>
> wrote:
> > On Sat, Aug 28, 2010 at 12:00 AM, Cliff Brake <cliff.brake@gmail.com>
> wrote:
> >> On Fri, Aug 27, 2010 at 2:29 PM, Cliff Brake <cliff.brake@gmail.com>
> wrote:
> >>> On Fri, Aug 27, 2010 at 11:13 AM, Ghorai, Sukumar <s-ghorai@ti.com>
> wrote:
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Vimal Singh [mailto:vimal.newwork@gmail.com]
> >>>>> Sent: Tuesday, August 24, 2010 10:41 PM
> >>>>> To: Cliff Brake
> >>>>> Cc: Ghorai, Sukumar; Linux OMAP Users; Kamat, Nishant
> >>>>> Subject: Re: NAND ECC in linux-omap
> >>>>>
> >>>>> On Tue, Aug 24, 2010 at 8:04 PM, Cliff Brake <cliff.brake@gmail.com>
> >>>>> wrote:
> >>>>> >
> >>>>> > flash_erasall -j /dev/mtd4
> >>>>>
> >>>>> Give a try without using '-j' option... If ECC layout is the
> suspect..
> >>>>> this may help.
> >>>> [Ghorai]
> >>>> Cliff,
> >>>> I did not able to spend much time on it to get into the problem.
> >>>> But would you please try using these additional patch(4) that yet to
> upstream?
> >>>> https://patchwork.kernel.org/patch/116554/
> >>>> https://patchwork.kernel.org/patch/116553/
> >>>> https://patchwork.kernel.org/patch/116555/
> >>>> https://patchwork.kernel.org/patch/116556/
> >>>> And select/change the proper ECC in -
> >>>> arch/arm/mach-omap2/board-flash.c: line No.148;
> >>>> board_nand_data.ecc_opt         = OMAP_ECC_HAMMING_CODE_HW;
> >>>
> >>> Thanks for the patches.  Now I get the following:
> >>>
> >>> root@ts3:~# flash_eraseall /dev/mtd1
> >>> Erasing 128 Kibyte @ 1c0000 -- 100 % complete.
> >>> root@ts3:~# nandwrite -p /dev/mtd1 /media/mmcblk0p1/u-boot.bin
> >>> Writing data to block 0 at offset 0x0
> >>>
> >>> And the operation hangs.
> >
> > Drop these patches. Please just give one more try after reverting last
> > 2 commits in omap2.c driver:
> > 1. omap3 nand: cleanup virtual address usages
> > and
> > 2. omap3 gpmc: functionality enhancement
> >
> > I suspect something wrong with patch '2'. I will look into it more.
> 
> I can see the problem in '1' patch only. In this patch, see below change:
> 
> ------------------------------------------
> 
> static void omap_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int
> ctrl)
>  {
>         struct omap_nand_info *info = container_of(mtd,
>                                         struct omap_nand_info, mtd);
> -       switch (ctrl) {
> -       case NAND_CTRL_CHANGE | NAND_CTRL_CLE:
> -               info->nand.IO_ADDR_W = info->gpmc_cs_baseaddr +
> -                                               GPMC_CS_NAND_COMMAND;
> -               info->nand.IO_ADDR_R = info->gpmc_cs_baseaddr +
> -                                               GPMC_CS_NAND_DATA;
> -               break;
> -
> -       case NAND_CTRL_CHANGE | NAND_CTRL_ALE:
> -               info->nand.IO_ADDR_W = info->gpmc_cs_baseaddr +
> -                                               GPMC_CS_NAND_ADDRESS;
> -               info->nand.IO_ADDR_R = info->gpmc_cs_baseaddr +
> -                                               GPMC_CS_NAND_DATA;
> -               break;
> -
> -       case NAND_CTRL_CHANGE | NAND_NCE:
> -               info->nand.IO_ADDR_W = info->gpmc_cs_baseaddr +
> -                                               GPMC_CS_NAND_DATA;
> -               info->nand.IO_ADDR_R = info->gpmc_cs_baseaddr +
> -                                               GPMC_CS_NAND_DATA;
> -               break;
> -       }
> 
> -       if (cmd != NAND_CMD_NONE)
> -               __raw_writeb(cmd, info->nand.IO_ADDR_W);
> +       if (cmd != NAND_CMD_NONE) {
> +               if (ctrl & NAND_CLE)
> +                       gpmc_nand_write(info->gpmc_cs, GPMC_NAND_COMMAND,
> cmd);
> +
> +               else if (ctrl & NAND_ALE)
> +                       gpmc_nand_write(info->gpmc_cs, GPMC_NAND_ADDRESS,
> cmd);
> +
> +               else /* NAND_NCE */
> +                       gpmc_nand_write(info->gpmc_cs, GPMC_NAND_DATA,
> cmd);
> +       }
>  }
> 
> ---------------------------------------------
> 
> The new (changed) hwcontrol routine still can latch command and
> address to correct gpmc nand registers. But it is failing to set '
> info->nand.IO_ADDR_W' and 'info->nand.IO_ADDR_R'.
> Which will be used by write/read routines to:  write to (IO_ADDR_W) or
> read from (IO_ADDR_R).
[Ghorai]
1. You mean revert the old code will solve the issue mentioned by Cliff? 
2. Can you check if the problem already exists before applying these patch itself?
 
> 
> 
> --
> Regards,
> Vimal Singh