Re: JFFS2 not persistent?

On Sep 19, 10:52 pm, "cpope" <cep...@xxxxxxxxx> wrote:
"Juergen Beisert" <jbeis...@xxxxxxxxxxxx> wrote in message

news:fcqie9$rnn$03$1@xxxxxxxxxxxxxxxxxxxx



cpope wrote:

"Geronimo W. Christ Esq" <thegreatsupre...@xxxxxxxxxxx> wrote in message
news:1189963084.31816.0@xxxxxxxxxxxxxxxxxxxxxxxxx
Martin Klar wrote:
cpope schrieb:
I'm having a problem with my JFFS2 partition. It mounts okay. I can
copy
files to the mount directory. DF says the space is being used for
the
new
file. But when I power cycle and remount JFFS2 all the changes are
lost. Any
ideas why the files aren't getting committed back to the flash chip?

Depending on your embedded distribution you may need to specify
a "flash save" or similar.

I'd suggest ensuring the JFFS2 partition is mounted with -osync. This
should ensure that all write transactions block when they are committed
to the flash, and are not held off in the cache.

This did seem to help but now I have a very strange problem. If I create
a
file with a period in the name, e.g. reboot.sh, it appears correct but
when I unmount and remount it I get a CRC error and the file is missing
(I
suspect it's still there but the inode is screwed up). However, if I
create a file without a period everything works fine.

So, why would a period in the filename clobber JFFS2?

In your system must be strange things happen. I'm working since years with
JFFS2 filesystems on various targets. No problems like yours yet.
What kind of memory do you use (NOR, NAND)? What kernel revision? How
large
is your flash memory (whole flash and page size)? How does the CPU
accesses
the memory (linear, paged)? Is the CPU cache disabled in the flash area?
What CPU do you are using?

Juergen

I think the period in the filename may be a coincidence. I've since had
files without the period throw the same error.

nor
2.6.10
32MB, 128kbyte
PPC on Virtex4

All accesses are through MTD so I assume it configures the accesses to flash
and disables cache in that are, right?

Thnaks,
Clark

Some flash chips allow for memory block protection on individual block
by block basis, within the same flash chip. I am wondering whether
you have some of the blocks write protected and others not. If that
was the case you may get this kind of strange behavior.

.