On Mon, Jan 30, 2006 at 02:09:16PM -0800, Garrett D'Amore wrote:

> Matt Thomas wrote:
> > Garrett D'Amore wrote:
> >> On Monday 30 January 2006 1:04 pm, Matt Thomas wrote:
> >>> Garrett D'Amore wrote:
> >>>> As Izumi-san recently pointed out, there is a problem with my current
> >>>> approach of conditionalizing the size of paddr_t on 64-bit
> >>>> platforms. The problem is that LKMs are likely to be impacted. 
> >>>> (Most of the
> >>>> userland tools work fine, which was my original concern.)
> >>>>
> >>>> I would like to reach a decision on this as soon as possible.  My
> >>>> preference is to just change the paddr_t size across the entire
> >>>> evbmips
> >>>> port.
> >>> does evbmips encompass any non-R4k processors?
> >>
> >> In theory, it does becuase the R5k is also supported on Malta boards
> >> (it uses a 64-bit ISA).  However, it is only supported while in
> >> 32-bit mode, or effectively emulating an R4k (at least that is my
> >> understanding).
> >
> > I was thinking more of the R2000/R3000 (MIPS1).
> I figured as much. :-)  I don't know that there is any plan to
> incorporate those into evbmips.  I would certainly hope that no new
> designs are being created based on those!

I don't know what effect speed-wise using a 64-bit paddr_t on a R2k or
R3k based machine would have, but hopefully not much.  Didn't some of
these cheap wifi APs have some SoC based on an r3k core?

> >> Right now the only two platforms that are supported by evbmips are
> >> the MIPS malta evaluation boards and the Alchemy boards.
> >>
> >> I know that at one point Simon was talking about merging in one or
> >> more of the MIPS ports (sbmips?) into the main evbmips port.

The sbmips and algor ports should both probably me moved in to
evbmips.  The algor port pre-dates evbmips, and the sbmips port already
shares some infrastructure with the evbmips port (mainly stuff under
evbmips/conf from memory).

> >> Frankly, it does strike me as a little odd that we have *so* many
> >> different mips based ports.  It seems like there should probably have
> >> only been one master MIPS port covering all MIPS32 systems (or at
> >> least those with an R4K mmu, which I believe is required to be MIPS32
> >> compliant) and perhaps another port covering all MIPS64 systems.  The
> >> rest of the details about different boards, etc. could easily have
> >> been handled as kernel config files, I think. (The notable challenge
> >> being some early system initialization and boot loader interfacing.) 
> >> I believe Linux does  it this way, FWIW.

A while ago there was a proposal to split sys/arch into sys/cpu and
sys/arch, where CPU support would move to sys/cpu, and the ports
themselves would remain in sys/arch.  I can't recall what the end result
of that discussion was, but it was I guess more of an aesthetic thing
more than a technical thing.

> > One of the problems is that NetBSD should be switching to a N32/N64 ABI
> > instead of still using the O32.  However, that leaves the R[23]K still
> > using O32 and presents a packaging nightmare.
> I guess I am a little ignorant of the ABI differences here.   But there
> shouldn't be any new platforms coming out based on the R[23]K, so I'd
> assume could just leave those alone.

Note that N32 and N64 _need_ 64-bit integer regs, and so will not be
usable on MIPS32.  So currently most boards supported by evbmips can't
use N32 or N64...

> > I think that we need four new machine archs, mips32e[lb] and mips64e[lb]
> > while leaving the existing mipse[bl] machine arches for O32.
> >
> This actually sounds like an excellent way to go.  (I had forgotten the
> endianness issue.  Which actually brings up another consideration, since
> in theory you can build bi-endian binaries.  The YAMON boot loader does
> this.  But also, we don't split out endianness for other ISAs that can
> do both -- see e.g. ARM.  Do we want to do so for MIPS?  Frankly I think
> it is a lot cleaner to have them be separate, since then you don't have
> issues e.g. evbmips-el and evbmips-eb not being distinct in uname
> output, and the problems *that* creates.  It complicates the build
> system to do this, though, because presumably you still only want one
> set of source files.)
> 
> I think consolidation of the MIPS ports should be a TODO list item. 
> (Other platforms like ARM and SH5 might want to follow suit.)

Do you mean the non-evaluation-type stuff?  Like pmax, cobalt, sgimips,
etc?  The definition of a "port" was something that was a standalone
computer product or family, and the evb* ports were catchalls for
evaluation boards and the like.  I don't think it makes sense to move
every port that has a MIPS CPU under sys/arch/mips, if that's what you
mean.  "Consolidation" in terms of code sharing under sys/arch/mips
though is a good thing.

> I also would be more than willing to have the Alchemy be the first
> processor to start a new mips32 port.  (At some level, it gives me the
> opportunity to start carte blanche and skip some IMO undesirable legacy.)

All of our MIPS ports are 32-bit ports currently.  There's no need for
a new MIPS32 port.  64-bit ports (for R4k, etc and MIPS64 CPUS) is a
different story, but not something that needs to be worried about with
respect to the Alchemy parts.

> Another question: there are actually additional ISAs in the MIPS line --
> there is a MIPS16 ISA which I believe tries to improve cache efficiency
> by shrinking a few insts into 16 bits.  I also seem to recall something
> to do with a MIPS extension for multimedia or vector ops ala SSE/SIMD. 
> I'm guessing we would handle this like we do for other platforms --
> enable it in the kernel config if useful, but not in LKM or userland.

I've never looked at these.  MIPS16 is I thought for more things like
smart cards where code density is paramount, and sort of like Thumb code
on ARM.  You have a reduced register set you can use too.  I don't know
how useful it would be in NetBSD.  The MDMX(?) multimedia stuff I think
is supported on only a few high-end MIPS cpus.

Both of these would be "used" by userland code, but probably need some
kernel support to be enabled.  System call support for MIPS16 might be
"fun" too...

Simon.
--
Simon Burge                                   <simonb@wasabisystems.com>
NetBSD Development, Support and Service:   http://www.wasabisystems.com/