Devices with 36-bit paddr on 32-bit system

[John Baldwin]

On Tuesday, August 25, 2015 08:55:45 AM Marcel Moolenaar wrote:
> 
> > On Aug 24, 2015, at 11:44 PM, Justin Hibbits <jrh29 at alumni.cwru.edu> wrote:
> > 
> > With my work porting FreeBSD to PowerPC e500mc and e5500, I have
> > devices in my device tree mapped well above the 4GB mark
> > (0xffexxxxxx), and have no idea how to properly address them for
> > resources in rman.  Do we already have a solution to support this?
> > Part of the problem is the powerpc nexus does a straight convert to
> > vm_offset_t of rman_get_start() (itself returning a u_long), and
> > vm_offset_t is not necessarily equal to vm_paddr_t (on Book-E powerpc
> > vm_offset_t is 32-bits, vm_paddr_t is 64-bits).
> 
> I think the best solution is to represent a resource address
> space with a type other than u_long. It makes sense to have
> it use bus_addr_t or vm_paddr_t for example. Such a change
> comes at a high price for sure, but you’ll fix it once and
> for all. I don’t think you should kluge your way out of this...

Expanding beyond u_long is the right solution.  PAE doesn't generally suffer
from this on i386 (though the ram0 device "punts" and ignores RAM ranges above
4G as a workaround).

However, u_long is baked into the bus resource API quite a bit.  Specifically,
the values 0ul and ~0ul are used as magic numbers in lots of places to request
"anywhere" locations.  Some of this has been mitigated by
bus_alloc_resource_any(), but that doesn't cover all cases.  You will probably
want to add some explicit constants and do a sweep replacing the magic numbers
with those first (and MFC the constants at least to make it easier to port
drivers across branches).  Then you can change the type.

As far as the best type: rman's are in theory generic and not just for bus
addresses.  I'd be tempted to let each platform define an rman_addr_t along
with RMAN_ADDR_MAX constants, but in practice it is probably fine to use
bus_addr_t and BUS_SPACE_MAXADDR.  If you do that it also means you can skip
the step of having to MFC new constants.

Note that various bus APIs will have to change to use bus_addr_t instead of
u_long as well.

-- 
John Baldwin