Subject: Re: 64-bit paddr_t (again, arrgh....)
To: Matt Thomas <firstname.lastname@example.org>
From: Garrett D'Amore <email@example.com>
Date: 01/30/2006 13:33:20
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.=20
> > 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 us=
a 64-bit ISA). However, it is only supported while in 32-bit mode, or=20
effectively emulating an R4k (at least that is my understanding).
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 =
MIPS ports (sbmips?) into the main evbmips port.
=46rankly, it does strike me as a little odd that we have *so* many differe=
mips based ports. It seems like there should probably have only been one=20
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 anothe=
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 load=
interfacing.) I believe Linux does it this way, FWIW.
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
Phone: 951 325-2134 Fax: 951 325-2191
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (SunOS)
-----END PGP SIGNATURE-----