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?

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.


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.


Xen-ppc-devel mailing list

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