Subject: Re: 64-bit paddr_t (again, arrgh....)
To: Simon Burge <firstname.lastname@example.org>
From: Garrett D'Amore <email@example.com>
Date: 01/30/2006 14:59:28
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
>>>>> 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
>>> 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).
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
>>> 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 RK 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 RK, 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,
Frankly, the userland for all MIPS ports with the same userland should
be identical. (Module endianness and 32 vs. 64 bit.) Likewise the LKM
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.
> Simon Burge <firstname.lastname@example.org>
> NetBSD Development, Support and Service: http://www.wasabisystems.com/
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
Phone: 951 325-2134 Fax: 951 325-2191