Subject: R4600 V1.7 errata

From: Ralf Baechle <[email-masked]>
Date: Sun, 1 Feb 2004 05:52:58 +0100

On Sat, Jan 31, 2004 at 03:10:27PM +0100, Jorik Jonker wrote:

> 
> On Sat, Jan 31, 2004 at 04:04:35AM +0100, Ralf Baechle wrote:
> > Over the past days a few fixes went into CVS, the last only a few minutes
> > ago.  Can you retry and let me know?
> 
> Well, it a little 'better'. It now hangs while configurating the network
> device, while in earlier versions the freeze appeared while calibrating the
> delay loop, or mounting the root fs.
> Is there something else I could try?
> Until I know what's going on, I am going to look for a kernel with proper
> VINO support which is 'old' enough to run without the freeze..

Seems I lost the R4600 V1.7 errata documents I used to have so all
information that is left to me is what's documented in the Linux code.
I've removed all the mentioned instructions and the kernel which
otherwise is running fine on R5000 systems or R4600 V2.0 keeps crashing.
I suspect I'm becoming victim of some of the other of the chip's errata;
it has at least 18 ...

Anybody still got errata information for the R4600 V1.7 around?

  Ralf

---

From: Ralf Baechle <[email-masked]>
Date: Tue, 3 Feb 2004 12:39:28 +0100

> Anybody still got errata information for the R4600 V1.7 around?

Jorik was so friendly to track down the patch in CVS that broke the R4600
V1.7 back in time.  With that as a start it was fairly easy to isolate the
problem further.  Seems we became victim of some erratum that affects the
operation of indexed I-cache flushes only.  Last night I commited a patch
that provides an optimized solution for the problem.

Still, knowing the errata sheet of this processor has at least 18 items
on it I'd not place bets on it being totally reliable.  Therefore I'm
still interested, just in case somebody happens to run over a dusty errata
sheet somewhere :-)

  Ralf

---

From: "Dominik 'Rathann' Mierzejewski" <[email-masked]>
Date: Tue, 3 Feb 2004 12:42:53 +0100

On Tue, Feb 03, 2004 at 12:39:28PM +0100, Ralf Baechle wrote:
[...] 
> that provides an optimized solution for the problem.

I assume it's safe to test it now? I'll build it for my R4600 V2.0 and
report in a while. Stay tuned.

-- 
Dominik 'Rathann' Mierzejewski <[email-masked]>                                                 
Interdisciplinary Centre for Mathematical and Computational Modelling                               
Warsaw University  |  http://www.icm.edu.pl  |  tel. +48 (22) 5540810

---

From: Ralf Baechle <[email-masked]>
Date: Tue, 3 Feb 2004 12:52:36 +0100

> report in a while. Stay tuned.

2.0 requires different workarounds which are already in place and functional
since quite some time.  We still lacking a fix for one important erratum of
the 2.0 but it seems pretty stable without.

Chip revs later than 2.0 do identify as 2.0 so if you're lucky your processor
is actually a post-2.0 and working just fine ...

  Ralf

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Tue, 3 Feb 2004 16:43:19 +0100 (CET)

> the 2.0 but it seems pretty stable without.

 Well, I can actually see two problems: #4 that is fairly easy to handle
and #7 which is painful and which is unfortunately present with the R4700
as well.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: [email-masked], PGP key available        +

---

From: Ralf Baechle <[email-masked]>
Date: Tue, 3 Feb 2004 17:12:02 +0100

> and #7 which is painful and which is unfortunately present with the R4700

If #7 would only affect the R4700 the world would peachy ...  To my
knowledge the dusty box here in a corner is the only R4700 that ever ran
Linux ...

Under a different bug number this bug also affects the R4600 V1.x; it's
fixed in post-2.0 R4600 (which all identify as 2.0) and post-1.1 R4700.
Since a workaround may be a bit performance sensitive I think I'll try if
it can be probed for reliably.

  Ralf

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Tue, 3 Feb 2004 17:20:18 +0100 (CET)

> it can be probed for reliably.

 The conditions appear clear, so they may be quite easy to reproduce for
the erratum to trigger.  I guess you may take the optimization hint from
the document into account as well.

---

From: "Dominik 'Rathann' Mierzejewski" <[email-masked]>
Date: Wed, 4 Feb 2004 16:48:02 +0100

> report in a while. Stay tuned.

Works now. Thanks, guys.

---

From: Pete Popov <[email-masked]>
Date: 04 Feb 2004 07:59:49 -0800

> > report in a while. Stay tuned.

The latest cache updates break the Au1x kernel. I don't know yet exactly
what the problem is, but I tested with a snapshot before and after the
updates.

Pete

---

From: Ralf Baechle <[email-masked]>
Date: Wed, 4 Feb 2004 21:04:23 +0100

> what the problem is, but I tested with a snapshot before and after the

The cache updates should specifically only affects systems that explicitly
enable the cache workaround in <asm/war.h>; for any other the compiler
should totally eleminate the workaround from the binary.

Therefore my first guess would be pg-r4k.c.

  Ralf