Date: Mon, 11 Feb 2013 09:14:47 -0800 From: Tim Kientzle <tim@kientzle.com> To: Ian Lepore <ian@freebsd.org> Cc: freebsd-arm@freebsd.org, Brett Wynkoop <wynkoop@wynn.com> Subject: Re: building RaspPi Images Message-ID: <3F4CD7E5-17D4-4315-86BD-605F5C0040DC@kientzle.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
>>> 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?
Here are several answers:
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.)
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.
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.
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.
>> 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.
> 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.
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.
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.
Tim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3F4CD7E5-17D4-4315-86BD-605F5C0040DC>