On Aug 8, 2006, at 6:42 PM, Hollis Blanchard wrote:
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.
start-info is going away, which means we'll need to add more
to replace it... something like this:
name = "xen";
version = "Xen-3.0-unstable";
Should we have a "compatible" that domain can compare against?
reg = <0 @DOMAIN_ID@ 0 0>;
This could certainly be "domain-id" and be one cell.
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.
It is 2x2 cells because:
and they dictate the size of the unit-address.
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.
domain-name = "@DOMAIN_NAME@";
shared = <@SHARED_INFO@>;
FYI, the second zero here denotes a sense code of 0 indicating
positive edge triggered interrupt
name = "console";
interrupts = <@CONSOLE_EVTCHN@ 0>;
Perhaps this should be a "unit address" and be a reg property, that
actually makes sense.
frameno = <@CONSOLE_MFN@>;
name = "store";
interrupts = <@STORE_EVTCHN@ 0>;
frameno = <@STORE_MFN@>;
this could be a "reg"/"unit address" as well.
What are all the extra 0s in there? Why do we want a reg property when
we can use separate explicitly-named properties?
Xen-ppc-devel mailing list