JFFS2+NAND problem in 2.6.13-at91

JFFS2+NAND problem in 2.6.13-at91

[Aras Vaichas]

Hi,

I was previously using 2.6.12-rc1, AT91 with JFFS2 on NAND and I had no
problems whatsoever with using JFFS2 on NAND.

I recently upgraded to 2.6.13 and now JFFS2 on NAND seems a little broken ...

This is what I usually do when configuring a new board:

# flash_eraseall -j /dev/mtd3
# mount -t jffs2 /dev/mtdblock3 /mnt/NAND
# copy FS to /mnt/NAND, etc ,etc

but now the mount fails with output::

/root # mount -t jffs2 /dev/mtdblock3 /mnt/NAND
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00028038: 0xffff
instead

<SNIP> much of the same ...

jffs2_scan_eraseblock(): Node at 0x00b28008 {0x1985, 0x2003, 0x00000008) has
invalid CRC 0xffffffdf (calculated 0x6b7c27e6)
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00b2800c: 0x0008
instead

<SNIP> much of the same ...

jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00ff0030: 0xffff
instead
Cowardly refusing to erase blocks on filesystem with no valid JFFS2 nodes
empty_blocks 0, bad_blocks 0, c->nr_blocks 1024
mount: Mounting /dev/mtdblock3 on /mnt/NAND failed: Input/output error


I had a look at previous posts and I couldn't find any answers, so I enabled
debugging for MTD at level 3 and ... the mount worked(!) and I could write a
file to NAND, reboot, remount and the file was still there. So it proves that
the formatting was correct.

When I changed the MTD debugging to level 2 (or less), the mount started to
fail again. Therefore something in the reading from the NAND must be incorrect.

This sounds like some sort of timing issues to me if switching on debugging
output causes the system to start working.

Has anyone else seen this problem?

regards,

Aras Vaichas

Re: JFFS2+NAND problem in 2.6.13-at91

[Aras Vaichas]

Aras Vaichas wrote:
> Hi,
> 
> I was previously using 2.6.12-rc1, AT91 with JFFS2 on NAND and I had no
> problems whatsoever with using JFFS2 on NAND.
> 
> I recently upgraded to 2.6.13 and now JFFS2 on NAND seems a little broken ...

<SNIP>

> This sounds like some sort of timing issues to me if switching on debugging
> output causes the system to start working.

I did a quick experiment and I added a 1ms delay at the end of each command as
a test and it "fixes" the problem.

in at91_nand.c:at91_nand_command()

        /* wait until command is processed */
        while (!my_nand->dev_ready(mtd))
                ;

        msleep(1);
}

But of course scanning and mounting now takes a very long time and this
obviously isn't a permanent fix but it might help to locate where the problem
code is.

Does this prove that it's a timing problem? perhaps some race condition?

regards,

Aras Vaichas

Re: JFFS2+NAND problem in 2.6.13-at91

[Aras Vaichas]

Aras Vaichas wrote:
> Aras Vaichas wrote:
> 
>>Hi,
>>
>>I was previously using 2.6.12-rc1, AT91 with JFFS2 on NAND and I had no
>>problems whatsoever with using JFFS2 on NAND.
>>
>>I recently upgraded to 2.6.13 and now JFFS2 on NAND seems a little broken ...

Jian Zhang wrote:

> i turn off debugging information( only MTD_DEBUG_LEVEL3) in nand_read_ecc( ),
> nand_write_ecc( ),nand_read_oob( ),nand_write_oob( ) which contained in
nand_base.c
> seperately. eventually,i found that it works well except turning off debugging
> info in nand_read_oob( ).so i insert  3us delay in this routine.

Thanks for the hint, I've got my NAND working again.

I did a diff between the nand_base.c version shipped with 2.6.13 (v1.147) and
2.6.12-rc1 (v1.138) and noticed that a delay loop had been moved further down
the code, I moved this delay back to where it was in v1.138 and it is now
working again. i assume that there was a probably a good reason to move this
delay in the first place though and I don't wish to break anything else ...

e.g.

--- drivers/mtd/nand/nand_base.c.orig   2005-09-14 13:28:07.000000000 +1000
+++ drivers/mtd/nand/nand_base.c        2005-09-14 13:37:59.000000000 +1000
@@ -1410,6 +1410,18 @@
                this->read_buf(mtd, &buf[i], thislen);
                i += thislen;

+
+               /* Apply delay or wait for ready/busy pin
+                * Do this before the AUTOINCR check, so no problems
+                * arise if a chip which does auto increment
+                * is marked as NOAUTOINCR by the board driver.
+                */
+               if (!this->dev_ready)
+                       udelay (this->chip_delay);
+               else
+                       nand_wait_ready(mtd);
+
+
                /* Read more ? */
                if (i < len) {
                        page++;
@@ -1421,16 +1433,6 @@
                                this->select_chip(mtd, -1);
                                this->select_chip(mtd, chipnr);
                        }
-
-                       /* Apply delay or wait for ready/busy pin
-                        * Do this before the AUTOINCR check, so no problems
-                        * arise if a chip which does auto increment
-                        * is marked as NOAUTOINCR by the board driver.
-                        */
-                       if (!this->dev_ready)
-                               udelay (this->chip_delay);
-                       else
-                               nand_wait_ready(mtd);

                        /* Check, if the chip supports auto page increment
                         * or if we have hit a block boundary.

Tom, did you want to check this? Should I submit a patch?

regards,

Aras Vaichas

Re: JFFS2+NAND problem in 2.6.13-at91

[Artem B. Bityuckiy]

Aras Vaichas wrote:
> Hi,
> 
> I was previously using 2.6.12-rc1, AT91 with JFFS2 on NAND and I had no
> problems whatsoever with using JFFS2 on NAND.
This is the third report saying about the same problem, but the other two
claimed that disabling summary helps, could you confirm this ? Or this is
unrelated?

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.

Re: JFFS2+NAND problem in 2.6.13-at91

[Timofei V. Bondarenko]

Hi.

Aras Vaichas wrote:
> I did a diff between the nand_base.c version shipped with 2.6.13 (v1.147) and
> 2.6.12-rc1 (v1.138) and noticed that a delay loop had been moved further down
> the code, I moved this delay back to where it was in v1.138 and it is now
> working again. i assume that there was a probably a good reason to move this
> delay in the first place though and I don't wish to break anything else ...

The delay_loop calibration logic has been changed in 2.6.13.
It might break udelay() on some architectures.

--
Regards.
	Tim.

Re: JFFS2+NAND problem in 2.6.13-at91

[Aras Vaichas]

Artem B. Bityuckiy wrote:
> Aras Vaichas wrote:
> 
>> Hi,
>>
>> I was previously using 2.6.12-rc1, AT91 with JFFS2 on NAND and I had no
>> problems whatsoever with using JFFS2 on NAND.
> 
> This is the third report saying about the same problem, but the other two
> claimed that disabling summary helps, could you confirm this ? Or this is
> unrelated?
> 

perhaps unrelated, and I can't find *any* summary options in my configuration
... can you be more specific?  Do you mean EBS?


Aras

Re: JFFS2+NAND problem in 2.6.13-at91

[Artem B. Bityuckiy]

On Thu, 2005-09-15 at 11:46 +1000, Aras Vaichas wrote:
> perhaps unrelated, and I can't find *any* summary options in my configuration
> ... can you be more specific?  Do you mean EBS?
> 
Ah, ok, it is now called EBS, yes.

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.