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.