[ECOS] JFFS2 Access and interrupts

Andrew Lunn andrew@lunn.ch
Fri Sep 8 16:58:00 GMT 2006

On Fri, Sep 08, 2006 at 11:59:48AM +0200, Gernot Zankl wrote:
> Hi all !
> > A basic rule of working with flash is that if any code is erasing or
> > programming part of the flash then no other code can access it. Some
> > flash chips relax that restriction somewhat by providing several
> > banks, but at best that is only a partial solution. Flash accesses can
> > come from a variety of sources.
> I'm using ROMRAM versin of redboot and the applications runs in RAM,
> too.
> Are there any calls to the ROM version of the redboot during the
> execution
> of a "normal" application, which would cause reading access to the flash
> ?

There shoudn't be. But it is worth checking the interrupt vectors and
VV are pointing to RAM addresses not ROM addresses. It could be the
ROMRAM startup code is not quite right and its still using ROM
addresses. Such a system might run, but experiance problems with
interrupts during flash handling.

> I want to give the v2 version a try. As far as i've seen, there exists a
> flas_v2 branch in the CVS.
> Are the modules devs/flash, io/flash and fs/jffs2 the only ones, I've to
> upgrade ?

If your problem is in Redboot, you might also need the redboot
directory from the branch.

> I built a test application (heavily based on one of the jffs2 tests),
> where
> cyclically files (with size f) are allocated, filed with rand()-values, 
> crc-checked and finally erased. 
> Starting with a fresh partition (all filled with 0xff) of size S, 
> it seems that after a number of iterations i, jffs2 produces a lot of
> warnings
> (see below), where always approx. i * f = S.
> The test continues, but most of the time hangs some iterations later.

It might be interesting to run this on the synthetic target. It has no
interrupts as such, so you can test if this is a jffs2 problem, not a
flash problem.


Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

More information about the Ecos-discuss mailing list