From owner-freebsd-arm@FreeBSD.ORG Mon Feb 11 16:02:01 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 71F35D0D for ; Mon, 11 Feb 2013 16:02:01 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id D6385AFF for ; Mon, 11 Feb 2013 16:01:56 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r1BG1sMe066095 for ; Mon, 11 Feb 2013 09:01:56 -0700 (MST) (envelope-from ian@FreeBSD.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r1BG1pJp039675; Mon, 11 Feb 2013 09:01:51 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: building RaspPi Images From: Ian Lepore To: Warner Losh In-Reply-To: References: <5116CB50.9080303@ceetonetechnology.com> <7757848F-45C6-4DEF-A4A2-5F900EB10A06@kientzle.com> <20130210012052.4d7e1a46@ivory.local> <58DCA6BE-8C06-4F69-81A2-A3582FBB5B12@kientzle.com> Content-Type: text/plain; charset="us-ascii" Date: Mon, 11 Feb 2013 09:01:51 -0700 Message-ID: <1360598511.4545.92.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Tim Kientzle , freebsd-arm@FreeBSD.org, Brett Wynkoop X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 16:02:01 -0000 On Sun, 2013-02-10 at 00:07 -0700, Warner Losh wrote: > On Feb 10, 2013, at 12:03 AM, Tim Kientzle wrote: > > > On Feb 9, 2013, at 10:20 PM, Brett Wynkoop wrote: > >> > >> I was thinking that we should be able to generate a generic image that > >> will boot on both the Pi and the Bone. Maybe a config file that > >> includes the needed drivers for both boards. > > > > I've thought about this and believe it is pretty routine, > > though I've not had time to actually try implementing it. > > > > This specific combination is simplified by the fact > > that the boot bits are so different, so you can just > > put them all on the same SD card image. > > > > There are a few pieces you'll need to work through: > > 1. An MSDOS partition with all the boot bits from both systems > > 2. A kernel with all of the drivers for both systems > > 3. ubldr will need to identify the board somehow > > 4. ubldr will need to obtain the correct FDT > > uboot is supposed to be providing the correct FDT. IF we aren't using it, we're doing FDT wrong and need to fix that. > > > Except for #3, this should all be entirely routine. > > > > For #4, the trick is to not compile any DTB into the > > kernel. Instead, the DTB is given to the kernel by > > the boot bits: > > > > * For RPi, this already happens: the first-stage boot > > loads a DTB, ubldr uses "fdt addr" to access that DTB > > in a known location and then passes it to the kernel. > > Doesn't the RPi's boot loader give our /boot/loader enough info to get this without the fdt addr command? > > > * For Beaglebone, you can use loader.rc commands to load > > the proper DTB from the UFS partition. I'm using the following > > on my BeagleBone right now: > > /boot/beaglebone.dtb > > /boot/loader.rc contains > > load /boot/kernel/kernel > > load -t dtb /boot/beaglebone.dtb > > autoboot > > why isnt' the beagle board's boot loader passing it to /boot/loader? > > > This should be an afternoon's work for someone who already > > has a good understanding of FreeBSD boot processes. > > The real solution here is to get the FDT plumbed through from the boards primary boot strap code into our code. Linux requires that this be passed in via like r2 for Linux to boot. We should make use of that too. > > Warner I'm seeing an essential conflict here in the mission of FDT data. If changing the FDT is the way an end user customizes things like pinmux assignments ("I need these pins for gpio, not another uart"), then how can we just accept a cannonical hardware description from low-level boot code we have no control over? -- Ian