Request review of device tree documentation

[Nicolas Pitre]

On Mon, 14 Jun 2010, Grant Likely wrote:

> The discussion *started* with a request to review this document:
> 
> http://devicetree.org/Device_Tree_Usage
> 
> Which is in early draft form (which is why the arm list wasn't
> initially cc'd. I was soliciting feedback from the current device tree
> users.  A second request for review will go out after rework is done
> to the document).

I'm therefore assuming I can safely ignore it for now then.

> In one of the reply threads Mitch stated that he is working on an ARM
> project that will use Open Firmware as the bootloader, and that he'd
> like the ability to keep OFW available after the kernel is booted
> which is something currently done on both Sparc and OLPC x86.  Mitch
> will correct me if I'm made any misrepresentations here.

OK... but what does "keep OFW available" mean? And what for?

> Conceptually I'm not opposed to allowing OFW to stay resident
> providing that it does not impose new requirements on the boot
> interface (the kernel would still need to be handed the flattened
> representation of the device tree) and that the code to do so is well
> contained in the kernel.  The devil is of course in the details on how
> feasible it is to accomplish.

Well, you'd need to tell the kernel about what memory area not to touch 
(given that memory is not in some area the kernel will touch anyway when 
it is in its early boot stage and still not smart enough to avoid it).

Then you'll need special code to perform those steps RMK already 
mentioned.  This is a bit like the low-level code for suspend/resume 
support is doing.  This is of course if I'm still guessing right about 
the whole purpose of this.

> ARM machines with Open Firmware are
> going to be the minority, so I'm not interested in doing anything
> special or out of the ordinary specifically to support it.

This certainly doesn't have to involve the core kernel.  A special 
module may even be sufficient to keep the complexity localized.  Just 
like low-level suspend/resume code is per SOC already anyway.

But again, what for?


Nicolas