Pinmux with device tree

[Nicolas Pitre]

On Thu, 19 May 2011, Mitch Bradley wrote:

> On 5/19/2011 7:10 AM, Grant Likely wrote:
> > Why is it error prone?  It is probably less error prone than using
> > magic integer values.  :-)  As for time and space inefficiencies,
> > we're talking about tiny amounts of data and processors now in the GHz
> > range with GBs of memory.  The time and space required is pretty much
> > in the noise.
> 
> Ideally, the device tree is exported by the firmware, whose storage device is
> often much much smaller than the RAM size.  Since I began doing firmware,
> average RAM sizes have increased by a factor of 4000 and RAM speed has
> increased by a factor of about 1000.  In that time, boot ROM size has
> increased by a factor of about 8 and the speed, in some cases, has decreased.
> 
> During a substantial portion of the firmware startup sequence, the CPU may be
> executing in a crippled mode, with caches unavailable.
> 
> On my current project, I have to fit everything in 1 MiB of slow SPI FLASH.
> "Everything" includes microcode wads for things like the wireless module,
> extensive manufacturing and field diagnostics for every hardware device,
> crypto code and keys for boot security, drivers for on-board devices and a
> myriad of USB devices, sound clips for a startup jingle, graphics images for
> "pretty boot" and for language-neutral reporting of diagnostic results,
> unit-specific manufacturing info, filesystem and network protocol code, and a
> wireless multicast facility for mass updating of the OS onto an arbitrary
> number of units.
> 
> So, in my world, space is always an issue.

I'm guessing that in such a scenario you have the kernel stored 
somewhere else, right?  You therefore simply have to store the FDT data 
along with the kernel in that other location, and have your boot 
firmware load an additional and relatively small file.

It is very important that the DT data be updateable independently from 
the firmware, just like the kernel is.  Ideally, the DT would indeed be 
exported by the firmware, but that works only in theory.  In practice it 
_will_ contain bugs that might be visible only after kernel development 
has progressed, and therefore it is primordial to be able to update it 
easily.  Hence in practice it is best if it is not exported/generated by 
the firmware directly.


Nicolas