This is the mail archive of the
ecos-patches@sources.redhat.com
mailing list for the eCos project.
RE: MPC8260 cache patch
- From: Gary Thomas <gary at mlbassoc dot com>
- To: Patrick Doyle <wpd at delcomsys dot com>
- Cc: eCos patches <ecos-patches at sources dot redhat dot com>
- Date: 24 Mar 2003 16:41:41 -0700
- Subject: RE: MPC8260 cache patch
- References: <NFBBJAJICAKJPMMKDAGBIEFKDNAA.wpd@delcomsys.com>
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
------------------------------------------------------------