This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: FLASH and disabling interrupts
- From: Bart Veer <bartv at ecoscentric dot com>
- To: WPD at dtccom dot com
- Cc: ecos-discuss at ecos dot sourceware dot org
- Date: Tue, 8 Mar 2005 16:02:33 +0000 (GMT)
- Subject: Re: [ECOS] FLASH and disabling interrupts
- References: <F18ED44D2778844592DFB732956B66510225C8AA@DTCNT40S4>
>>>>> "wpd" == Doyle, Patrick <WPD@dtccom.com> writes:
wpd> While tracking down a memory corruption problem, I have
wpd> gotten to the point where I see inconsistent state in the
wpd> bowels of the eCos interrupt handling code (dsr_list is NULL,
wpd> but the dsr_count for the clock DSR is non-zero). I see this
wpd> when an interrupt occurs while my code is in the midst of a
wpd> call to 'flash_dev_query()'. Looking at flash.h, I see in the
wpd> comments
wpd> // Both implementations must be called with interrupts disabled.
wpd> Basically, what I think is happening is that, in the midst of
wpd> syncing and invalidating the cache, I get an interrupt, which
wpd> accesses 'dsr_list' in the cache right before we shut off the
wpd> cache. This must be a recognized issue, or else Gary wouldn't
wpd> have put that comment in the code.
wpd> So, here are my questions...
wpd> Who is responsible for making sure that interrupts are
wpd> disabled? Should 'flash_dev_query()' be patched to ensure
wpd> that interrupts are disabled? 'flash_dev_query()' is called
wpd> from within my flash driver. Should my flash driver disable
wpd> interrupts before calling 'flash_dev_query()'? My flash
wpd> driver is called by 'flash_init()'. Should 'flash_init()'
wpd> disable interrupts before calling into my driver? I'm the one
wpd> who calls 'flash_init()' from my application. Should I
wpd> disable interrupts in my application before calling
wpd> 'flash_init()'? I'll stop here :-)
Currently it is the responsibility of the application to do the right
thing, where "the right thing" depends somewhat on how the system is
set up. There has been discussion of this in the V2 flash API context,
see e.g.
http://ecos.sourceware.org/ml/ecos-discuss/2004-08/msg00297.html and
follow-ups.
flash_init() itself should not manipulate interrupts or the cache.
With some flash drivers, e.g. the synthetic target and dataflash ones,
there is no need to worry about the cache or interrupts at all. Hence
it must be either the driver or the application which takes care of
things. Current drivers do not. I have written a V2 AMD flash driver
which handles all the interrupt and cache issues inside the driver, so
application code never needs to worry about this sort of thing. Said
driver is not currently available in anoncvs.
wpd> In the short term, I'm going to disable interrupts in my
wpd> application around the call to 'flash_init()'. In the long
wpd> term, it would be nice if there were at least a comment
wpd> somewhere near 'flash_init()' that indicated that interrupts
wpd> should be disabled when calling it.
The entire flash subsystem has been pretty much rewritten. The work is
happening on a separate branch.
wpd> Perhaps a related question would be, do I need to call
wpd> 'flash_init()'? I only call it because I copied code from
wpd> elsewhere that calls it. But, all I want to do is to make
wpd> some CYGACC_CALL_IF_FLASH_FIS_OP calls to get the base
wpd> address and length of some data stored in files in the FIS. I
wpd> could try things once without the call to 'flash_init()', but
wpd> after the time I've spent tracking down this particular
wpd> Heisenbug (in which minor changes to the code resulted in
wpd> making the problem disappear and reappear, most likely
wpd> related to where things lined up in the cache relative to the
wpd> timing of the interrupt while flushing the cache), I am
wpd> loathe to just make a change, see that things work, and
wpd> decide I've fixed this.
AFAIK it shouldn't be necessary to call flash_init() if you only
perform FIS_OP operations, although I don't know all the details of
the FIS implemention. The FIS code lives in RedBoot and there has
already been a call inside RedBoot to perform the necessary
initialization. However if you perform an FIS operation which involves
modifying the flash contents then that should usually be protected by
disabling interrupts.
Bart
--
Bart Veer eCos Configuration Architect
http://www.ecoscentric.com/ The eCos and RedBoot experts
>>>>> Visit us in booth 2539 at Embedded Systems Conference 2005 <<<<<
>>>>> March 8 - 10, San Francisco http://www.embedded.com/esc/sf <<<<<
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss