Date: Tue, 12 Feb 2013 11:54:03 -0700 From: Warner Losh <imp@bsdimp.com> To: Tim Kientzle <tim@kientzle.com> Cc: freebsd-arm@freebsd.org, Ian Lepore <ian@freebsd.org>, Brett Wynkoop <wynkoop@wynn.com> Subject: Re: building RaspPi Images Message-ID: <27A7F65F-C61D-424F-AD2C-65B29B49B700@bsdimp.com> In-Reply-To: <25EAEA1F-876A-4189-BCD4-A7D438332C11@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> <1360604561.4545.115.camel@revolution.hippie.lan> <72554169-D2DD-48DD-8C2F-6C411DBFCE4D@kientzle.com> <FB6E9736-F961-4685-9502-AA5AC17D9F29@bsdimp.com> <25EAEA1F-876A-4189-BCD4-A7D438332C11@kientzle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 12, 2013, at 10:15 AM, Tim Kientzle wrote: >=20 > On Feb 12, 2013, at 8:40 AM, Warner Losh wrote: >=20 >> The typical approach taken over in linux-land is to have a base = config, then have customizations done with a file that just includes the = base, and enables some of the disabled devices. You don't need several = versions of the DTS at all, just one base one and several smallish files = that describe different board configs. Think of this as: >>=20 >> include "GENERIC" >> nodevice foo >> device bar >> option FRED >> nooption WILMA >>=20 >> FDT is powerful enough to cope with those things today, with the = version we have in the tree. >=20 > Warner, >=20 > Could you point me to a good example of this? Or a second example: = http://lxr.linux.no/linux+v3.7.7/arch/arm/boot/dts/at91sam9g20ek_2mmc.dts This is the 2 mmc version of the 9g20ek evaluation board. This includes = the common 9g20ek definitions, then refines them. The 9g20ek common = includes the SoC definitions. Others that include the SoC definition are = things like kizbox.dts. But again, the pinmux/pin group stuff doesn't seem to be in the 3.7 = kernel :( Warner > I've dug around a little bit in the Linux DTS files > but I'm not sure I yet understand what I'm looking > at well enough to tell which ones are good examples > of this technique in action. >=20 > I also have a question about FDT device probe > ordering: I found in tinkering with BeagleBone that > our current FDT implementation probes each > device in the order it appears in the FDT. > This caused me some confusion when I accidentally > had some device (I don't remember which one; call > it FOO) before the SCM controller (which handles pinmux). > The FOO attach blew up because it couldn't > get access to the SCM controller. (Yes, the FOO > driver did explicitly list SCM as a requirement.) >=20 > I wonder if simple bus shouldn't somehow > accommodate this; otherwise, it seems like > it could be a problem for doing DTS inclusion > correctly. >=20 > Tim >=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?27A7F65F-C61D-424F-AD2C-65B29B49B700>