Date: Fri, 28 Aug 2015 10:35:50 -0700 From: John Baldwin <jhb@freebsd.org> To: freebsd-arch@freebsd.org Cc: Marcel Moolenaar <marcel@xcllnt.net>, Justin Hibbits <jrh29@alumni.cwru.edu> Subject: Re: Devices with 36-bit paddr on 32-bit system Message-ID: <1568331.OrSoeYfXsf@ralph.baldwin.cx> In-Reply-To: <ED4B5B25-D7A7-440C-9452-4C79B0800D2E@xcllnt.net> References: <CAHSQbTDsvB32%2BLyzHJO78VwUwAfUTMOUQp13BMCUpapSMT0fbg@mail.gmail.com> <ED4B5B25-D7A7-440C-9452-4C79B0800D2E@xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, August 25, 2015 08:55:45 AM Marcel Moolenaar wrote: > > > On Aug 24, 2015, at 11:44 PM, Justin Hibbits <jrh29@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1568331.OrSoeYfXsf>