Date: Mon, 11 Feb 2013 09:58:11 -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: <4CCEF987-A506-436C-81FC-91910440507E@bsdimp.com> In-Reply-To: <1360600007.4545.98.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> <DCA761EF-FAE4-4BC9-AE33-D9F55C8ABB16@bsdimp.com> <1360600007.4545.98.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 11, 2013, at 9:26 AM, Ian Lepore wrote:
> On Mon, 2013-02-11 at 09:10 -0700, Warner Losh wrote:
>> On Feb 11, 2013, at 9:01 AM, Ian Lepore wrote:
>>=20
>>> 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?
>>=20
>> 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...
>=20
> 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.
I don't see how this is an unsatisfying answer. If there's a FDT from =
the BIOS, we use it by default. If the user wants to change things on =
the board, they need to provide a custom FDT to match their changes.
> 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.
You CAN use it however you want, true. However, there are some defaults =
that the default BIOS provides and if you want to change the defaults, =
you have to change the defaults. The way to you do that is via a custom =
FDT.
> 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
If you do customization, you have to have a custom FDT. There's no =
getting around that. This is standard issue in the Linux world, and =
should be standard issue in FreeBSD as well. We have to start converging =
on interfaces that allow extensibility, and FDT is one such interface.
But that's no different than what we have today, except *EVERYTHING* is =
custom today. My position is that, by default, we use the FDT that the =
BIOS provides, and if the user wants to do custom things, they do what =
the do in Linux and load a custom FDT/DTB to describe those custom =
things.
My main two points: (1) We should really try harder to use the FDT from =
the board and (2) We should avoid mechanisms outside of FDT to make it =
"easy" since those mechanisms likely will make it harder.
Warner=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4CCEF987-A506-436C-81FC-91910440507E>