Date: Mon, 11 Feb 2013 09:10:13 -0700 From: Warner Losh <imp@bsdimp.com> To: Ian Lepore <ian@FreeBSD.org> Cc: Tim Kientzle <tim@kientzle.com>, freebsd-arm@FreeBSD.org, Brett Wynkoop <wynkoop@wynn.com> Subject: Re: building RaspPi Images Message-ID: <DCA761EF-FAE4-4BC9-AE33-D9F55C8ABB16@bsdimp.com> In-Reply-To: <1360598511.4545.92.camel@revolution.hippie.lan> 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> <1360598511.4545.92.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
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:
>>=20
>>> On Feb 9, 2013, at 10:20 PM, Brett Wynkoop wrote:
>>>>=20
>>>> 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.
>>>=20
>>> I've thought about this and believe it is pretty routine,
>>> though I've not had time to actually try implementing it.
>>>=20
>>> 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.
>>>=20
>>> 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
>>=20
>> 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.
>>=20
>>> Except for #3, this should all be entirely routine.
>>>=20
>>> 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:
>>>=20
>>> * 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.
>>=20
>> Doesn't the RPi's boot loader give our /boot/loader enough info to =
get this without the fdt addr command?
>>=20
>>> * 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
>>=20
>> why isnt' the beagle board's boot loader passing it to /boot/loader?
>>=20
>>> This should be an afternoon's work for someone who already
>>> has a good understanding of FreeBSD boot processes.
>>=20
>> 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.
>>=20
>> Warner
>=20
> 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...
Warner=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?DCA761EF-FAE4-4BC9-AE33-D9F55C8ABB16>