Jffs2 write Error

Hi Guys,

I am seeing a frequent error

on an ARM7TDMI system
uClinux version 2.4.20-uc0

Processor: Atmel AT91M40xxx revision 0
Architecture: EB01

physmap flash device: 200000 at 1600000
Found: Atmel AT49BV32XA
number of JEDEC chips: 1

Creating 3 MTD partitions on "Physically mapped flash":
0x00000000-0x00100000 : "part1" 0x00100000-0x00200000 : "part2" 0x00200000-0x00400000 : "rest"

I have added some debugging in write.c
And I get this sort of output
I am copying a large file into the flash system.

ls -l /var/ram/mytest
-rwxr-xr-x 1 0 0 500856 Jan 1 00:00 /var/ram/mtest

cp /var/ram/mytest /var/mtd0/mytest

It all looks to be working just fine...
( PSW is my debug )
PSW Write of 2491 bytes at 0x000ac3b4 attempted. returned 0, retlen 2491 PSW Write of 2514 bytes at 0x000acd70 attempted. returned 0, retlen 2514 PSW Write of 2422 bytes at 0x000ad744 attempted. returned 0, retlen 2422 PSW Write of 2550 bytes at 0x000ae0bc attempted. returned 0, retlen 2550 PSW Write of 2523 bytes at 0x000aeab4 attempted. returned 0, retlen 2523 PSW Write of 2393 bytes at 0x000af490 attempted. returned 0, retlen 2393 PSW Write of 527 bytes at 0x000afdec attempted. returned 0, retlen 527 PSW Write of 2129 bytes at 0x0009000c attempted. returned 0, retlen 2129

Then I get this error

Last[3] is 66, datum is 8000066
Write of 49 bytes at 0x00090860 failed. returned -5, retlen 40 jffs2_write_dirent in garbage_collect_dirent failed: -5 Last[3] is 66, datum is 8000066
Write of 49 bytes at 0x00090894 failed. returned -5, retlen 40 jffs2_write_dirent in garbage_collect_dirent failed: -5

which produces and IOERROR -5 = -EIO

Here is the flash usage..

/> df

Filesystem           1k-blocks      Used Available Use% Mounted on
rootfs                    1999      1999         0 100% /
/dev/ram0                 1999      1999         0 100% /

/dev/ram1 115 8 107 7% /var
/dev/mtdblock0 1024 444 580 43% /var/mtd0

The system was eraseall'd and then mounted before this test.
The first copy of the big file went OK the error was found on the second copy to the same file.

Any clues as to what is happening here ???

regards
Phil Wilshire

SDCS -- System Design & Consulting Services LLC, http://www.sysdcs.com
** Embedded Linux Training **  email me for details  
630 Springhouse Sq., Leesburg VA 20175 t: 703 669 9766 f: 703 669 9768

Hi All,

I have found my original problem.

The
do_write_oneword
routine in
cfi_cmdset_0002.c

was being given values for datum wider than the 16 bits we are allowed to write to the device.
The readback being limited to 16 bits, of course , failed to match

The data was being given to do_write_oneword by gc.c

Here is the error output

Last[3] is 66, datum is 8000066 addr 3028c
Write of 49 bytes at 0x00030264 failed. returned -5, retlen 40 jffs2_write_dirent in garbage_collect_dirent failed: -5

As you can see 8000066 is impossible to write to a 16 bit device.

I put an extra check on the word size in do_write_oneword and the error just went away.

regards
Phil Wilshire

SDCS -- System Design & Consulting Services LLC, http://www.sysdcs.com
** Embedded Linux Training **  email me for details  
630 Springhouse Sq., Leesburg VA 20175 t: 703 669 9766 f: 703 669 9768

Why is gc.c passing values that aren't appropriate?

Quite obvious.

What check did you put in? What do you mean by "the error just went away?" That sounds like a Heisenbug (race) more than a real solution.

Thayne Harbaugh
Linux Networx

Hi Thane,

I do not know . A quick scan of the software looked OK but the values in the actual hardware system were wrong.
It looked like only the call from gc.c produced the bad values.

Yes i guess so. No one caught it on the first posting though.

Here is the code I added. This is a hack/fix for just this system.

The diff is against the latest CVS
============================================================================

@@ -769,7 +769,20 @@
        int ta = 0;
        DECLARE_RETRY_CMD_CNT();
 
+
        adr += chip->start;
+
+        // PSW added sanity checks here...
+       if (cfi_buswidth_is_1()) {
+               if (datum & 0xffffff00) {
+                       datum &= 0x00ff;
+               }
+       }
+       if (cfi_buswidth_is_2()) {
+               if (datum & 0xffff0000) {
+                       datum &= 0xffff;
+               }
+       }
 
        cfi_spin_lock(chip->mutex);
        ret = get_chip(map, chip, adr, FL_WRITING);

==============================================================

Poor wording on my part. The fix was actually correcting the error. The system now works.

I do not claim that this is a real solution. However it does enable the process to work which is what I was trying to do.

If this helps unstick some others who are having the same problem great. I would like to try to find out why gc.c does not
set up the correct values in datum but I have not managed to trace that yet.

regards
Phil Wilshire

SDCS -- System Design & Consulting Services LLC, http://www.sysdcs.com
** Embedded Linux Training **  email me for details  
630 Springhouse Sq., Leesburg VA 20175 t: 703 669 9766 f: 703 669 9768