Help: Error on mounting JFFS2

Help: Error on mounting JFFS2

[Shawn Jin]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 2617 bytes --]

Hi,

I have some error when mounting a JFFS2 root
filesystem. My flash is Am29PL320D on a MPC8245 board,
16MB at two banks (0xFF800000, and 0xFF000000).
CONFIG_MTD_CFI_B8 and CONFIG_MTD_CFI_I2 are set. The
root fs image has benn programmed to bank 1 which
starts at 0xFF000000. The error message is shown
below.

MTD do_write_oneword(): WRITE 0x00051b40(0x000000f0)
MTD do_write_oneword(): Check 0x6f6c65ff 0x1985e002
MTD do_write_oneword(): Check 0x6f6c65ff 0x1985e002
MTD do_write_oneword(): Wacky!  Unable to decode
failure status
Possible buggy device - try increasing retry_cmd_max
from 5
MTD do_write_oneword(): 0x00051b40(0x00000000):
0x6f6c65ff 0x1985c002 0x6f6c65ff
 0x1985e002
Write error in obliterating obsoleted node at
0x00051b44: -5
MTD do_erase_oneblock(): ERASE 0x00680000
Chip not ready after erase suspended: status = 0x1032
error -5 reading node at 0x0004faac in
get_inode_nodes()
jffs2_get_inode_nodes() for ino 2 returned -5
Returned error for crccheck of ino #2. Expect
badness...
Chip not ready after erase suspended: status = 0x1032
error -5 reading node at 0x000574b0 in
get_inode_nodes()
jffs2_get_inode_nodes() for ino 4 returned -5
Returned error for crccheck of ino #4. Expect
badness...

The following debugging information about the flash
chip may be helpful.

ep8245:Probing 0x00800000 at 0xff000000
Number of erase regions: 4
Primary Vendor Command Set: 0002 (AMD/Fujitsu
Standard)
Primary Algorithm Table at 0040
Alternative Vendor Command Set: 0000 (None)
No Alternate Algorithm Table
Vcc Minimum:  2.7 V
Vcc Maximum:  3.6 V
No Vpp line
Typical byte/word write timeout: 16 µs
Maximum byte/word write timeout: 512 µs
Full buffer write not supported
Typical block erase timeout: 1024 ms
Maximum block erase timeout: 65536 ms
Chip erase not supported
Device size: 0x400000 bytes (4 MiB)
Flash Device Interface description: 0x0005
  - Unknown
Max. bytes in buffer write: 0x1
Number of Erase Block Regions: 4
  Erase Region #0: BlockSize 0x8000 bytes, 1 blocks
  Erase Region #1: BlockSize 0x4000 bytes, 2 blocks
  Erase Region #2: BlockSize 0x30000 bytes, 1 blocks
  Erase Region #3: BlockSize 0x40000 bytes, 15 blocks
EP8245 Flash Bank #1: Found 2 x32 devices at 0x0 in
64-bit mode
 Amd/Fujitsu Extended Query Table at 0x0040
EP8245 Flash Bank #1: Swapping erase regions for
broken CFI table.
number of CFI chips: 1
Using word write method
cfi_cmdset_0002: Disabling fast programming due to
code brokenness.

Any help is appreciated!

-Shawn.

__________________________________
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html

Re: Help: Error on mounting JFFS2

[Florian Schirmer]

Hi,

> cfi_cmdset_0002: Disabling fast programming due to
> code brokenness.

What MTD version you are using? I recommend to get the latest code from CVS, 
since there was another bug in the cmdset2. You should in fact get two 
"Disabled X due to bugs" messages.

Regards,
   Florian

Re: Help: Error on mounting JFFS2

[Shawn Jin]

> 
> > cfi_cmdset_0002: Disabling fast programming due to
> > code brokenness.
> 
> What MTD version you are using? I recommend to get the latest code from
> CVS, 
> since there was another bug in the cmdset2. You should in fact get two 
> "Disabled X due to bugs" messages.

The version of cfi_cmdset_0002.c is 1.94, which is almost up-to-date
without David Vrabel's patches. I have some questions on the debugging
messages shown below.

VFS: Mounted root (jffs2 filesystem).
Freeing unused kernel memory: 84k init
init started:  BusyBox v1.00-pre7 (2004.02.18-01:28+0000) multi-call binary
Config lookback interface...
Config eth0...
Add default route...
mount proc...
No more tasks for init -- sleeping forever.
e100: eth0 NIC Link is Up 100 Mbps Full duplex
------------------------------------------------------

Q: The above messages show that the root filesystem seemed to be mounted
and the first script /etc/rc.sh was executed. Why is MTD tying to erase
0x00780000? What is MTD trying to do here? Filesystem cleanup?

