Pinmux with device tree

[Mitch Bradley]

On 5/19/2011 10:36 AM, Nicolas Pitre wrote:
> 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.

There is no stored FDT.  The firmware generates the device tree 
dynamically from a combination of static information and dynamic probing.

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


In our world it works in practice.  We control the hardware, firmware, 
and OS releases.  In many cases, a firmware update is less expensive 
than an OS release by several orders of magnitude.


>
>
> Nicolas
>