Date: Mon, 11 Feb 2013 10:42:41 -0700 From: Ian Lepore <ian@FreeBSD.org> To: Tim Kientzle <tim@kientzle.com> Cc: freebsd-arm@FreeBSD.org, Brett Wynkoop <wynkoop@wynn.com> Subject: Re: building RaspPi Images Message-ID: <1360604561.4545.115.camel@revolution.hippie.lan> 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 Mon, 2013-02-11 at 09:14 -0800, 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?
>
> 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.)
>
I actually find it much easier to recompile the kernel than any of the
other alternatives I've run into, but I understand that an end user
would see it differently. I also find that while I'm trying to be
open-minded about fdt in general, I still find it much more cumbersome
to work with than the old hints system. The very fact that you need a
special compiler to change the fdt data is part of that.
In general, the fdt data seems to be good at describing hardware
relationships that are hard to express with simple hints, such as how
pins that generate interrupts are mapped between various devices and
interrupt controllers. But it seems to be hard to use when the nature
of the customizations are simple choices.
> 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.
>
I whole-heartedly agree with that last sentence, but it's about a
zillion miles from where our code is now. I'm not even sure it's fully
possible, it just seems like a nice generic ideal "I asked for a uart,
so the uart driver should enable power, enable clocks, and assign pins
to make that happen." The problem crops up when "assign pins" has
several sets of pins to choose from for a given device, and I know at
least the Atmel SoCs do this a lot.
> 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.
>
I'll look into this, although when I was playing with it a couple weeks
ago, I was having a hard time doing *anything* with loader.rc at all.
That got me involved in trying to get the forth code running so that
we'd have the full btx-loader goodness in the arm world with loader.conf
files that we're all familiar with already. That was going pretty well
except for our kernels not having proper elf headers, and I started to
sidetrack to fix that, and then $work happened and I haven't gotten back
to any of it yet.
-- Ian
> >> 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...
> >
> > 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.
> >
> > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1360604561.4545.115.camel>