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] device discovery for dart, open pic, uart etc

To: xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
Subject: [XenPPC] device discovery for dart, open pic, uart etc
From: Maria Butrico <butrico@xxxxxxxxxxxxx>
Date: Fri, 12 May 2006 16:04:19 -0400
Delivery-date: Fri, 12 May 2006 13:05:30 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
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>
Reply-to: butrico@xxxxxxxxxxxxxx
Sender: xen-ppc-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 1.5.0.2 (Windows/20060308)
The latest patch I sent, although it makes progress in booting on g5 hardware has many structural flaws. One problem is that boot_of.c is growing with code that, although uses information from the OF tree, does not properly belong there. For example, the open mpic allocation, optionally needs a flag to indicate big endian. The definition of this flag is information pertinent to the mpic implementation (mpic.c and mpic.h) and properly boot_of.c should not need to include mpic.h. The current plan is to shift the discovery of open pic, dart, memory later in the boot process and to use the OFD tree whose address we plan on making global. Thus there will be a start_mpic.c (we cannot use mpic.c, since we already have that) where the code currently in external.c that allocates mpic is and this code will find the mpic device and its address with the global OFD tree. Since we are shifting these items later, we have no need to discover the hardware type in boot_of either and we are also planning to do so with OFD interfaces later. The serial port discovery code will remain pretty much unchanged (aside from some minor fixes) and will remain in boot_of.c.

There is a bit of ugliness in this code related to finding the device address. I tried to rationalize this by looking carefully over the documentation, but I ran into problems. The ugliness does not go away by moving to OFD and other devices, for example mpic, will have similar code. The ugliness relates to how to map the properties 'reg' and 'ranges'. These should be driven by the values of the properties #address-cells and #size-cells, in specific locations. While the value for #size-cells tracks, we have issues with #address-sizes (it's not what I would expect). In addition Jimi and I have a bit of disagreement over the location of the property #size-cells. Jimi believes that the absence of this property should indicate that one is to look further up the tree, whereas I think that the absence of this property should indicate that it reverts to its default value of 1. There is additional complication that for the property 'reg' the #size-cells of interest is one slot up the tree and for the property 'ranges' it is not.

As I mentioned already, in practice on the machine where I have tested the #size-cells is where we expect it to be and its value tracks what we see in the related other properties. Jimi and I disagree about what to do should this property not be there, a case that we have not encountered in practice. (I make this statement with a degree of uncertainly. I have not booted on maple hardware, for example.)


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

<Prev in Thread] Current Thread [Next in Thread>