My flash is Am29PL320D, and the configuration is 64-bit bus width and 2
chip interleaved. Erase block size is 512KiB. 0xFF000000-0xFF800000 is the
1st mtd device.

MTD do_erase_oneblock(): ERASE 0x00780000
MTD do_erase_oneblock(): Check 0xffffffff 0xffffffff
MTD do_erase_oneblock(): Check 0xffffffff 0xffffffff
MTD do_erase_oneblock(): ERASE 0x007e0000
MTD do_erase_oneblock(): Check 0xffffffff 0xffffffff
MTD do_erase_oneblock(): Check 0xffffffff 0xffffffff
MTD do_erase_oneblock(): ERASE 0x007e8000
MTD do_erase_oneblock(): Check 0xffffffff 0xffffffff
MTD do_erase_oneblock(): Check 0xffffffff 0xffffffff
MTD do_erase_oneblock(): ERASE 0x007f0000
MTD do_erase_oneblock(): Check 0xffffffff 0xffffffff
MTD do_erase_oneblock(): Check 0xffffffff 0xffffffff
------------------------------------------------------

Q: What does the following WRITE mean? Why does it try to write 0xc03bdd84
to 0x00780000?

It seems to me that WRITE command failed somehow. It might be due to the
implemention of my own _write64(). But if the problem is in the _write64(),
I don't think that the chip even can be probed. The chips are found
correctly. Then what caused this failure?

MTD do_write_oneword(): WRITE 0x00780000(0xc03bdd84)
MTD do_write_oneword(): Check 0xffffffff 0xffffffff
MTD do_write_oneword(): Check 0xffffffff 0xffffffff
MTD do_write_oneword(): WRITE 0x00780000(0x000000f0)
MTD do_write_oneword(): Check 0xffffffff 0xffffffff
MTD do_write_oneword(): Check 0xffffffff 0xffffffff
MTD do_write_oneword(): WRITE 0x00780000(0x000000f0)
MTD do_write_oneword(): Check 0xffffffff 0xffffffff
MTD do_write_oneword(): Check 0xffffffff 0xffffffff
MTD do_write_oneword(): WRITE 0x00780000(0x000000f0)
MTD do_write_oneword(): Check 0xffffffff 0xffffffff
MTD do_write_oneword(): Check 0xffffffff 0xffffffff
MTD do_write_oneword(): WRITE 0x00780000(0x000000f0)
MTD do_write_oneword(): Check 0xffffffff 0xffffffff
MTD do_write_oneword(): Check 0xffffffff 0xffffffff
MTD do_write_oneword(): WRITE 0x00780000(0x000000f0)
MTD do_write_oneword(): Check 0xffffffff 0xffffffff
MTD do_write_oneword(): Check 0xffffffff 0xffffffff
MTD do_write_oneword(): Wacky!  Unable to decode failure status
Possible buggy device - try increasing retry_cmd_max from 5
MTD do_write_oneword(): 0x00780000(0x00000000): 0x19852003 0x0000000c
0xffffffff
 0xffffffff
Write clean marker to block at 0x00780000 failed: -5

This issue really drives me crazy. Any hints are appreciated. Thanks a lot.

Regards,
-Shawn.

__________________________________
Do you Yahoo!?
Yahoo! Mail SpamGuard - Read only the mail you want.
http://antispam.yahoo.com/tools

Re: Help: Error on mounting JFFS2

[Shawn Jin]

> > cfi_cmdset_0002: Disabling fast programming due to
> > code brokenness.
> 
> What MTD version you are using? I recommend to get the latest code from
> CVS, 
> since there was another bug in the cmdset2. You should in fact get two 
> "Disabled X due to bugs" messages.
 
