This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: HAL macro to deselect an external chip?
- From: Bart Veer <bartv at ecoscentric dot com>
- To: Grant Edwards <grante at visi dot com>
- Cc: ecos-discuss at sources dot redhat dot com
- Date: Tue, 02 Jun 2009 11:24:39 +0100
- Subject: Re: [ECOS] HAL macro to deselect an external chip?
- References: <h01el6$6ph$1@ger.gmane.org>
>>>>> "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