From: Ralf Baechle <ralf@oss.sgi.com>
To: Greg Johnson <gjohnson@superweasel.com>
Cc: linux-mips@oss.sgi.com
Subject: Re: Linux on a 100MHz r4000 indy?
Date: Tue, 17 Jul 2001 05:00:50 +0200 [thread overview]
Message-ID: <20010717050050.A1737@bacchus.dhis.org> (raw)
In-Reply-To: <20010716223902.A16351@superweasel.com>; from gjohnson@superweasel.com on Mon, Jul 16, 2001 at 10:39:02PM -0400
On Mon, Jul 16, 2001 at 10:39:02PM -0400, Greg Johnson wrote:
> 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
next prev parent reply other threads:[~2001-07-17 3:02 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-07-16 20:37 Linux on a 100MHz r4000 indy? Greg Johnson
2001-07-17 1:20 ` Ralf Baechle
2001-07-17 2:39 ` Greg Johnson
2001-07-17 3:00 ` Ralf Baechle [this message]
2001-07-17 3:08 ` Greg Johnson
2001-07-17 5:50 ` Kevin D. Kissell
2001-07-17 5:50 ` Kevin D. Kissell
2001-07-17 7:06 ` Ralf Baechle
2001-07-17 7:28 ` Geert Uytterhoeven
2001-07-17 8:16 ` Maciej W. Rozycki
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=20010717050050.A1737@bacchus.dhis.org \
--to=ralf@oss.sgi.com \
--cc=gjohnson@superweasel.com \
--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