Date: Mon, 11 Feb 2013 11:08:14 -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: <82E702D7-3099-4D23-B233-A19F85FE4118@bsdimp.com> In-Reply-To: <1360604561.4545.115.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> <3F4CD7E5-17D4-4315-86BD-605F5C0040DC@kientzle.com> <1360604561.4545.115.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 11, 2013, at 10:42 AM, Ian Lepore wrote:
> 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?
>>=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.)
>>=20
>=20
> 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.
>=20
> 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.
Indeed.
>> 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.
>>=20
>=20
> 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.
In Linux land, at least for Atmel, they have created pin groups that are =
switched together when things like the uarts are enabled. It looks to be =
pretty slick, but I haven't seen it in its final form.
We can do it mostly by default, with the special cases being handled =
specially.
>> 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.
>>=20
>> 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
>=20
> 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.=20=
>=20
> 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.
I hate it when $work happens...
Warner
> -- Ian
>=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.
>=20
>=20
> _______________________________________________
> freebsd-arm@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?82E702D7-3099-4D23-B233-A19F85FE4118>