"Gleb O. Raiko" wrote:

Ralf Baechle wrote:

quoted

On Wed, Jul 10, 2002 at 03:16:21PM +0100, Jon Burgess wrote:

quoted

This may be caused by the cache routines running from the a cached kseg0, it
looks like it can be fixed by making sure that the are always called via
KSEG1ADDR(fn) which looks like it could be done with a bit of fiddling of the
setup_cache_funcs code. I have included a patch below which starts this, but I
haven't caught all combinations of how the routines are called.

While that could be done it's not a good idea; running code in KSEG1 is
very slow.

Unfortunately, it's required by manuals for some processors. As I know,
IDT HW manuals clearly state cache flush routines must operate from
uncached code and must access uncached data only. Examples are R30x1 CPU
series.

Yes, that's true.
But that code belongs in the R30xx specific cache routines, not in the MIPS32 cache
routines.

Regards,
Gleb.

--
_    _ ____  ___   Carsten Langgaard   Mailto:carstenl@mips.com
|\  /|||___)(___   MIPS Denmark        Direct: +45 4486 5527
| \/ |||    ____)  Lautrupvang 4B      Switch: +45 4486 5555
  TECHNOLOGIES     2750 Ballerup       Fax...: +45 4486 5556
                   Denmark             http://www.mips.com