UbiFS + HWECC(?) + BeagleBoard = fail

UbiFS + HWECC(?) + BeagleBoard = fail

[[AvataR]]

Hi. After moving to upstream 2.6.3{5,6,7} kernels, i forced to use jffs2
instead of ubifs, because of lot CRC errors. If i use prefetch/dma, i
can attach to ubi, make volume, write data, reboot - and got lots of CRC
errors. Without prefetch i just couldn't do anything to ubi. 

Looks like hw/sw bug in ubi

Re: UbiFS + HWECC(?) + BeagleBoard = fail

[Grazvydas Ignotas]

On Sun, Nov 7, 2010 at 9:40 AM, [AvataR] <public.avatar@gmail.com> wrote:
> Hi. After moving to upstream 2.6.3{5,6,7} kernels, i forced to use jffs2
> instead of ubifs, because of lot CRC errors. If i use prefetch/dma, i
> can attach to ubi, make volume, write data, reboot - and got lots of CRC
> errors. Without prefetch i just couldn't do anything to ubi.
>
> Looks like hw/sw bug in ubi

Looks like Sukumar's recent changes broke subpage reads that are
needed for UBI to operate. You can try commenting out #define
CONFIG_MTD_NAND_OMAP_HWECC in drivers/mtd/nand/omap2.c and disabling
MTD_NAND_OMAP_PREFETCH, with that it mostly works for me but sometimes
spits out ECC error or two.

Re: UbiFS + HWECC(?) + BeagleBoard = fail

[Luca Ceresoli]

On Mon, 8 Nov 2010 13:08:44 +0200, Grazvydas Ignotas wrote:
>On Sun, Nov 7, 2010 at 9:40 AM, [AvataR] <public.avatar@xxxxxxxxx> wrote:
>> Hi. After moving to upstream 2.6.3{5,6,7} kernels, i forced to use jffs2
>> instead of ubifs, because of lot CRC errors. If i use prefetch/dma, i
>> can attach to ubi, make volume, write data, reboot - and got lots of CRC
>> errors. Without prefetch i just couldn't do anything to ubi.
>>
>> Looks like hw/sw bug in ubi
>
>Looks like Sukumar's recent changes broke subpage reads that are
>needed for UBI to operate. You can try commenting out #define
>CONFIG_MTD_NAND_OMAP_HWECC in drivers/mtd/nand/omap2.c and disabling
>MTD_NAND_OMAP_PREFETCH, with that it mostly works for me but sometimes
>spits out ECC error or two.

I think this is the same bug reported back in august in
http://www.spinics.net/lists/linux-omap/msg34452.html, right?

I've been hit by this as well, and it seems to be still there, at least in

commit afd2d11e00520b7440003987be2ee4aab7c32901
Merge: 7fd1cff 734b4c7
Author: Tony Lindgren <tony@atomide.com>
Date:   Wed Dec 1 13:56:37 2010 -0800

    Merge branch 'devel-gpio'

While I thank you for you proposed solution, I see it does not work here.
In fact I commented the #define CONFIG_MTD_NAND_OMAP_HWECC and left
MTD_NAND_OMAP_PREFETCH disabled as it previously was, and got compilation
errors:

drivers/mtd/nand/omap2.c:1: warning: data definition has no type or storage class
drivers/mtd/nand/omap2.c:1: warning: type defaults to 'int' in declaration of 'B1'
drivers/mtd/nand/omap2.c:1: error: expected identifier or '(' before numeric constant
drivers/mtd/nand/omap2.c:1:9: error: invalid suffix "c" on integer constant
drivers/mtd/nand/omap2.c:1: error: expected identifier or '(' before numeric constant

As it looks to me like a very serious and very ancient bug, I wonder if I
missed something.

Or is any patch around to fix this?

Any pointer would be greatly appreciated.

Thanks,
Luca Ceresoli

Re: UbiFS + HWECC(?) + BeagleBoard = fail

[Luca Ceresoli]

Luca Ceresoli wrote:
> While I thank you for you proposed solution, I see it does not work here.
> In fact I commented the #define CONFIG_MTD_NAND_OMAP_HWECC and left
> MTD_NAND_OMAP_PREFETCH disabled as it previously was, and got compilation
> errors:

Wrong, sorry. Your solution compiles and works. I had another change in that
file that broke compilation.

Nevertheless, it's not clear to me whether the long-term direction is to
switch to HWECC, and if it is expected to work in current builds, or if
SWECC in here to stay.

Thanks,
Luca

Re: UbiFS + HWECC(?) + BeagleBoard = fail

[Charles Manning]

On Tuesday 07 December 2010 23:29:59 Luca Ceresoli wrote:
> Luca Ceresoli wrote:
> > While I thank you for you proposed solution, I see it does not work here.
> > In fact I commented the #define CONFIG_MTD_NAND_OMAP_HWECC and left
> > MTD_NAND_OMAP_PREFETCH disabled as it previously was, and got compilation
> > errors:
>
> Wrong, sorry. Your solution compiles and works. I had another change in
> that file that broke compilation.

