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