Subject: Re: 64-bit paddr_t (again, arrgh....)
To: Simon Burge <simonb@wasabisystems.com>
From: Garrett D'Amore <garrett_damore@tadpole.com>
List: port-mips
Date: 01/30/2006 15:10:35
Simon Burge wrote:
> On Mon, Jan 30, 2006 at 02:39:34PM -0800, Matt Thomas wrote:
>
>   
>> Garrett D'Amore wrote:
>>
>>     
>>> The MIPS64 stuff is going to be a problem, I think, almost no matter
>>> what.  I cannot see that evbmips can properly encompass both a 64-bit
>>> and a 32-bit kernel.  (Note that this is different than the 64-bit
>>> part running in 32-bit compatibility mode.)
>>>       
>> mips64 will need a separate machine_arch.
>>     
>
> I agree with Matt here.
>
> I think that evbmips should be able to support both 32-bit and 64-bit
> ports.  Issues about MACHINE_ARCH can be dealt with when they arise.
> The same issues will also affect any other MIPS port with a 64-bit
> capable CPU (which is most of them).
>   
Sorry I was confusing machine_arch with something else, I think.
>   
>>> So can I take this as approval to go ahead and make that change, so
>>> that paddr_t is 64-bits on all evbmips?
>>>       
>> Yes.
>>     
>
> Same here.  If you can do some simple before-and-after benchmarks too
> that'd be nice, but not necessary.
>   
Okay, I'll commit the change later today, once I've validated it by itself.
> Also, does bus_addr_t (and bus_size_t) need to be 64-bits too?
>   
For my purposes, no.  If someone ever wants to support 64-bit PCI on the
platform it could crop up, but I don't see that as being to much of a
risk at the moment.

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