Luca, I have been having similar problems on a hacked Overo kernel.

I have no problems with 2.6.35.

I tried just commenting out the define and disabling PREFETCH and did not get 
a good boot due to ubi not finding the volume info.

Are you loading up a UBI image with uboot?

Are you using the ubi volume as rootfs?

>
> Nevertheless, it's not clear to me whether the long-term direction is to
> switch to HWECC, and if it is expected to work in current builds, or if
> SWECC in here to stay.
>

Clearly HWECC has some advantages, but UBI and HWECC need some effort to get 
working together.

-- Charles

Re: UbiFS + HWECC(?) + BeagleBoard = fail

[Luca Ceresoli]

Charles Manning wrote:
> Luca, I have been having similar problems on a hacked Overo kernel.
> 
> I have no problems with 2.6.35.
> 
> I tried just commenting out the define and disabling PREFETCH and did not get 
> a good boot due to ubi not finding the volume info.
> 
> Are you loading up a UBI image with uboot?
> 
> Are you using the ubi volume as rootfs?

To make it work again, I did from u-boot:
- nand scrub (*completely* wipe the NAND)
- ubi part nand0,3 (recreate partitions)
- ubi create rootfs 400000
- ...create other partitions...
- ubi write ... (to rewrite rootfs)
- finally, boot with the kernel having the define commented and PREFETCH off.

Not all of these may be needed, but this way I got the board up and running again.

Luca

Re: UbiFS + HWECC(?) + BeagleBoard = fail

[Charles Manning]

On Thursday 09 December 2010 21:30:48 Luca Ceresoli wrote:
> Charles Manning wrote:
> > Luca, I have been having similar problems on a hacked Overo kernel.
> >
> > I have no problems with 2.6.35.
> >
> > I tried just commenting out the define and disabling PREFETCH and did not
> > get a good boot due to ubi not finding the volume info.
> >
> > Are you loading up a UBI image with uboot?
> >
> > Are you using the ubi volume as rootfs?
>
> To make it work again, I did from u-boot:
> - nand scrub (*completely* wipe the NAND)
> - ubi part nand0,3 (recreate partitions)
> - ubi create rootfs 400000
> - ...create other partitions...
> - ubi write ... (to rewrite rootfs)
> - finally, boot with the kernel having the define commented and PREFETCH
> off.
>
> Not all of these may be needed, but this way I got the board up and running
> again.
>
> Luca

What branch are you working from?

I tried working from a reasonably recent master on 
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git

I found that reads via the  prefetch eengine work, but reads via 
        ioread16_rep(nand->IO_ADDR_R, buf, len / 2)
do not.

Perhaps this is due to the address not being set up properly. Any clues?

I found that I can make everything work by realigning all accesses in 
nand_base.c to be 4-byte aligned.


-- Charles

Re: UbiFS + HWECC(?) + BeagleBoard = fail

[Charles Manning]

On Wednesday 15 December 2010 17:13:42 Charles Manning wrote:
> On Thursday 09 December 2010 21:30:48 Luca Ceresoli wrote:
> > Charles Manning wrote:
> > > Luca, I have been having similar problems on a hacked Overo kernel.
> > >
> > > I have no problems with 2.6.35.
> > >
> > > I tried just commenting out the define and disabling PREFETCH and did
> > > not get a good boot due to ubi not finding the volume info.
> > >
> > > Are you loading up a UBI image with uboot?
> > >
> > > Are you using the ubi volume as rootfs?
> >
> > To make it work again, I did from u-boot:
> > - nand scrub (*completely* wipe the NAND)
> > - ubi part nand0,3 (recreate partitions)
> > - ubi create rootfs 400000
> > - ...create other partitions...
> > - ubi write ... (to rewrite rootfs)
> > - finally, boot with the kernel having the define commented and PREFETCH
> > off.
> >
> > Not all of these may be needed, but this way I got the board up and
> > running again.
> >
> > Luca
>
> What branch are you working from?
>
> I tried working from a reasonably recent master on
> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
>
> I found that reads via the  prefetch eengine work, but reads via
>         ioread16_rep(nand->IO_ADDR_R, buf, len / 2)
> do not.
>
> Perhaps this is due to the address not being set up properly. Any clues?
>
> I found that I can make everything work by realigning all accesses in
> nand_base.c to be 4-byte aligned.
>

This change does what I need.

--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -245,6 +245,18 @@ static void omap_read_buf_pref(struct mtd_info *mtd, 
u_char *buf, int len)
        int ret = 0;
        u32 *p = (u32 *)buf;
 
+       /* u32 align the buffer and read */
+       /* NB: This assumes the buf ptr can be aligned *down* which is a 
valid.
+        * Assumption when dealing with ecc buffers etc.
+        */
+       u32 addr = (u32)p;
+
+       int diff = addr & 3;
+       addr -= diff;
+       len += diff;
+       len = (len + 3) & ~3;
+       p = (u32 *)addr;
+
        /* take care of subpage reads */
        if (len % 4) {
                if (info->nand.options & NAND_BUSWIDTH_16)

Charles