>>>>> "Gernot" == Gernot Zankl <[EMAIL PROTECTED]> writes:
Gernot> while writing a file in a jffs2 filesystem (by means of
Gernot> open, write, close) my application seems to hang in
Gernot> function write(). After guarding the write access with
Gernot> HA_DISABLE_INTERRUPTS/HAL_RESTORES_INTERRUPTS the write
Gernot> accesses worked properly.
Gernot> After a short inspection of flash.c (in
Gernot> packages/io/flash/current/src) it seems that in my port
Gernot> these guards are already present, placed around the
Gernot> "__anonymizer"-ed flash access functions.
Gernot> Is there a general rule, how to handle mutual IRQs and
Gernot> flash access ? Do I miss something ? Is there a
Gernot> configuration option, I've forgotten to enable ?
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.
1) I do not know too much about jffs2 internals (I leave that to
others) but I suspect that there is enough locking within jffs2
to prevent two threads from accessing the flash h/w concurrently
while performing file I/O.
2) If your board uses a RedBoot residing in flash, as opposed to a
ROMRAM version, then the application may switch to RedBoot and
hence execute from flash for a variety of reasons. The thread
performing file I/O may get preempted and some other thread then
calls printf(), diag_printf(), or anything similar which involves
I/O via the virtual vector mechanism. Or the other thread may hit
a breakpoint, activating the gdb stubs. Or there may be a virtual
vector access to the fis or fconfig data. Or the code may throw
an exception.
3) some other thread may access the flash for some other reason,
either via the flash API or directly. Especially if the
application itself resides in flash.
The anoncvs trunk still uses the V1 API. Basically this does not
address any locking issues at all. Note that the default versions of
the HAL_FLASH_CACHES_...() macros only affect the cache, not
interrupts, so there is nothing to stop the current thread from being
interrupted or preempted. (Actually, manipulating the caches without
considering interrupts is itself rather dodgy). Possibly the platform
HAL for your port defines more advanced macros. There are some
scenarios where you may just be able to get away with this - a ROMRAM
RedBoot, absolutely nothing else using the flash - but it is not a
robust solution.
Anoncvs also has a V2 flash development branch which addresses some of
the problems. In particular it adds mutex locking for accessing flash
devices, so if the only other flash accesses happen via the V2 flash
API then you'll be ok. Again a ROMRAM RedBoot would be a very good
idea.
eCosCentric has done further work on the V2 flash drivers which has
not yet gone into anoncvs. This adds optional interrupt
disabling/reenabling where it is needed, right inside the drivers
themselves, together with support for program burst and for erase
suspend mode to limit the effect on real-time behaviour. There are
various configuration options so you can fine tune the drivers'
behaviour, basically trading off performance for interrupt response
times. With these drivers the application no longer needs to worry
about IRQs during flash accesses on non-SMP systems, it is all done
automatically.
Bart
--
Bart Veer eCos Configuration Architect
http://www.ecoscentric.com/ The eCos and RedBoot experts
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
