Subject: Re: port-mips is a mips-CPU list, not a MipsCo port
To: michael smith <email@example.com>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 02/28/1997 19:29:31
Michael Smith writes:
>To that end, I'd like to stir a little discussion about the MipsCo
>boxes, particularly with regard to the NetBSD mips support of the r3k
>in a big-endian environment. All the MipsCo machines of which I am
>aware are r3kbe (there are probably some r2k machines but I know
>nothing of them).
>Is the MI mips code ready for showtime?
I beleive that bcopy() still needs to be re-written to be bi-endian:
e.g., by using macros to do "load higher address" (word,byte), rather
than explicit lwl/lwr.
Otherwise, I think the MI mips code is basically ready for showtime.
Michael Hitch has got an r4k-based DECstation to single-user prompt.
These machines have nontrivial secondary caches, and so need some more
support than was in Per's original Pica code.
I haven't looked at later OpenBSD code; I'll leave that to someone who
has. Certainly I think writing "MI" mips support is the right way to
go. Until recently, none of the NetBSD/mips developers had access to
r4k machines; that's no longer the case and things are happening.
Getting NetBSD-current up on one of the bi-endian ARC-like machines
may be a useful porting path to going bi-endian.
>How would one go about
>constructing a arch subtree to make use of it? What still needs
>work? Per recently committed an r3kbe port (wgrisc) to the OBSD
>tree which I have been studying for a while now in an effort to
>reach some understanding of the various issues, but I'm still
All I can say for now is: see arch/pmax/pmax.
You'll need port-specific versions of
And also of the include files in arch/pmax/include that just include
files from arch/mips/include.
I don't know how far Michael Hitch has got with the r4k version of
pmap.c; when that works reliably with 2nd-level caches, there's likely
to be an MI arch/mips/mips/pmap.c, with #ifdef's to allow compiling
for mips1, mips3 or (soon) both. Some of the other files could (and
hopefully will) be made more MI. The pmax cpu.c is more-or-less MI;
it's only separate to allow a callback to estimate the CPU clock
speed, and thus the DECstation model number.
Also, there *are* people interested in working on newer MipsCo
hardware, (e.g., Magnums). This list exists so they can speak for
themselves, so I'll let them do so...