This is the mail archive of the 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]
Other format: [Raw text]

Re: HAL macro to deselect an external chip?

On 2009-06-02, Bart Veer <> wrote:

>    Grant> Disabling the i-cache to force external instruction fetches
>    Grant> between polls seems a bit drastic (and isn't possible on
>    Grant> all platforms anyway).
>    Grant> Is there a HAL macro somewhere that can be used to force
>    Grant> deselect of the part at a specified external memory
>    Grant> address?
> That sounds rather too specialized for what is meant to be a
> portability layer.

That's sort of what I thought.

> The first thing I would try is to solve the problem in the
> platform HAL initialization code, where it sets up the memory
> controller registers. Is there anything you can to those
> settings, for example disabling burst accesses to the flash,
> to get the flash chip deselected after every access?

Not that I can see.

> Some processors have bus arbitration registers where you can
> force the cpu to relinquish the bus between accesses, giving
> priority to DMA engines. Is anything like that available?

I'll look again.

> Depending on the performance implications you could either
> change settings permanently or just around flash accesses.
> If none of that is feasible, disabling the icache for flash
> operations is not actually that big a deal. The cpu is going
> to be spinning in a polling loop anyway, and the time taken
> for the operation is independent of how fast the cpu executes
> that loop.

ISR and DSR response is going to be noticeably slowed (tests
indicate about a 25-30% reduction in throughput).  For very
slow operations like block erase, it would also slow other
tasks that run while the flash is being erased.

> There will be some performance penalty because some
> instructions before and after the polling loop will also
> execute with the icache disabled, but unlikely to be worth
> worrying about.

It's not the flash polling loop that I'm concerned about, it's
the other stuff that might be running -- for example an ISR,
DSR, or another thread.  Granted, if something else _does_ run
"during" the polling loop, that will provide the deselection
anyway, but you can't count on that hapenning.

> I don't know about the old strata drivers. If you were using
> the stratav2 driver then you should look at src/strata.c,
> specifically the STRATA_INTSCACHE macros. Platforms can
> override these by e.g. defining a HAL_STRATA_INTSCACHE_BEGIN()
> macro, and that could disable the icache in addition to the
> usual messing with interrupts and the dcache.
> The alternative approach would be to add a
> HAL_STRATA_READ_STATUS() macro, and update the flash driver to
> use that if defined or else fall back to a straightforward
> memory read. Your platform HAL would then define this macro to
> incorporate another memory access, in a way known to work on
> that platform. I am not too keen on that because it means
> convoluting the driver code yet further to work around a bad
> chip design, but it would be acceptable.

I guess we'll just live with a forked flash driver.  We've
already customized it so that it handles the two different
block sizes in the flash.

Grant Edwards                   grante             Yow! Here we are in America
                                  at               ... when do we collect

Before posting, please read the FAQ:
and search the list archive:

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