Re: [XenPPC] XenPPC IEEE1275 binding?

[Jimi Xenidis <jimix@xxxxxxxxxxxxxx>]

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.
>                 privileged;
>                 init-domain;
>                 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.

-JX

_______________________________________________
Xen-ppc-devel mailing list
Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel