This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Flash Support in eCos


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]