Subject: Re: 64-bit paddr_t (again, arrgh....)
To: Matt Thomas <>
From: Garrett D'Amore <>
List: port-evbmips
Date: 01/30/2006 14:09:16
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!
>> 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.
>> 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.
> 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.
> 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.)

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.)

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.

Am I missing anything else here?

    -- Garrett

Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
Phone: 951 325-2134  Fax: 951 325-2191