[XenPPC] device discovery for dart, open pic, uart etc

[Maria Butrico <butrico@xxxxxxxxxxxxx>]

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