Subject: Linux on a 100MHz r4000 indy?

From: Greg Johnson <[email-masked]>
Date: Mon, 16 Jul 2001 16:37:12 -0400

I have tried recently to get Debian installed on a 100MHz r4000 indy.
I got it to install and boot the base system, but when I upgrade to the
more recent libc6, I get Bus Errors when I run things like "ls".  I
understand that this is related to the MIPS_ATOMIC/ll/sc stuff that has
been discussed here lately.  So, I tried the fast-sysmips patch.  This
changed the Bus Errors to Segfaults.  

I also have another indy with a 175MHz r4400.  This machine seems to
work fine even without the fast-sysmips patch.  

So what's the deal?  Are the r4000 and r4400 that different?  It's my
understanding that both the r4000 and the r4400 support the ll/sc
instructions.  Should I expect bad/broken hardware on the r4000 machine?  

Thanks,

Greg

---

From: Ralf Baechle <[email-masked]>
Date: Tue, 17 Jul 2001 03:20:55 +0200

> work fine even without the fast-sysmips patch.  

This could be explained if you have different libraries, the one compiled for
MIPS II, the other one only for MIPS I on these two systems.  Sure you're
running the very same binaries?

> So what's the deal?  Are the r4000 and r4400 that different?

They're very similar, almost the same silicon.

> It's my understanding that both the r4000 and the r4400 support the ll/sc
> instructions.

> Should I expect bad/broken hardware on the r4000 machine?  

Depends.  The older R4000s were really buggy silicon and we don't
have all the workarounds needed to keep them happy.  So in theory if
circumstances are just right that can explain why you have so much
fun with the R4000 machine.

When the kernel is booting it prints a a line "CPU revision is: xxx"
where xxx is a 8 digit hex number.  What number?

  Ralf

---

From: Greg Johnson <[email-masked]>
Date: Mon, 16 Jul 2001 22:39:02 -0400

> running the very same binaries?

They're the same.

> fun with the R4000 machine.

Interesting.

> where xxx is a 8 digit hex number.  What number?

For the r4000 indy:

ARCH: SGI-IP22
PROMLIB: ARC firmware Version 1 Revision 10
CPU: MIPS-R4000 FPU<MIPS-R4000FPC> ICACHE DCACHE SCACHE 
Loading R4000 MMU routines.
CPU revision is: 00000422
Primary instruction cache 8kb, linesize 16 bytes.
Primary data cache 8kb, linesize 16 bytes.
Secondary cache sized at 1024K linesize 128 bytes.

For the r4400 indy:

ARCH: SGI-IP22
PROMLIB: ARC firmware Version 1 Revision 10
CPU: MIPS-R4400 FPU<MIPS-R4400FPC> ICACHE DCACHE SCACHE 
Loading R4000 MMU routines.
CPU revision is: 00000460
Primary instruction cache 16kb, linesize 16 bytes.
Primary data cache 16kb, linesize 16 bytes.
Secondary cache sized at 1024K linesize 128 bytes.

Thanks,

Greg

---

From: Ralf Baechle <[email-masked]>
Date: Tue, 17 Jul 2001 05:00:50 +0200

> CPU revision is: 00000422

That's a really old and buggy CPU.  Kevin Kissel may correct me but I think
it's the first series shipped to customers.  Among the fun bugs:

-----------------------------------------------------------------------------

4. R4000PC, R4000SC: An instruction sequence which contains a load which causes
   a data cache miss and a jump, where the jump instruction is that last
   instruction in the page and the delay slot of the jump is not currently
   mapped, causes the exception vector to be overwritten by the jump address.
   The R4000 will use the jump address as the exception vector.

   Example:	lw	<---- data cache miss
		noop	<---- one or two Noops
		jr	<---- last instruction in the page (jump or branch in-
			      struction)
		--------------<----	page boundary
		noop

   Workaround: Jump and branch instructions should never be in the last loca-
               tion of a page.
11. R4000PC, R4000SC: In the case:

		lw rA, (rn)
		noop		(or any non-conflicting instruction)
		lw rn, (rA)	(where the address in rA causes a TLB refill)
		--------------------> end of page
		page not mapped

   where rn and RA are general purpose registers r0 through r31

   This code sequence causes the second load instruction to slip due to a
   load use interlock. When the R4000 crosses the page boundary after the
   lw, it vectors to 0x8000 0000 and later causes an instruction cache miss.
   After the instruction cache miss is complete the LW causes another TLB
   refill. This should vector to 0x8000 0000 but instead goes to 0x8000 0180.

14 (Just an update of erratum 4)

-----------------------------------------------------------------------------

There's more but I don't want to paste the whole errata document in here
and above bugs alone without the respective workarounds in kernel and tools
are grave bugs.

  Ralf

---

From: Greg Johnson <[email-masked]>
Date: Mon, 16 Jul 2001 23:08:30 -0400

On Tue, Jul 17, 2001 at 05:00:50AM +0200, Ralf Baechle wrote:

<erratta deleted>

> and above bugs alone without the respective workarounds in kernel and tools

Ok.  Fixing any of that is beyond me.  I guess it makes a nice monitor
stand for now. :-)

It's nice to know that there is a reason it doesn't work.

Thanks again,

Greg

---

From: "Kevin D. Kissell" <[email-masked]>
Date: Tue, 17 Jul 2001 07:50:00 +0200

I don't have access to old R4000 revision data, and I'll take your
word for the errata applicable to rev 0422.  A am a *little* surprised
that such early parts found their way into Indys, since the Indy was
not the first R4000 platform (I believe that honor belongs to the
"Crimson" graphics workstations), but it's certainly possible.

            Regards,

            Kevin K.

---

From: Ralf Baechle <[email-masked]>
Date: Tue, 17 Jul 2001 09:06:24 +0200

On Tue, Jul 17, 2001 at 07:50:00AM +0200, Kevin D. Kissell wrote:

> word for the errata applicable to rev 0422.

There is a cool site on the internet to get such data.  It's
http://www.mips.com/Documentation/R4000_3.0_2.2_PC_SC_errata.pdf :-)

> A am a *little* surprised that such early parts found their way into
> Indys, since the Indy was not the first R4000 platform (I believe that
> honor belongs to the "Crimson" graphics workstations), but it's certainly
> possible.

Agreed.  So far I thought the oldest CPU module we have to worry about
is v3.0.

If somebody has an old 2.2 CPU module for an Indy lying around which he
wants to send to me for debugging such stuff ...

  Ralf

---

From: Geert Uytterhoeven <[email-masked]>
Date: Tue, 17 Jul 2001 09:28:08 +0200 (MEST)

> http://www.mips.com/Documentation/R4000_3.0_2.2_PC_SC_errata.pdf :-)

You did make a copy on CDR? Interesting docs tend to disappear from the
Internet...

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE)
[email-masked] ------------------- Sint-Stevens-Woluwestraat 55
Voice +32-2-7248626 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Tue, 17 Jul 2001 10:16:18 +0200 (MET DST)

> You did make a copy on CDR? Interesting docs tend to disappear from the

 I'm mirroring whatever I can -- feel free to ask if you are looking for a
particular document or for any documents on a particular item. 

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