Date: Fri, 28 Aug 2015 13:59:34 -0700 From: Adrian Chadd <adrian.chadd@gmail.com> To: John Baldwin <jhb@freebsd.org> Cc: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org>, Justin Hibbits <jrh29@alumni.cwru.edu>, Marcel Moolenaar <marcel@xcllnt.net> Subject: Re: Devices with 36-bit paddr on 32-bit system Message-ID: <CAJ-VmomduZBYT6=e7HUm2V1m0taM0MAMXxMojYV8wvgEKyUEyA@mail.gmail.com> In-Reply-To: <1568331.OrSoeYfXsf@ralph.baldwin.cx> References: <CAHSQbTDsvB32%2BLyzHJO78VwUwAfUTMOUQp13BMCUpapSMT0fbg@mail.gmail.com> <ED4B5B25-D7A7-440C-9452-4C79B0800D2E@xcllnt.net> <1568331.OrSoeYfXsf@ralph.baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
+1 on this. Also - justin/i figured it out (well, I made the suggestion, he did the suggestion) which is just to do a big/single mapping of the relevant hardware window into vmem early in boot, and hack that bus nexus to treat things as being in that vmem region. He's gotten pretty far along the device bringup path now. That way the rmem allocation is just from that vmem region. -adrian On 28 August 2015 at 10:35, John Baldwin <jhb@freebsd.org> wrote: > 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> w= rote: >> > >> > 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=E2=80=99ll fix it once and >> for all. I don=E2=80=99t think you should kluge your way out of this... > > Expanding beyond u_long is the right solution. PAE doesn't generally suf= fer > 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. Specific= ally, > the values 0ul and ~0ul are used as magic numbers in lots of places to re= quest > "anywhere" locations. Some of this has been mitigated by > bus_alloc_resource_any(), but that doesn't cover all cases. You will pro= bably > want to add some explicit constants and do a sweep replacing the magic nu= mbers > with those first (and MFC the constants at least to make it easier to por= t > 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 bu= s > addresses. I'd be tempted to let each platform define an rman_addr_t alo= ng > 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 s= kip > 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 > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmomduZBYT6=e7HUm2V1m0taM0MAMXxMojYV8wvgEKyUEyA>