building RaspPi Images

[Warner Losh]

On Feb 11, 2013, at 11:27 PM, Tim Kientzle wrote:

> On Feb 11, 2013, at 9:42 AM, Ian Lepore wrote:
> 
>> … I still find it much more cumbersome to work with
>> than the old hints system. The very fact that you need
>> a special compiler to change the fdt data is part of that.
> 
> This is my single biggest complaint about fdt as well.

And the better solution is?  We have nothing that's better...

>>> 2) We're still debating the role of the FDT vis a vis
>>> end user customization.  Personally, I would like
>>> to find some more dynamic approach to handling
>>> pinmux at runtime.  (E.g., if you want to use a pin
>>> for gpio, you do this:
>>>  $ gpioctl 1 7 out   # Set gpio 1 7 for output, including pinmux change
>>>  $ gpioctl 1 7 on
>>> Similarly, I think that enabling uart2 should automatically
>>> adjust the pinmux appropriately.
>> 
>> I whole-heartedly agree with that last sentence, but it's about a
>> zillion miles from where our code is now.  I'm not even sure it's fully
>> possible, it just seems like a nice generic ideal "I asked for a uart,
>> so the uart driver should enable power, enable clocks, and assign pins
>> to make that happen."
> 
> 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.

The tables should come in from the FDT. I know that's a pain, but it makes it so that when the next rev of the silicon comes out that has slightly different swizzled pins easier to integrate.

> 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.

This is the approach that's favored by those driving the FDT definitions. I've seen it work well in the Atmel case where they have the same basic core that they remix with different devices to produce the different SoCs optimized for different market segments. They have gotten tot he point where a new SoC with old IP just needs a new FDT to be supported by the kernel.

> 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.)

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

>> The problem crops up when "assign pins" has
>> several sets of pins to choose from for a given device, and I know at
>> least the Atmel SoCs do this a lot.
> 
> 
> Tim
> 
> _______________________________________________
> freebsd-arm at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"