From owner-freebsd-arm@FreeBSD.ORG Mon Feb 11 16:26:51 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 556DD4F8 for ; Mon, 11 Feb 2013 16:26:51 +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 2AC9DCF9 for ; Mon, 11 Feb 2013 16:26:50 +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 r1BGQoTE066329 for ; Mon, 11 Feb 2013 09:26:50 -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 r1BGQmwP039768; Mon, 11 Feb 2013 09:26:48 -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> <1360598511.4545.92.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Mon, 11 Feb 2013 09:26:47 -0700 Message-ID: <1360600007.4545.98.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:26:51 -0000 On Mon, 2013-02-11 at 09:10 -0700, Warner Losh wrote: > On Feb 11, 2013, at 9:01 AM, Ian Lepore wrote: > > > 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? > > If you are going to do crazy things like this, then you supply your own custom FDT. If you use the board in its stock configuration, then you use the thing from the boot loader. If you hack the board, you have to hack the FDT to match... That's a massively unsatisfying answer. It makes sense for something like a DreamPlug that's sold as a consumer unit; the phrase "stock config" makes some sense there. What's the stock configuration of a BeagleBoard? Pretty much every ball on the chip is brought out to one of two headers on the board so that you can use the board for virtually anything you want. I think the basic problem here is a desire to treat u-boot as if it were a PC BIOS, but it lacks some of what a traditional BIOS allows a user to do in terms of configuring optional hardware and storing that config. -- Ian