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

Re: [XenPPC] [PATCH 3 of 4] [PATCH] Move flat device tree construction f


On Jan 15, 2007, at 4:13 PM, Ryan Harper wrote:

* Jimi Xenidis <jimix@xxxxxxxxxxxxxx> [2007-01-15 14:53]:

On Jan 15, 2007, at 1:51 PM, Ryan Harper wrote:

* Jimi Xenidis <jimix@xxxxxxxxxxxxxx> [2007-01-11 16:53]:
[snip]
- renamed find_first_cpu to find_cpu, we don't care which cpu we find

I believe you _must_ use the the entry that has a reg property of 0.

Is that because the properties we are interested aren't guaranteed to be
present in all cpu nodes?
Well I would like it to have a reg=0 and cpu#=0
Some OF devtrees contain nodes that described shares resources (like L3, L4 caches), usually the full definition is in the lowest number of the sharers and the secondaries can simply us a property that contains the phandle of the original node.
[snip]

SEGVs are good! :)

WFM. =)
No.. seriously!
[snip]


+static int copynode(struct ft_cxt *cxt, const char *dirpath, const
char **propfilter)
+{

This is totally informational, but I think the blob/fnmatch routines
may make this code way simpler.

sure and I liked my regexp, but the concern was what sort of libc
functions would be available in Xen when we implement copynode down
there for dom0 devtree construction.

this is a good point, however dom0 will copy everything.
[snip]

+int make_devtree(
[snip]
Any ideas what this reservation is for? is it for the flat-devtree
itself?

Nope.

+    /* root.reserve(0x1000000, 0x1000) */
+    val[0] = cpu_to_be64((u64) 0x1000000);
+    val[1] = cpu_to_be64((u64) 0x1000);
+    ft_add_rsvmap(root, val[0], val[1]);

Hollis?!


+

this value is keyed off of rma_bytes

No idea, just duping reservations that the python code made.  Is there
some place I should be getting these values from?
Sure.. you calculate rma_bytes below when you fill in the /memory@0 stuff in.
that is what you are missing below.
[snip]

+    /* xen = root.addnode('xen') */
+    ft_begin_node(root, "xen");

the 0x3ffc00 value is offset from rma_bytes
+
+    /* xen.addprop('start-info', long(0x3ffc000), long(0x1000)) */
+    val[0] = cpu_to_be64((u64) 0x3ffc000);
+    val[1] = cpu_to_be64((u64) 0x1000);
+    ft_prop(root, "start-info", val, sizeof(val));

What am I missing here?

+
+    /* memory@1 is all the rest */
+    if (remaining > 0)
+    {

this really should be "memory@<rma_bytes>"

+        /* mem = root.addnode('memory@1') */
+        ft_begin_node(root, "memory@1");
+

OK.

--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253   T/L: 678-9253
ryanh@xxxxxxxxxx


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

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