Request review of device tree documentation

[Mitch Bradley]

Grant Likely wrote:
> On Sat, Jun 12, 2010 at 4:52 PM, Benjamin Herrenschmidt
> <benh at kernel.crashing.org> wrote:
>   
>> On Sat, 2010-06-12 at 06:30 -1000, Mitch Bradley wrote:
>>
>>     
>>> I'm certainly going to try keeping OFW alive.  On the x86 OLPC machines,
>>> the ability to
>>> dive into OFW via a SysRq key combo was very helpful for debugging some
>>> difficult
>>> problems.  The team has asked me to support the feature on ARM.
>>>       
>> Oh well, if you can and can convince the ARM kernel folks to do the
>> necessary changes ... :-)
>>     
>
> What is needed to keep OFW alive?  I've got no problem with doing so
> if it isn't invasive, and as long as the same boot entry interface can
> be used.
>   

Minimally, OFW needs to own some memory that the kernel won't steal.  
OFW on ARM
is position-independent, so it can be tucked up at the top of memory 
fairly easily.

To call back into OFW, the virtual mapping for that memory needs to be 
reestablished.
Or perhaps the MMU and caches can be turned off for the duration of the 
callback.
I don't have the details of ARM MMUs and caches reloaded into my head 
yet.  Maybe next week...

Also, for debugging, OFW typically needs access to a UART.  If the OS is 
using the UART,
it's often possible for OFW to use it just by turning off interrupts and 
polling the UART.

>   
>> One thing tho, you will only benefit from the whole infrastructure we
>> have created accross platforms in linux if the device-tree is "sucked"
>> into linux at boot. IE. Linux will not do constant accesses to OF for
>> the DT. Even sparc converted to that now.
>>
>> That means that if your device-tree has a dynamic nature, we'll need to
>> come up with a way to inform the kernel of changes in it so it can
>> update it's copy accordingly.
>>     
>
> What is the use-case for having a dynamic device tree? 

The use case for a dynamic device tree is not compelling.

In SPARC / Solaris land, Open Boot managed the non-volatile 
configuration variables, which the OS could access and modify 
dynamically as properties in /options.  The OS didn't have to know the 
storage layout nor the hardware details of the storage device.  
Convenient, but not hugely important.

>  I can see
> keeping OFW alive being useful for some debug facilities, but once the
> kernel has started, I'm really not interested in relying on firmware
> to manage the hardware. 

That's sort of a self-fulfilling prophecy.  If the OS doesn't trust the 
firmware, there is no pressure for the firmware to "get it right".

In PC land, the current status quo is that Windows depends on ACPI so 
heavily that BIOS vendors pretty much have to get that part of the 
puzzle right.  Microsoft did a thorough job of creating certification 
tests and enforcing their use.  I'm not praising ACPI, just pointing out 
the dynamics that result from assignment of responsibility.

That said, I'm not interested in pushing the issue.  It's okay with me 
if the device tree is static as far as the kernel is concerned, and 
callbacks to OFW are only used for debugging purposes.

>  (but then again it's no secret that I'm
> suspicious of anything that depends on runtime interaction with
> firmware).
>
> g.
>
>