building RaspPi Images

[Warner Losh]

On Feb 12, 2013, at 10:15 AM, Tim Kientzle wrote:

> 
> On Feb 12, 2013, at 8:40 AM, Warner Losh wrote:
> 
>> 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:
>> 
>> include "GENERIC"
>> nodevice foo
>> device bar
>> option FRED
>> nooption WILMA
>> 
>> FDT is powerful enough to cope with those things today, with the version we have in the tree.
> 
> Warner,
> 
> 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.
> 
> 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.)
> 
> I wonder if simple bus shouldn't somehow
> accommodate this; otherwise, it seems like
> it could be a problem for doing DTS inclusion
> correctly.
> 
> Tim
>