Date: Mon, 11 Feb 2013 09:01:51 -0700 From: Ian Lepore <ian@FreeBSD.org> To: Warner Losh <imp@bsdimp.com> Cc: Tim Kientzle <tim@kientzle.com>, freebsd-arm@FreeBSD.org, Brett Wynkoop <wynkoop@wynn.com> Subject: Re: building RaspPi Images Message-ID: <1360598511.4545.92.camel@revolution.hippie.lan> In-Reply-To: <E691571B-EA19-4485-BB02-7486685B44C7@bsdimp.com> References: <5116CB50.9080303@ceetonetechnology.com> <7757848F-45C6-4DEF-A4A2-5F900EB10A06@kientzle.com> <20130210012052.4d7e1a46@ivory.local> <58DCA6BE-8C06-4F69-81A2-A3582FBB5B12@kientzle.com> <E691571B-EA19-4485-BB02-7486685B44C7@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1360598511.4545.92.camel>