From owner-freebsd-arch@freebsd.org Fri Aug 28 20:59:35 2015 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8FA359C4B78 for ; Fri, 28 Aug 2015 20:59:35 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5B9FCCBC; Fri, 28 Aug 2015 20:59:35 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by igph8 with SMTP id h8so19653552igp.0; Fri, 28 Aug 2015 13:59:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=oorMlEat01N/AiCV1fYEkkQQXdufCr06LqrTbHPpJpg=; b=y65PoXP6rl5nwH6Ho09xyEzK9iCQuA+vvq6cDElY8UNIGxX5jnRxyVv5InGTg03/hF D0tfDX4aumQeaKxyfyJc6DLDevwn76dMWmzpxafzRDXSpF3UXQQ9mHwDgxy77oOXzD+N SSvK4OkvNfzk1I8tM0H1hKlz7jX6PdMduDZBWIeuIWApk5qC4NYwE16qz4id6kVhDZG9 4hUlvQRz3EIf/IWBqmt8aFXmSEo+3571vnj0eMz9T2hHbOYhf6uHP1/ZnXRmdpp1j8Q9 FKWSf3Tpvwo+R9lY3o8KpwwGcYg/xp2Kf1qsayIo9B0dg5VpySVDNbdxL1JhAZ+hdNu6 GHcg== MIME-Version: 1.0 X-Received: by 10.50.120.9 with SMTP id ky9mr4791154igb.61.1440795574209; Fri, 28 Aug 2015 13:59:34 -0700 (PDT) Received: by 10.36.28.208 with HTTP; Fri, 28 Aug 2015 13:59:34 -0700 (PDT) In-Reply-To: <1568331.OrSoeYfXsf@ralph.baldwin.cx> References: <1568331.OrSoeYfXsf@ralph.baldwin.cx> Date: Fri, 28 Aug 2015 13:59:34 -0700 Message-ID: Subject: Re: Devices with 36-bit paddr on 32-bit system From: Adrian Chadd To: John Baldwin Cc: "freebsd-arch@freebsd.org" , Justin Hibbits , Marcel Moolenaar Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 20:59:35 -0000 +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 wrote: > On Tuesday, August 25, 2015 08:55:45 AM Marcel Moolenaar wrote: >> >> > On Aug 24, 2015, at 11:44 PM, Justin Hibbits 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"