Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: Ralf Baechle <ralf@oss.sgi.com>
To: "Gleb O. Raiko" <raiko@niisi.msk.ru>
Cc: Carsten Langgaard <carstenl@mips.com>,
	Jon Burgess <Jon_Burgess@eur.3com.com>,
	linux-mips@oss.sgi.com
Subject: Re: mips32_flush_cache routine corrupts CP0_STATUS with gcc-2.96
Date: Thu, 11 Jul 2002 13:12:47 +0200	[thread overview]
Message-ID: <20020711131247.A11700@dea.linux-mips.net> (raw)
In-Reply-To: <3D2D58A6.2E5D9695@niisi.msk.ru>; from raiko@niisi.msk.ru on Thu, Jul 11, 2002 at 02:06:30PM +0400

On Thu, Jul 11, 2002 at 02:06:30PM +0400, Gleb O. Raiko wrote:

> > > 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.
> 
> I don't wonder if other IDT CPUs also require this, including those that
> conform MIPS32.
> Basically, requirement of uncached run makes hadrware logic much simpler
> and allows  to save silicon a bit.

The R3000 cache manipulation mechanism is implemented by giving magic
meaning to store instruction while the isolate cache and swap cache bits
are in use.  By their very implementation they're both incompatible with
normal operation of caches and therefore can only be used from uncached
space.

For most part of it the situation for R4000 class CPUs is easier; a cache
instruction either hits or fails.  The only problem I could imagine an
access conflict in the i-cache when both normal instruction fetch and the
cache instruction are going to operate on the i-cache and that sounds like
a less likely problem to me.

Of course not having read the RTL of all CPUs there is a bit of speculation
here :)

  Ralf

  parent reply	other threads:[~2002-07-11 15:57 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-10 14:16 mips32_flush_cache routine corrupts CP0_STATUS with gcc-2.96 Jon Burgess
2002-07-11  0:15 ` Ralf Baechle
2002-07-11  8:48   ` Gleb O. Raiko
2002-07-11  9:18     ` Carsten Langgaard
2002-07-11 10:06       ` Gleb O. Raiko
2002-07-11 10:15         ` Carsten Langgaard
2002-07-11 10:36           ` Gleb O. Raiko
2002-07-11 10:46             ` Carsten Langgaard
2002-07-11 11:12         ` Ralf Baechle [this message]
2002-07-11 17:01           ` Maciej W. Rozycki
2002-07-11 23:02             ` Dominic Sweetman
2002-07-12  0:24               ` Ralf Baechle
2002-07-12 10:37               ` Gleb O. Raiko
2002-07-12 18:40               ` Maciej W. Rozycki
2002-07-11 11:23         ` Maciej W. Rozycki
2002-07-11 13:11           ` Gleb O. Raiko
2002-07-11 13:41             ` Maciej W. Rozycki
2002-07-11 15:27               ` Gleb O. Raiko
2002-07-11 15:59                 ` Maciej W. Rozycki
2002-07-12 10:26                   ` Gleb O. Raiko
2002-07-12 19:02                     ` Maciej W. Rozycki
2002-07-15  9:16                       ` Gleb O. Raiko
2002-07-16  9:00                         ` Maciej W. Rozycki
2002-07-16 10:20                           ` Gleb O. Raiko
2002-07-16 10:36                             ` Maciej W. Rozycki
2002-07-11  7:34 ` Carsten Langgaard
  -- strict thread matches above, loose matches on Subject: below --
2002-07-11  9:49 Jon Burgess
2002-07-11 12:13 ` Ralf Baechle
2002-07-12  9:18 ` Carsten Langgaard
2002-07-11 12:11 Jon Burgess
2002-07-11 16:53 ` Jun Sun
2002-07-11 16:33 Jon Burgess
2002-07-12  9:08 Sedjai, Mohamed
2002-07-12  9:08 ` Sedjai, Mohamed
2002-07-12  9:26 ` Geert Uytterhoeven
2002-07-12  9:40 ` Carsten Langgaard
2002-07-12 15:24 Jon Burgess
2002-07-15  9:42 Jon Burgess
2002-07-22  8:18 Sedjai, Mohamed
2002-07-22  8:18 ` Sedjai, Mohamed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020711131247.A11700@dea.linux-mips.net \
    --to=ralf@oss.sgi.com \
    --cc=Jon_Burgess@eur.3com.com \
    --cc=carstenl@mips.com \
    --cc=linux-mips@oss.sgi.com \
    --cc=raiko@niisi.msk.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox