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/
Home Products Support Community News


Re: [XenPPC] XenPPC IEEE1275 binding?

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 properties
to replace it... something like this:
        xen {
                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:
  /#address-cells: 2
  /#size-cells: 2

and they dictate the size of the unit-address.

                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.

                console {
                        name = "console";
                        interrupts = <@CONSOLE_EVTCHN@ 0>;
FYI, the second zero here denotes a sense code of 0 indicating positive edge triggered interrupt

                        frameno = <@CONSOLE_MFN@>;
Perhaps this should be a "unit address" and be a reg property, that actually makes sense.

                store {
                        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?
see above.


Xen-ppc-devel mailing list

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