[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


-----Original Message-----
>From: David Woodhouse [mailto:dwmw2@xxxxxxx.org]
>Sent: Friday, October 05, 2001 6:14 AM
>To: msundius@xxxxxxx.com
>Cc: jffs-dev@xxxxxxx.com
>Subject: Re: JFFS 

>msundius@xxxxxxx.com said:
>>  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 
>>  length. 

>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->write16, and 
map->write32 pass the address of the buffer instead of the data to be
map->write16 (map, (((__u16*)buf)), adr+z);
should be:
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? 

>Looks fine.

>> - 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 
>big-endian systems. 

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.

>> Lastly 
>> - 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 
>>    JFFS1?
>>    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 majordomo@xxxxxxx.com