From owner-freebsd-arm@freebsd.org Thu Oct 20 15:33:09 2016 Return-Path: Delivered-To: freebsd-arm@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 E6D39C1AAEA for ; Thu, 20 Oct 2016 15:33:09 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 86C04E6C for ; Thu, 20 Oct 2016 15:33:09 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id u9KFWjh8041558; Thu, 20 Oct 2016 08:32:45 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id u9KFWX8D041557; Thu, 20 Oct 2016 08:32:33 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201610201532.u9KFWX8D041557@pdx.rh.CN85.dnsmgr.net> Subject: Re: Raspberry Pi 3 support In-Reply-To: To: Warner Losh Date: Thu, 20 Oct 2016 08:32:33 -0700 (PDT) CC: "freebsd-arm@freebsd.org" , Ross Alexander X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 15:33:10 -0000 > On Wed, Oct 19, 2016 at 12:33 PM, Rodney W. Grimes > wrote: > >> On Wed, Oct 19, 2016 at 01:46:20AM -0600, Warner Losh wrote: > >> ... > >> > I've updated the nanobsd build. > >> > > >> > Is the u-boot-rpi3 port different from the other u-boot ports in > >> > requiring someone to snag firmware in addition to u-boot? Will that be > >> > fixed? Or should I go ahead and fix it when I get to rpi3 in my uboot > >> > cleanup? > >> > >> I looked at how the rpi2 u boot port did it. crochet (or whoever) is > >> responsible for building a dtb from a source dts we have. So for now > >> the rpi3 port does not provide the dtb files but will provide the broadcom > >> binary (as the RPI2 port does). Really this is one place where the > >> RPi2 and RPi3 ports could share easily as the firmware should be the same. > >> We need to chat about this further ;) > > > > It would be very nice to support both 32 bit and 64 bit worlds on the > > RPI3. I am not sure if this can be done in one version of uboot, or > > if it would require two, as IIRC it is the binary blob running in the > > GPU that sets the CPU up for 32 or 64 bit. > > Can't be done with one u-boot image. Could be done with two in one FAT. > > However, we don't even support SMP yet on rpi3 and we've barely grown > support in the tree for it. This is a great idea, but a bit premature > I think. I actually think we are way behind the ball on the whole RPI3 support, someone had 64 bit code booting and running on it way back in March 2016, but we still are just now getting that in tree and its being redone from scracth. Meanwhile for 7 months Linux has been shipping and running in 32 bit mode on the RPI3. Thats a lost window of opportunity that can not be recovered. It should of been a rather simple matter to get the RPI2 binaries running on RPI3 with just some u-boot and DTS changes. Basically doing the same thing that was done with the Linux support for RPI3. For many things people are going to want to run on the RPI3 with its small unexpandible memory of 1GB they would be far better off with a 32 bit system anyway. You dont need 64 bit, you dont have the memory space to use it. -- Rod Grimes rgrimes@freebsd.org