Re: [ECOS] HAL macro to deselect an external chip?

[Bart Veer <bartv at ecoscentric dot com>]

>>>>> "Grant" == Grant Edwards <grante@visi.com> writes:

    Grant> I recently had to add support for Numonyx bootblock flash
    Grant> parts to our old copy of the Intel bootblock flash driver.
    Grant> (Which seems to have vanished from CVS?)

    Grant> Of course the part isn't _quite_ compatible. When polling
    Grant> the Numonyx part for status, you have to make sure that the
    Grant> chip is deselected between polls. Intel parts don't require
    Grant> this.

    Grant> As a result, when running with i-cache enabled, the loop
    Grant> that polls the flash chip's status waiting for a program or
    Grant> erase cycle to complete works with Intel parts but not with
    Grant> Numonyx parts.

    Grant> For my particular platform, I know how to force an uncached
    Grant> read of a different external part that's on the same
    Grant> external bus as the Numonix flash chip. Adding that
    Grant> operation to the loops that poll the flash chip status
    Grant> makes the code work with Numonyx parts. However, the code
    Grant> I'm using is platform-specific, and adding it to the flash
    Grant> driver seems wrong.

    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.

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? 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? 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. 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.

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.

Bart
    
-- 
Bart Veer                                   eCos Configuration Architect
eCosCentric Limited    The eCos experts      http://www.ecoscentric.com/
Barnwell House, Barnwell Drive, Cambridge, UK.      Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.

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