WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ppc-devel

[XenPPC] replacing OF stub with the flattened device tree

To: xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
Subject: [XenPPC] replacing OF stub with the flattened device tree
From: Hollis Blanchard <hollisb@xxxxxxxxxx>
Date: Wed, 8 Mar 2006 17:39:15 -0600
Delivery-date: Wed, 08 Mar 2006 23:40:08 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-ppc-devel-request@lists.xensource.com?subject=help>
List-id: Xen PPC development <xen-ppc-devel.lists.xensource.com>
List-post: <mailto:xen-ppc-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ppc-devel>, <mailto:xen-ppc-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ppc-devel>, <mailto:xen-ppc-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: IBM Linux Technology Center
Sender: xen-ppc-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.8.3
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

<Prev in Thread] Current Thread [Next in Thread>
  • [XenPPC] replacing OF stub with the flattened device tree, Hollis Blanchard <=