On Jan 4, 2007, at 4:15 PM, Yoder Stuart-B08248 wrote:
-----Original Message-----
From: Hollis Blanchard [mailto:hollisb@xxxxxxxxxx]
Sent: Thursday, January 04, 2007 2:12 PM
Have you tried attaching GDB to systemsim to figure out
what's going on?
I haven't used gdb w/ the simulator yet-- I need to
figure out how to do that.
I have turned on debug prints in arch/powerpc/boot_of.c.
One thing I'm puzzling over is why boot_of_alloc_init()
is marking overlapping regions of memory. Does that
make sense??
Overlapping is fine since its a bitmap we just end up setting the bit
redundantly.
The first thing we do is mark memory "outside of" the avail
properties, you can find that out from systemsim with:
systemsim % mysim of getprop [ mysim of find_device /memory@0 ]
available
0000000000000000 0000000010000000.
which says that AFA FW is concerned we can do whatever we want from 0
to 0x10000000 (which is 256M that I have mine configed with)
You should have also seen this in output:
69254: (66466): avail:
73075: (69743): 0x00, 0x010000000
I see now I should pretty that up a bit :)
[snip]
so first we mark from 0 to the bigining of "available" which is 0 also
boot_of_alloc_init: marking 0x0 - 0x0^M
This one does not make sense, is there garage that matches this in
your available property?
boot_of_alloc_init: marking 0x0 - 0x400^M
We then explicitly mark the xen image itself, because we cannot
depend on FW to claim it (tho it should).
boot_of_alloc_init: marking 0x400000 - 0x88b000^M
Then we explicitly remove the exception area (the first 4 pages)
boot_of_alloc_init: marking 0x0 - 0x3000^M
[snip]
Also, why is there a region w/ zero length?
see above
Here is all my debug output, which _does_ make sense, but does may be
from a different sim version.
67604: (64816): boot_of_mem_init: number of bytes in property 'reg' 16
69254: (66466): avail:
73075: (69743): 0x00, 0x010000000
76663: (73331): boot_of_alloc_init: marking 0x0 - 0x0
81799: (77651): boot_of_alloc_init: marking 0x400000 - 0x771000
141392: (136972): boot_of_alloc_init: marking 0x0 - 0x3000
_______________________________________________
Xen-ppc-devel mailing list
Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel
|