[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
>From: David Woodhouse [mailto:email@example.com]
>Sent: Friday, October 05, 2001 6:14 AM
>Subject: Re: JFFS
>> I ceate the JFFS and I can write and then read back from it.
>> However if I unmount my FS and then mount it back again I see that
>> some of the files have either disappeared or been truncated to 0
>Odd. It sounds like the writes to flash aren't actually working. Can
>you try some tests on the MTD driver directly, writing various
>lengths of data to variously-aligned offsets within the device and
>then checking that they have 'taken'?
I had a similar problem with the MTD drivers in the 2.4.2 kernel for an
Intel StratoFlash 28F640J3A. Everything worked until I did a umount/mount.
I found a problem in the cfi_cmdset_0001.c file that is included with the
2.4.2 kernel. In the function do_write_buffer() the calls to map->write8,
map->write32 pass the address of the buffer instead of the data to be
map->write16 (map, (((__u16*)buf)), adr+z);
map->write16 (map, ((*(__u16*)buf)), adr+z);
(I apologize for the description instead of a patch, but I haven't had time
to figure out that process yet)
once I fixed this problem, my data survived power cycles. Currently I am
mounting a read only ext2 filesystem on this driver, but I can't do that for
the final solution.
>> - Is this an OK configuration?
>> - What is the currently "blessed" version that you would recommend
>> for the kernel version that I'm using?
>The latest code in my CVS tree ought to work fine with most kernel
>versions; if not it should be fairly simple to fix.
I wasn't able to get the current CVS tree to work with my 2.4.2 ARM version
of the kernel. I will admit that I tried it, got some missing symbol
problems that I didn't see an obvious fix for (something like put_user_bad),
then went back and fixed the above problem.
>> - Has any of this been tested on the PowerPC?
>I believe so, although I cannot personally remember running it on any
I am using it on a NanoEngine (ARM) with a 2.4.2 kernel plus patches for the
ARM from Brightstar Engineering.
>> - Is there something stupid that you can see that I'm doing?
>No, but do check the underlying flash driver is working OK. If it
>seems OK with the checks I suggested above, then put extra code into
>flash_safe_writev() to make it read back from the flash after writing
>and compare. If that check doesn't trigger, then do the following:
> - mount an empty flash
> - do the _minimum_ amount of writing to reproduce the problem.
> - unmount
> - take snapshot of flash
> - remount
>Then send me all the debugging output and the snapshot.
>CONFIG_JFFS_FS_VERBOSE=2 should be sufficient.
>> - From reading the JFFS how-to / FAQ, It wasn't clear if one should
>> count on the stability of JFFS2 or should I stick with the
>> This is all for a very high reliability networking switch so I
>> want to make sure its really solid...
>I don't believe there's a great deal to choose between them now, in >terms
of stability. I'm biased though.
I neither one worked for me out of the box. The JFFS v1.0 has similar
problems to the ones you describe, the file system is gone across a power
cycle. With JFFS v2.0 the filesystem is still there, but corrupted somehow.
I am using the flash to store large (~1-2MB
executables) and they are no longer executable. I will try the latest JFFS
filesystems from CVS to see if I can get them to work.
David - a question for you with the MTD drivers. How can I tell when the
filesystem has been completely written to the flash? It would be nice to
know so I can be sure not to power down until it is done.
To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to firstname.lastname@example.org
- Re: JFFS
- From: David Woodhouse <email@example.com>