[XenPPC] replacing OF stub with the flattened device tree

[Hollis Blanchard <hollisb@xxxxxxxxxx>]

Some thoughts on firmware and device trees...

Upstream, somebody recently added a BUG_ON() to vsprintf(). It turned out that 
this caused a build break for us, so I had to take it out, and diverging from 
upstream in common code is bad.

The reason I had to take it out is that our Open Firmware stub (which is used 
by domU) uses some of the common code, in particular string.c, lib.c, and 
vsprintf.c. BUG_ON() calls debugtrace_dump() and printk() and other Xen 
functions which are not present in the OF stub.

We could ask Cambridge to remove the BUG_ON(), but really we are reaching into 
code we shouldn't be... at least as things are presently structured. We could 
also duplicate all the Xen code we need into arch/ppc/of_handler, and I 
started doing that, but it ended up being more work than I was looking for.

We could also get rid of our firmware entirely by switching to the new Linux 
flattened device tree standard. That would also let us standardize on the 
Linux device tree tools. (I just made a device tree with rhype's "ofdts" 
tool, but we're not distributing those things and we will need to.) In that 
case, we would simply copy a large data structure into domU, and at boot domU 
would extract everything it needs from there without trying to call out to 
firmware.

Of course, to provide a PAPR interface we will need a firmware, so we would 
still need to sort out the original issue: what utility code can we share 
between our firmware and the rest of the codebase and how? Some upstream 
discussion is probably needed.

-- 
Hollis Blanchard
IBM Linux Technology Center

_______________________________________________
Xen-ppc-devel mailing list
Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel