This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Flash Support in eCos
- To: <ecos-discuss at sources dot redhat dot com>
- Subject: [ECOS] Flash Support in eCos
- From: "RAY Electronic-Design GmbH" <info at raygmbh dot de>
- Date: Wed, 8 Aug 2001 01:33:32 +0100
- Reply-To: "RAY Electronic-Design GmbH" <info at raygmbh dot de>
As i wanted to port the flash support in eCos i came to the following:
In most platforms for which this is already implemented (e.g.: EDB7XXX)
there is one function per c-file specially compiled to get it's length and
copy it to ram before calling it, because if the function is executing out
of the flash, it will not work.
But for example in platform EDB7XXX specific 'flash_query' the cache is
treated:
__
HAL_DCACHE_IS_ENABLED(cache_on);
if (cache_on) {
HAL_DCACHE_SYNC();
HAL_DCACHE_DISABLE();
}
__
Which is necessary to have cycle-exact control of the flash.
But in my platform the MACRO's used to control the cache call functions in
the ROM, which fails at that point, because these function calls are not
position independent (ARM7TDMI).
Wouldn't it be better to leave the cache-handling to the common calling
functions in eCos instead of the RAM-cloned ones, so that the ram-cloned
functions do nothing but accessing the flash ?
For now i am deciding what to do.
I could'nt find the switch used for compiling these ram-cloned functions in
my doc's:
-fno-function-sections
Also did it select the strongarm cpu for EDB7XXX.
Is the EDB7XXX a strongarm or is this just a hack, to avoid the problems i
discovered ?
Raymund Hofmann
RAY Electronic-Design GmbH
Lagerstrasse 49
64807 Dieburg, Germany
Tel ++49 6071-986000
Fax ++49 6071-9860098