Devices with 36-bit paddr on 32-bit system

[Adrian Chadd]

+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 at 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 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
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"