Skip site navigation (1)Skip section navigation (2)
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>