Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: Florian Lohoff <flo@rfc822.org>
To: linux-mips@oss.sgi.com
Subject: MIPS32 patches breaking DecStation
Date: Tue, 9 Jan 2001 00:41:01 +0100	[thread overview]
Message-ID: <20010109004101.B27674@paradigm.rfc822.org> (raw)


Hi,
i found this snippet from arch/mips/kernel/head.S breaking DecStations:

@@ -68,9 +76,9 @@
        mtc0    k0, CP0_ENTRYLO0                # load it
        srl     k1, k1, 6                       # convert to entrylo1
        mtc0    k1, CP0_ENTRYLO1                # load it
-       b       1f
-        tlbwr                                  # write random tlb entry
-1:     
+       nop                                     # Need 2 cycles between mtc0
+       nop                                     #  and tlbwr (CP0 hazard).
+       tlbwr                                   # write random tlb entry
        nop
        eret                                    # return from trap
        END(except_vec0_r4000)


>From the Documentation and how i understand it this is perfectly
valid as the mtc0 instruction causes a cp0 hazard within the next 2 instruction
thought the delay of 2 cycles would be ok.

This is probably related to the Decstations having REALLY old R4000 silicion
revisions - Probably one should look through the erratas for these

flo@repeat:~$ cat /proc/cpuinfo 
cpu			: MIPS
cpu model		: R4000SC V3.0
system type		: Digital DECstation 5000/1xx

OK - I just had a look at the errata - This IS a workaround to a 
Mips R4000SC 2.0, 3.0 errata - I restored the original code back.

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?

WARNING: multiple messages have this Message-ID (diff)
From: Florian Lohoff <flo@rfc822.org>
To: linux-mips@oss.sgi.com
Subject: MIPS32 patches breaking DecStation
Date: Tue, 9 Jan 2001 00:41:01 +0100	[thread overview]
Message-ID: <20010109004101.B27674@paradigm.rfc822.org> (raw)
Message-ID: <20010108234101.t2OW-aNqLmcn0hv4IqLTy7Z28xZsFq57pJJ2N90Pz2E@z> (raw)


Hi,
i found this snippet from arch/mips/kernel/head.S breaking DecStations:

@@ -68,9 +76,9 @@
        mtc0    k0, CP0_ENTRYLO0                # load it
        srl     k1, k1, 6                       # convert to entrylo1
        mtc0    k1, CP0_ENTRYLO1                # load it
-       b       1f
-        tlbwr                                  # write random tlb entry
-1:     
+       nop                                     # Need 2 cycles between mtc0
+       nop                                     #  and tlbwr (CP0 hazard).
+       tlbwr                                   # write random tlb entry
        nop
        eret                                    # return from trap
        END(except_vec0_r4000)


From the Documentation and how i understand it this is perfectly
valid as the mtc0 instruction causes a cp0 hazard within the next 2 instruction
thought the delay of 2 cycles would be ok.

This is probably related to the Decstations having REALLY old R4000 silicion
revisions - Probably one should look through the erratas for these

flo@repeat:~$ cat /proc/cpuinfo 
cpu			: MIPS
cpu model		: R4000SC V3.0
system type		: Digital DECstation 5000/1xx

OK - I just had a look at the errata - This IS a workaround to a 
Mips R4000SC 2.0, 3.0 errata - I restored the original code back.

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?

             reply	other threads:[~2001-01-08 23:41 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-01-08 23:41 Florian Lohoff [this message]
2001-01-08 23:41 ` MIPS32 patches breaking DecStation Florian Lohoff
2001-01-09  0:34 ` Kevin D. Kissell
2001-01-09  0:34   ` Kevin D. Kissell
2001-01-09  8:54   ` Florian Lohoff
2001-01-09 17:11     ` Harald Koerfgen
2001-01-09 18:28       ` Ralf Baechle
2001-01-09 19:30         ` Kevin D. Kissell
2001-01-09 19:30           ` Kevin D. Kissell
2001-01-09 19:54           ` Ralf Baechle
2001-01-09 19:54             ` Ralf Baechle
2001-01-09 20:33             ` Kevin D. Kissell
2001-01-09 20:33               ` Kevin D. Kissell
2001-01-09 15:09   ` Ralf Baechle
2001-01-09 15:09     ` Ralf Baechle
2001-01-09 15:50     ` Kevin D. Kissell
2001-01-09 15:50       ` Kevin D. Kissell
2001-01-09 16:43 ` Harald Koerfgen
2001-01-09 17:01   ` Ralf Baechle

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=20010109004101.B27674@paradigm.rfc822.org \
    --to=flo@rfc822.org \
    --cc=linux-mips@oss.sgi.com \
    /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