This is the mail archive of the
ecos-patches@sources.redhat.com
mailing list for the eCos project.
RE: MPC8260 cache patch
- From: "Patrick Doyle" <wpd at delcomsys dot com>
- To: "Robin Farine" <robin dot farine at acn-group dot ch>, "eCos patches ml" <ecos-patches at sources dot redhat dot com>
- Date: Fri, 28 Mar 2003 09:18:22 -0500
- Subject: RE: MPC8260 cache patch
> On Thu, 2003-03-27 at 19:53, Patrick Doyle wrote:
>
> > There is still the underlying problem that, on the 8260,
> 'HAL_DCACHE_SYNC()'
> > does not guarantee that main memory is coherent with the cache. I have
> > thought about changing the region that 'HAL_DCACHE_SYNC()'
> loads to be in
> > flash rather than SDRAM
>
> Sorry to insist, I can't resist. What matters is to have a 16Kb virtual
> region reserved for cache flushing. That you map Flash, SDRAM, IO
> registers isn't relevant, just choose the region with the fastest read
> access time.
>
> All this doesn't sound like a problem at all to me so I guess I'm
> missing something. Someone cares to explain?
In my mind, it is a classic between time vs. (memory) space. If we wanted
to dedicate 16 kBytes just for syncing the cache, we can (out of 1 - 32MB --
what's 16Kbytes? Of course, there is an installed code base that doesn't
know about having to dedicate that region yet). Flash will be slower than
SDRAM, internal RAM will be fasted (but perhaps it is not cacheable -- I'd
have to check that, besides it will be much more precious than slower SDRAM,
so we probably don't want to dedicate 16kBytes to that). Or, we could just
pay the penalty of syncing twice as much space as we need (in which case,
using cacheable internal RAM would probably yield the best results).
On the 8260 port to our specific board, I believe that all of the BAT
registers are in use, so creating an alias to existing memory might not be
possible, but that could be another solution for other boards.
--wpd