Date: Mon, 11 Feb 2013 11:04:48 -0700 From: Warner Losh <imp@bsdimp.com> To: Tim Kientzle <tim@kientzle.com> Cc: freebsd-arm@freebsd.org, Brett Wynkoop <wynkoop@wynn.com>, Ian Lepore <ian@freebsd.org> Subject: Re: building RaspPi Images Message-ID: <780B5A66-2727-4E16-B912-93AAD7FDE21B@bsdimp.com> In-Reply-To: <3F4CD7E5-17D4-4315-86BD-605F5C0040DC@kientzle.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> <1360598511.4545.92.camel@revolution.hippie.lan> <DCA761EF-FAE4-4BC9-AE33-D9F55C8ABB16@bsdimp.com> <1360600007.4545.98.camel@revolution.hippie.lan> <3F4CD7E5-17D4-4315-86BD-605F5C0040DC@kientzle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 11, 2013, at 10:14 AM, Tim Kientzle wrote:
>>>> 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
> Here are several answers:
>=20
> 1) The immediate result of this change will make
> it *easier* to change the FDT. Right now, most people
> are recompiling the kernel just to tweak the FDT.
> This change moves it out into a separate standalone
> file in the boot partition. (You still need to compile
> the DTS, but you can at least change it and reboot
> without touching the kernel.)
This is good.
> 2) We're still debating the role of the FDT vis a vis
> end user customization. Personally, I would like
> to find some more dynamic approach to handling
> pinmux at runtime. (E.g., if you want to use a pin
> for gpio, you do this:
> $ gpioctl 1 7 out # Set gpio 1 7 for output, including pinmux =
change
> $ gpioctl 1 7 on
> Similarly, I think that enabling uart2 should automatically
> adjust the pinmux appropriately.
These are also good, but we have a long ways to go in the kernel to get =
there. And there are limits to how far you can push this envelope.
However, enabling uart2 is also done through the FDT, at least in linux, =
but it takes care of these pesky details for the most part.
> 3) IIUC, the FDT concept came from the PowerPC
> world, where the FDT is provided by the ROM.
> It's not really a tool for customizing the system; it's a tool
> for describing the hardware available.
It is a tool to describe how the hardware is configured as well. It is =
the only place where you can find how things are wired together. That's =
its primary purpose. If you are customizing your hardware, you are =
wiring it together differently.
> 4) Ubldr already has tools for adjusting the FDT
> dynamically at boot time. I just committed the
> online help for this "help fdt". So you can indeed
> adjust the FDT via loader.rc. That works today, even
> when the FDT is compiled into the kernel.
>=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.
>>=20
>> 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.
>=20
>> 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.
>=20
> Right now, we're using U-Boot for exactly two things:
> * Boot loader driver. Rather than writing board-specific
> drivers for ubldr for every board, we get to leverage U-Boot.
> * Providing the *default* FDT.
>=20
> The code I circulated yesterday uses the following logic to find
> the FDT:
> 1) If an FDT was loaded into ubldr, use that. (E.g., "load -t dtb =
filename")
> 2) If U-Boot provided an FDT, use that.
> 3) If the kernel has a compiled-in FDT, use that.
Yes, I like that.
Warner=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?780B5A66-2727-4E16-B912-93AAD7FDE21B>