When the latest code from CVS (i.e. with David Vrabel's patches) was used,
the root filesystem finally got mounted with type JFFS2.

However I observed some strange behaviors. What I tried is to create some
new files in the device. Here is the screenshot.

# ls
bin   dev   etc   lib   proc  sbin  tmp   usr   var
--> original root filesystem

# cd tmp
# ls
# df
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/mtdblock1            8192      2096      6096  26% /
--> show the device's usage

# cp /bin/busybox busybox
Node totlen on flash (0xffffffff) != totlen from node ref (0x00000044)
Node CRC ffffffff != calculated CRC f09e7845 for node at 000f69dc
# ls -l
-rwxr-xr-x    1 0        0          785136 Jan  1 00:03 busybox
# ls -l /bin/busybox
-rwxr-xr-x    1 0        0          785136 Feb 18  2004 /bin/busybox
# df
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/mtdblock1            8192      2528      5664  31% /
--> copy a file 'busybox' to 'tmp' directory. Here come some error
messages.

# cp busybox bb1
Node totlen on flash (0xffffffff) != totlen from node ref (0x00000044)
Node totlen on flash (0xffffffff) != totlen from node ref (0x0000000c)
Node CRC ffffffff != calculated CRC f09e7845 for node at 000f704c
Node CRC ffffffff != calculated CRC f09e7845 for node at 000f704c
cp: Read error: Input/output error
--> Again error messages. And also the size of 'bb1' is less than the size
of 'busybox'.

# cp bb1 bb2
Node totlen on flash (0xffffffff) != totlen from node ref (0x00000044)
Node totlen on flash (0xffffffff) != totlen from node ref (0x0000000c)
# cp bb2 bb3
Node totlen on flash (0xffffffff) != totlen from node ref (0x00000044)
Node totlen on flash (0xffffffff) != totlen from node ref (0x0000000c)
# df -k
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/mtdblock1            8192      3820      4372  47% /
# ls -l
-rwxr-xr-x    1 0        0          782336 Jan  1 00:04 bb1
-rwxr-xr-x    1 0        0          782336 Jan  1 00:04 bb2
-rwxr-xr-x    1 0        0          782336 Jan  1 00:04 bb3
-rwxr-xr-x    1 0        0          785136 Jan  1 00:03 busybox
--> The sizes of 'bb1', 'bb2', and 'bb3' are the same but all are less than
the size of 'busybox'.

--> After the sytem is rebooted, all created files are gone. Why cannot
they be written to flash?

Question: Is this problem related to JFFS2? Or just simply to mkfs.jffs2? I
used the latest util from CVS to make a JFFS2 filesystem image with '-e
0x80000' specified, no padding.

Regards,
-Shawn.

__________________________________
Do you Yahoo!?
Yahoo! Mail SpamGuard - Read only the mail you want.
http://antispam.yahoo.com/tools

Re: Help: Error on mounting JFFS2

[David Vrabel]

>>> cfi_cmdset_0002: Disabling fast programming due to code 
>>> brokenness.
>> 
>> 
>> What MTD version you are using? I recommend to get the latest code
>> from CVS, since there was another bug in the cmdset2. You should
>> in fact get two "Disabled X due to bugs" messages.
> 
> 
> The version of cfi_cmdset_0002.c is 1.94, which is almost up-to-date 
> without David Vrabel's patches. I have some questions on the 
> debugging messages shown below. [...] MTD do_write_oneword(): WRITE 
> 0x00780000(0xc03bdd84) MTD do_write_oneword(): Check 0xffffffff 
> 0xffffffff MTD do_write_oneword(): Check 0xffffffff 0xffffffff

This looks like you're not write-enabling the flash device or the
sectors are write protected so nothing ever gets written.  I'm a bit
surprised the write didn't fail with an error though.  The datasheet I
have here for the AM29LV128M doesn't say what the chip is supposed to do
when you try to erase/program protected sectors.

The reason the latest CVS appears to work better is because it no longer
checks the flash to see if the data actually got written -- it assumes
the status reported by the chip is correct.

David Vrabel
-- 
David Vrabel, Design Engineer

Arcom, Clifton Road           Tel: +44 (0)1223 411200 ext. 3233
Cambridge CB1 7EA, UK         Web: http://www.arcom.com/

Re: Help: Error on mounting JFFS2

[Shawn Jin]

> > The version of cfi_cmdset_0002.c is 1.94, which is almost up-to-date
> > without David Vrabel's patches. I have some questions on the debugging
> > messages shown below.
> > [...]
> > MTD do_write_oneword(): WRITE 0x00780000(0xc03bdd84)
> > MTD do_write_oneword(): Check 0xffffffff 0xffffffff
> > MTD do_write_oneword(): Check 0xffffffff 0xffffffff
> 
> This looks like you're not write-enabling the flash device or the 
> sectors are write protected so nothing ever gets written.  I'm a bit 
> surprised the write didn't fail with an error though.  The datasheet I 
> have here for the AM29LV128M doesn't say what the chip is supposed to do 
> when you try to erase/program protected sectors.

Thank you very much for your hints.

Before I forgot to disable write protection (WP#) and the mtd driver even
couldn't probe the chip. After WP# is disabled, which is controled by a bit
of an internal register of the board, the flash Am29PL320D
(http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24075.pdf)
is found, which, I think, verifies that the flash device is write enabled.
Right?

The device is shipped with all sectors unprotected and I'v verified this by
manually issuing the Sector-Protect-Verify command sequence through a BDI.

This device is obviously not writable on linux. But why? Each factor I've
found with the help from this mailing list indicates contrarily that the
device be writable. What else will cause a device unwritable?
 
> The reason the latest CVS appears to work better is because it no longer 
> checks the flash to see if the data actually got written -- it assumes 
> the status reported by the chip is correct.

This explains why the files are gone after the system reboot. Thanks.

-Shawn.

__________________________________
Do you Yahoo!?
Yahoo! Mail SpamGuard - Read only the mail you want.
http://antispam.yahoo.com/tools