2008-10-10 12:15:22 JFFS issue
Richard Aldrich (UNITED KINGDOM)
Message: 63434
We use the MTD flash over SPI on our board (BF537). It's worked fine for months but it has just today had some problems. I noticed the following messages on startup:
Empty flash at 0x000d4ba8 ends at 0x000d4c3c
Empty flash at 0x003c092c ends at 0x003c863c
Then when we try to write to the flash filesystem, i.e. when we FTP a program file onto it, we see the following:
Data CRC 844e5596 != calculated CRC a8b043a6 for node at 0022113c
Node CRC 14041051 != calculated CRC 5eeddfd7 for node at 00221d1c
Node totlen on flash (0x00000802) != totlen from node ref (0x00000884)
Node CRC 00100540 != calculated CRC 6eefbafe for node at 002225a0
Node CRC 08108029 != calculated CRC 0a4a2ede for node at 00222924
Node totlen on flash (0x00000002) != totlen from node ref (0x00000854)
Node CRC 91114280 != calculated CRC c122a5f4 for node at 00223178
Node CRC c0250456 != calculated CRC 813da67a for node at
lNode totlen on flash (0x00000000) != totlen from node ref (0x000003e4)
Node CRC 63249027 != calculated CRC 24a79a16 for node at 00223880
Node CRC 90538044 != calculated CRC b6ac542d for node at 00223ac8
Node totlen on flash (0x00000100) != totlen from node ref (0x00000564)
Node CRC 8c040a02 != calculated CRC 36789cb0 for node at 0022402c
Node CRC 4163010b != calculated CRC 82935c68 for node at 00224294
Node totlen on flash (0x00000429) != totlen from node ref (0x0000067c)
Node CRC 42293080 != calculated CRC 5eeeee15 for node at 00224910
Node CRC 807c1a80 != calculated CRC 65b674e2 for node at 00224e28
Node totlen on flash (0x00000020) != totlen from node ref (0x00000424)
Node CRC 00990098 != calculated CRC dd8a4b08 for node at 0022524c
Node CRC 00080090 != calculated CRC 1ae5544b for node at 002254e0
Node totlen on flash (0x00000404) != totlen from node ref (0x000007a8)
Node CRC 07491204 != calculated CRC 7217dec0 for node at 00225c88
Node CRC 491370a0 != calculated CRC a0e79022 for node at 00226024
Node totlen on flash (0x00000630) != totlen from node ref (0x000006f4)
Node CRC c10080f2 != calculated CRC 77702370 for node at 00226718
I'm interested to know what this means, and is there any way of recovering the device without re-flashing it?
It's obviously a worry because we need to know the file system is safe.
QuoteReplyEditDelete
2008-10-29 11:29:48 Re: JFFS issue
Richard Aldrich (UNITED KINGDOM)
Message: 64354
No one has yet replied to this so I will follow up on it hoping that someone will respond!
I thought the issue may be down to a faulty memory chip on a board i was working on, but I have now seen it on another board after some time. It only appears to happen after a while.
Just recently i have seen to following message while I have been writing to the spi flash filesystem:
Node CRC ffffffff != calculated CRC f09e7845 for node at 002c2444
Node CRC ffffffff != calculated CRC f09e7845 for node at 002c33e4
Node CRC ffffffff != calculated CRC f09e7845 for node at 002c435c
Node CRC ffffffff != calculated CRC f09e7845 for node at 00150360
Node CRC ffffffff != calculated CRC f09e7845 for node at 002c2444
Following this, the program file which I put onto the flash did not run correctly, so I deleted it and put it down again and it worked OK.
However, I need to find what the cause is. I need an expert on JFFS2 who can give some advice.
QuoteReplyEditDelete
2008-10-29 11:44:14 Re: JFFS issue
Mike Frysinger (UNITED STATES)
Message: 64359
please describe the software/hardware that is actually in use as well as the settings ... versions, chip types, etc...
afaik, you shouldnt get any crc messages and ff means the byte was erased. i'm assuming when you programmed the mtd partition, you filled it completely (if the file was smaller than the filesystem, it should have been 0xff padded to the entire size).
if you want a JFFS2 expert, this isnt really the place ... the JFFS2 experts live on the MTD/JFFS mailing lists:
http://sources.redhat.com/jffs2/
http://www.linux-mtd.infradead.org/mail.html
QuoteReplyEditDelete
2008-10-30 12:30:42 Re: JFFS issue
Richard Aldrich (UNITED KINGDOM)
Message: 64449
The kernel is uClinux-dist.R1.1-RC3.
The Memory chip is an 8MB M25P64 device.
I created the jffs2 image originally using: mkfs.jffs2 -p 0x400000 -e 0x400000 -d jffsdir -o jffs2.img
This was done on the target device.
I think i may have found one possible issue looking again at my configuration..
I have the bootloader in the first 1mb, the jffs2 in 1-5 (4 mb) and the kernel is at 5-8 (3 mb). However, on that basis my partition data below is incorrect.
static struct mtd_partition bfin_spi_flash_partitions[] = {
{
.name = "bootloader",
.size = 0x20000,
.offset = 0,
.mask_flags = MTD_CAP_ROM
},{
.name = "file system",
.size = 0x400000,
.offset = 0x100000,
},{
.name = "kernel",
.size = 0x300000,
.offset = 0x400000
}
};
I think Kernel should be offset 0x500000 nor 0x400000, so i will make this change now.
Another question, what does the MTD_CAP_ROM flag do? Does it make it Read only? If so, should I have this flag on the Kernel as well?
QuoteReplyEditDelete
2008-10-30 12:55:46 Re: JFFS issue
Mike Frysinger (UNITED STATES)
Message: 64452
yes, MTD_CAP_ROM makes things read-only. that way you can flag the bootloader as read-only and not worry about userspace accidentally erasing/corrupting it.
some people like to update the kernel from userspace rather than the boot loader ... so that should dictate whether you set MTD_CAP_ROM on the kernel partition
QuoteReplyEditDelete
2008-10-30 13:00:54 Re: JFFS issue
Richard Aldrich (UNITED KINGDOM)
Message: 64453
Is there a doc explain updating the kernel from userspace? I know when i first looked into it (about 18 months ago) it wasn't recommended due to it not being tested fully. However it might be something I need to implement.
QuoteReplyEditDelete
2008-10-30 13:07:43 Re: JFFS issue
Mike Frysinger (UNITED STATES)
Message: 64454
you could do it with a simple script
flash_eraseall /dev/mtdblock#
cat uImage > /dev/mtdblock#
cmp -n $(stat -c%s uImage) uImage /dev/mtdblock#
(i just typed this up without testing ...)