Skip site navigation (1)Skip section navigation (2)
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>