Date: Tue, 12 Feb 2013 09:44:44 -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: <0F135283-ACDB-4126-A74F-04FF9321399C@bsdimp.com> In-Reply-To: <1360681004.4545.160.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> <72554169-D2DD-48DD-8C2F-6C411DBFCE4D@kientzle.com> <1360681004.4545.160.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 12, 2013, at 7:56 AM, Ian Lepore wrote: > On Mon, 2013-02-11 at 22:27 -0800, Tim Kientzle wrote: >> On Feb 11, 2013, at 9:42 AM, Ian Lepore wrote: >>=20 > [snip] >>=20 >> At least for BeagleBone, I think I see a way to >> make the pinmux code work this way. That code is >> all table-driven, so with some creative reworking of >> the tables, it should be feasible to define groups of >> pins and a mechanism to manage them. Tedious >> work, to be sure, simply because of the sheer number >> of definitions involved, but nothing particularly complicated. >>=20 >> Another approach I've considered is to have the >> necessary pinmux assignments be part of the >> device entry in the DTS. (BeagleBone DTS, at >> least, defines a single list of pinmux settings for >> the board, which I don't like at all.) This would >> be similar to the way interrupts and memory >> regions are assigned today. That would at >> least move the problem down to the level of >> enabling/disabling particular entries in the DTS. >> Unfortunately, I don't yet understand the inner workings >> of simplebus and the FDT management in the kernel >> well enough to be able to tackle this just yet. >>=20 >> Having pinmux settings be part of the associated >> device node in the DTS would also make your next >> issue a little easier to manage, I think. (For example, >> the DTS in SVN could have several versions of a single >> device with most of them disabled.) >=20 > I've seen a block at the bottom of some dts source named "choices" or > something like that. That seems to hint at the possibility of > describing a variety of stock configurations for various devices and > then the choosing of configurations might be little more than > manipulating some strings in that section. That's the sort of thing > that might be easy to handle within ubldr. Doing more than that in > ubldr might set us on the path of turning it into a dts compiler. "chosen" is what you are talking about. It isn't quite what you think it is for. This section is for = communicating some settings to the kernel, but it isn't supposed to = enable/disable devices. What you are describing sounds cool, but I have = grave doubts it would work. It also goes against the main tenants of = FDT, which is that you have a simple binary blob that describes how = you've configured/wired your hardware together and the kernel can = completely rely on that to do configuration. Adding weird settings in = the chosen setting gets us back to the days of having some things = compiled in, and some things selected with hints. btw, what's wrong with optionally turning ubldr into a dts compiler? = Assuming, that is, that the BSD dts compiler project makes progress = enough to keep up with the GPL'd one? Warner=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0F135283-ACDB-4126-A74F-04FF9321399C>