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


On Sat, 2003-03-29 at 16:14, Patrick Doyle wrote:
> OK, now I am confused.
> 
> I just looked at changing the 'DCACHE_SYNC()' macro in the five variants
> currently in the powerpc source tree (mpc5xx, mpc8260, mpc8xx, ppc40x,
> ppc60x).  I was planning on defining it in
> "powerpc/arch/current/include/hal_cache.h" (with the usual trick of allowing
> the variants to redefine it) because of my bias against cutting and pasting
> code from one variant to another.  I figured that, at least the mpc8260 and
> the ppc60x would benefit from this.  (Please chime in here if you have any
> objections to this strategy, but it's not really what I wanted to get to
> here).  What I learned was that the mpc5xx variant has no cache and I have
> no idea what the SPR's that are manipulated in the mpc8xx variant do (so I
> would leave those to override the arch definition in "hal_cache.h").  But,
> what really caught my eye was the ppc40x variant, which uses the "dcbf"
> instruction to flush (and invalidate) the cache line corresponding to the
> given address.
> 

I think we should leave the cache functions as it - in the variant - 
since the behaviour (and even the instructions used) are very processor
specific.

> So, here is my question:
> 
> Why don't we always use the "dcbf" instruction (in "hal_cache.h" -- and let
> the mpc5xx variant override it for efficiency and, perhaps, let the mpc8xx
> variant override because of whatever it needs to do with the SPRs, or
> perhaps not -- but somebody else would have to test it for me)?  The "dcbf"
> instruction is defined by the powerpc architecture, and, as I understand it,
> will always do the "right thing" regardless of how a particular variant
> implements its cache (i.e. split data & instruction, number of ways, etc...)
> Is the "dcbf" instruction not used because it invalidates the cache as well
> as flushing it?  Was it an oversight?  Would you like me to update the
> architecture and the three (or even four) variant HALs as I have described
> here instead of just doubling the number of lines in the 8260 and 60x
> variants?
> 

I don't think that the code using 'dcbf' works :-(  The way I read the
documentation, it only flushes lines which match the given address.  
Since the code enumerates address [0..DCACHE_SIZE-1], this only insures
that memory is coherent with those addresses - not any others that might
be in the cache (whose address falls outside that range).

I'm pretty sure that the only way to do this properly is like it is done
on the PPC60x and even then, I think we need the 2x fix in there.

In other words, the versions that use 'dcbf' for the SYNC() function are
simply wrong.  We probably never noticed because the only 40x platform 
that was ever exercised much was a 403 and the IIRC either it had no 
caches or they didn't work (maybe this was why).

> I'll be back in OMAP (i.e. innovator) land on Monday, so I won't be able to
> play with this until Tuesday at the earliest, but please let me know what
> you think.
> 
> 
> On a related but different topic, I'm still not to sure about the disable
> vs. disable and invalidate point.  It still sounds familiar to me, but I
> don't see anything like that in the OMAP documenation (Jonathan's point
> about it being one of Jesper's ports has me really worried here).  Perhaps
> it was back when I was reading the MIPS book...
> 

Technically, this should not matter.  The only time this would make any
difference would be if the FLASH functions modified data that was already
within the data cache.  If the lines were left valid and then the cache
disabled, when the cache was re-enabled, the lines in the cache could
override the changes in memory, leading to an inconsistent state.  So,
for safety's sake, we should leave the invalidate calls in there.  BTW,
as far as I can see the only time this could cause a problem would be
on the "inquire" function - the one that computes the size and shape of
the FLASH.  If that data were already in the cache, then things could
go awry.  The only other routines only write to the FLASH and should not
be touching memory anyway.


> 
> > -----Original Message-----
> > From: Gary Thomas [mailto:gary at mlbassoc dot com]
> > Sent: Friday, March 28, 2003 11:34 AM
> > To: Patrick Doyle
> > Cc: Jonathan Larmour; eCos patches
> > Subject: RE: MPC8260 cache patch
> >
> >
> > On Fri, 2003-03-28 at 09:29, Patrick Doyle wrote:
> > > Yes, I also think that it's safe in this case.
> > > >
> > > > I vaguely recall something about some architecture or variant (not
> > > > powerpc) which had caches where, if you "just" disabled them, it would
> > > > still use the cache lines that were still valid. So the invalidate was
> > > > needed too. Perhaps Nick might remember the specifics? Although I also
> > > > vaguely recall it was one of Jesper's ports.
> > > Here's where you are making me wonder if it might be the OMAP
> > port.  Gee,
> > > you would think I could remember that sort of stuff from one day to the
> > > next.  Sigh... I'll double check that, especially since, now that you
> > > mention it, it sounds vaguely familiar to me as well.
> > >
> >
> > I doubt that it would be any ARM or PowerPC port.  It might have been
> > SH though.
> >
> > > I guess I've got some cache problems of my own. :-)  Gary, we
> > once discussed
> > > ugrading to the new 2.0 brains, have you heard anything about
> > them lately?
> > > I've got two newer model Patricks in development right now, but they are
> > > only 2.5 years and 5 months old, so I think it will be while
> > before I can
> > > depend on them for support.
> > >
> >
> > Even then, don't count on it!  My replacements are now 21,17 and 14 and
> > I doubt if I'll ever be able to count on them to help my ailing gray
> > cells!
> >
> > --
> > ------------------------------------------------------------
> > 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
> > ------------------------------------------------------------
> >
-- 
------------------------------------------------------------
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]