Date: Tue, 12 Feb 2013 11:45:32 -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: <5F763292-2EA4-426A-B84A-8DE533BA6308@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? Yes. http://lxr.linux.no/linux+v3.7.7/arch/arm/boot/dts/at91sam9n12ek.dts is = the dts for the Atmel AT91SAM9N12-EK evaluation board. It just includes = the base Atmel AT91SAM9N dts at the top, then adds its model string, = boot args, memory size, clocks and devices (by changing their status to = "okay". It also wires up different GPIOs to the linux-speciifc triggers = like sd card or nand activity, and finally says that certain GPIO is = connected to the wakeup key. But it doesn't have all the pin group stuff in yet, so I'll have to = chase that down and see what happened to that part of the early patches = I was reviewing... > 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.) This I'm less sure about. Warner > I wonder if simple bus shouldn't somehow > accommodate this; otherwise, it seems like > it could be a problem for doing DTS inclusion > correctly.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5F763292-2EA4-426A-B84A-8DE533BA6308>