This is the mail archive of the ecos-patches@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: MPC8260 cache patch


In
"packages/io/flash/current/include/flash.hpackages/io/flash/current/include/
flash.h", there is the following definition:

#define HAL_FLASH_CACHES_OFF(_d_, _i_)          \
    CYG_MACRO_START                             \
    _i_ = 0; /* avoids warning */               \
    HAL_DCACHE_IS_ENABLED(_d_);                 \
    HAL_DCACHE_SYNC();                          \
    HAL_DCACHE_INVALIDATE_ALL();                \
    HAL_DCACHE_DISABLE();                       \
    HAL_ICACHE_INVALIDATE_ALL();                \
    CYG_MACRO_END

This is called in prior to the call to 'flash_dev_query()' (and
'HAL_FLASH_CACHES_ON()' is called afterwards).  When it is called during the
the boot process of RedBoot, RedBoot has written some values to the virtual
vector table that do not get committed to memory by the (current version of)
'HAL_DCACHE_SYNC()'.  Then when 'HAL_DCACHE_INVALIDATE_ALL()' is invoked,
those changes are lost.

You won't get any argument from me about the desire to fully understand a
problem prior to fixing it.  There is a huge difference between fixing a
problem and making it go away.  In my experience, the latter practice is
encountered significantly more often than the former.

OTOH,

As I was thinking about this last night, I started to wonder, why does it
matter if the sync time is doubled?  The effeciency expert in my cringes to
hear me write this (huh?) but, seriously, how often does the cache need to
be sync'd in eCos.  We don't perform MMU-style context switches as Linux
does.  The caches on the '8260 support snooping (in theory -- are there
erratta about this not working?) so in an MP system, the hardware will take
care of coherency issues.  As I said, when I first read your reply saying
that you didn't want do double the time it takes to sync the cache, my first
reaction was one of total agreement.  But, as I thought about it more, I
wonder, is it really an issue for eCos?

--wpd


> -----Original Message-----
> From: Gary Thomas [mailto:gary at mlbassoc dot com]
> Sent: Monday, March 24, 2003 6:42 PM
> To: Patrick Doyle
> Cc: eCos patches
> Subject: RE: MPC8260 cache patch
>
>
> On Mon, 2003-03-24 at 15:12, Patrick Doyle wrote:
> > The particular problem I was chasing down was related to the
> fact that the
> > virtual vector table is in the first 16K.  (Perhaps it could be
> moved for
> > the '8620 platform).  RedBoot initializes pointers in there
> that do not get
> > committed to main memory before the flash initialization
> routine invalidates
> > the cache.
> >
>
> I don't understand.  The FLASH routines don't invalidate the cache, only
> flush them.  Then they turn it off while running the code and then
> restore the cache [turn it back on].  There should be no need to access
> any data within that low 16K while the cache is off.  What data that's
> in the cache and not being flushed is being missed?
>
> This all works fine on all other platforms, including some 603 based
> ones.
>
> > The only other solutions I can think of (now that you mention the major
> > problem of doubling the flush time) are to not place any
> writable data in
> > the first 16K or to choose some other 16K region of cacheable
> memory that
> > could be used to flush the cache.
> >
>
> That's how it works on some other platforms.  The StrongARM has a
> special memory region which is used for only this (it's a sink hole).
>
> Note: I'm not saying that we don't need to fix this.  I just want to
> fully understand it first.
>
> --
> ------------------------------------------------------------
> Gary Thomas                 |
> MLB Associates              |  Consulting for the
> +1 (970) 229-1963           |    Embedded world
> http://www.mlbassoc.com/    |
> email: <gary at mlbassoc dot com>  |
> gpg: http://www.chez-thomas.org/gary/gpg_key.asc
> ------------------------------------------------------------
>


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