On Sun, 2010-06-13 at 23:13 -0600, Grant Likely wrote: > > We use that to suck the device-tree, which we flatten, and then > re-enter > > the kernel with the "common" entry interface. > > I don't think I want to do the same on ARM. I'd rather have the > prom_init stuff in a boot wrapper, or have OFW itself generate the > flat representation before booting the kernel.
But then it's no longer OF. IE. A compliant OF implementation provides a client interface API :-) This is going to be especially important if Mitch wants to keep OF alive. I suppose it could be done via a wrapper like prom_init, which flattens the tree, and sticks somewhere in a property the address of the OF client interface callback though it's a tad awkward. If well defined, I suppose Mitch might even be able to make his OF natively boot kernels that way but that's of course up to him. > I'm trying to constrain the number of things that could go wrong by > defining only one way for getting the device tree data into the > kernel. I understand, and the flattened method is the most versatile, I'm just pointing out the situation here :-) > Right. We don't need to use OFW/RTAS to handle this use case. Definitely not. It will depend on whatever hypervisor interface is implemented in a given environment. Though I do like the idea of passing precompiled bits of .dtb around for hotplug :-) We could make that a standard way of KVM to do things in embedded space. Cheers, Ben. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev