I remember seeing some mention of it, but I don't think we currently
have an IEEE1275 binding describing the contents of the /xen node.
As you're currently both the only producer and the only consumer of
this node, you don't need a real binding yet. But, the standard
properties you have should be correct; and you should make your
specific properties as sane as possible as soon as possible.
start-info is going away, which means we'll need to add more
properties
to replace it... something like this:
xen {
name = "xen";
version = "Xen-3.0-unstable";
Call this property "xen-version" instead?
Should we have a "compatible" that domain can compare against?
Yes, but you also should have a "device_type".
reg = <0 @DOMAIN_ID@ 0 0>;
This could certainly be "domain-id" and be one cell.
If it's a 32-bit number always -- if not, make it two cells.
I used "reg" because I mistakenly thought is was a mandatory
property and we needed a "unit-id" which makes no sense as you
point out below.
If you only ever have one "xen" node, you don't need the "reg".
It is 2x2 cells because:
/#address-cells: 2
/#size-cells: 2
and they dictate the size of the unit-address.
Only #address-cells actually; but "reg" contains a size as well.
domain-name = "@DOMAIN_NAME@";
shared = <@SHARED_INFO@>;
This, console and store, and all addresses should be expressed in
bytes and are domain-physical not MFNs so we should label them
correctly. They also need to match /#address-cells and should
prolly have a size.
privileged;
init-domain;
I have no idea what these last three props describe; please
explain? (And perhaps make the names more specific).
console {
name = "console";
interrupts = <@CONSOLE_EVTCHN@ 0>;
FYI, the second zero here denotes a sense code of 0 indicating
positive edge triggered interrupt
Well no. A node's "interrupts" property's semantics depends
on the interrupt-controller it points to. You don't point to
anything yet.
Are those interrupts "virtual" interrupts? In that case, you
want to have a "xen-interrupt-controller" node; or you could
even just put an "interrupt-controller" in the main "xen" node.
All virtual irqs will have the same sense/value, so you can do
without that second cell in the interrupt specifiers completely.
frameno = <@CONSOLE_MFN@>;
Perhaps this should be a "unit address" and be a reg property, that
actually makes sense.
Can't comment; what is this?
};
store {
name = "store";
interrupts = <@STORE_EVTCHN@ 0>;
frameno = <@STORE_MFN@>;
this could be a "reg"/"unit address" as well.
You need #address-cells and #size-cells in the parent node for
that, btw.
Segher
_______________________________________________
Xen-ppc-devel mailing list
Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel
| 
Home