Subject: Re: 64-bit paddr_t (again, arrgh....)
To: Garrett D'Amore <garrett_damore@tadpole.com>
From: Matt Thomas <matt@3am-software.com>
List: port-mips
Date: 01/30/2006 13:54:44
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).

> 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 think that we need four new machine archs, mips32e[lb] and mips64e[lb]
while leaving the existing mipse[bl] machine arches for O32.

-- 
Matt Thomas                     email: matt@3am-software.com
3am Software Foundry              www: http://3am-software.com/bio/matt/
Cupertino, CA              disclaimer: I avow all knowledge of this message.