This is the mail archive of the ecos-discuss@sources.redhat.com 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: FLASH and disabling interrupts


>>>>> "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


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