building RaspPi Images

Tim Kientzle kientzle at freebsd.org
Thu Feb 14 05:35:50 UTC 2013


On Feb 12, 2013, at 10:17 PM, Warner Losh wrote:

> 
> On Feb 12, 2013, at 10:30 PM, Tim Kientzle wrote:
> 
>> On Feb 12, 2013, at 10:45 AM, Warner Losh wrote:
>> 
>>> 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 would be interested in seeing those early patches.
>> 
>> I agree that it would be best to bundle pinmux info
>> with the related device in the FDT.  Seeing some
>> prior art would help a lot.
> 
> They were posted to the device-tree mailing list a while ago, but I don't have a pointer to the archives :(...  They were from somebody at Atmel.com, so if you find it, it will be easy to search  for.
> 
> Warner
> 


I finally found the thread I think you're referring to, from
January 2012.  This looks like an interesting post
because it gives some concrete ideas for what the
device tree might look like (and the author gives
some thoughtful critiques that I'll have to think about
further):

https://lists.ozlabs.org/pipermail/devicetree-discuss/2012-January/012015.html

Skimming some other discussions, it looks like the general
idea a lot of folks are considering is:

Having a pinmux node for whatever hardware controls
pinmuxing.  For the TI chip I'm working with, that would be
the scm (System Control Module).

Within that node, have a collection of named pinmux settings.
E.g., pmx_ethernet01 or pmx_uart02

Within other hardware nodes, refer to those named
settings, so you might have (very roughly; I still don't
understand FDT syntax):

     uart02: uart at 40800000 {
         compatible = "….";
         ….
         pinmux = "pmx_uart02";
         pinmuxc = "scm01";
     }

(That is, the uart02 should use scm01 to enable
pmx_uart02 pinmux settings.)  In particular, for
hardware with multiple states, you could refer
to multiple pinmux settings (e.g., an idle setting
that tristated the outputs vs. an active setting
that powered them).

A lot of the debate seems to revolve around the details
of whether the pinmux details should be lists of hardware
numeric codes (advantage:  eliminates tables from
the pinmux driver source and eliminates lots of text
from the DTS) or should be more verbose textual
descriptions (advantage:  easier to read and update).

Is this generally what you had in mind?

Tim



More information about the freebsd-arm mailing list