This is the mail archive of the ecos-discuss@sourceware.org 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 <bartv@ecoscentric.com> 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
                               visi.com            unemployment?


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


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