Simon Burge wrote:
> 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?
>   
No idea.
>>>> 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).
>   
This sounds like a good idea.  Some changes would have to be made wrt
boot loader interface, etc. though.
>   
>>>> 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.
>   
We sort of already have this with mips/ and evbmips/.  Creating a new
directory would be aesthetically more pleasing, but otherwise have
little value.
>   
>>> 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...
>   
Oh... that's bad.

I think this underscores the fact that 64-bit MIPS needs its own port,
completely separate from the 32-bit.
>   
>>> 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.
>   
That's not *quite* what I had in mind.  What I do think it makes sense
is to consolidate to a few common variants.  Most MIPS based ports have
so much more in common than not, that it seems silly to have half a
dozen or more separate architectures, each with their own bus_spaces,
userlands, etc...

Frankly, the userland for all MIPS ports with the same userland should
be identical.  (Module endianness and 32 vs. 64 bit.)  Likewise the LKM
interfaces.

The fact that there are a couple of variations of busses, etc. could
(should!) be contained within the kernel, and could well be handled by
different config files, I think.

>   
>> 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.
>   
The idea wasn't creating a "new" port, but starting a new "super-port"
which would eventually subsume the other 32-bit MIPS ports.  I'm willing
to table that conversation right now, though.  Its not urgently needed,
IMO, but I do think the idea deserves further exploration at some point.
>   
>> 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...
>   
I don't have any pressing need for any of this.  I was merely pointing
these out in case we were going to discuss the "superport" idea further.

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


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