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
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191