Subject: RE: [PATCH 7/7] [POWERPC] Xilinx: Update booting-without-of.

From: "Stephen Neuendorffer" <[email-masked]>
Date: Mon, 17 Dec 2007 16:22:56 -0800

I've updated the generator based on the below feedback.  I'll also send
around the updated patch for this section briefly.  Comments below.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Grant Likely
> Sent: Monday, December 17, 2007 7:20 AM
> To: Stephen Neuendorffer
> Cc: [email-masked]; [email-masked]; linuxppc-
> [email-masked]; David Gibson
> Subject: Re: [PATCH 7/7] [POWERPC] Xilinx: Update booting-without-of.
>=20
> > -       (name)@(base-address) {
> > +       (name): (ip-core-name)@(base-address) {
>=20
> (name): (generic-name)@(base-address) {

In most cases it now does this.  In the default case for ip which is not
recognized, it falls back to the ip-core-name.

> > -       opb_ps2_dual_ref_0@a9000000 {
> > +       opb_ps2_dual_ref_0: opb-ps2-dual-ref@a9000000 {
> > +               #address-cells =3D <1>;
> > +               #size-cells =3D <1>;
> > +               compatible =3D "xlnx,compound";
> >                 ranges =3D <0 a9000000 2000>;
> >                 // If this device had extra parameters, then they
would
> >                 // go here.
> > -               ps2@0 {
> > +               opb-ps2-dual-ref@0 {
>=20
> According to the generic names recommendation, this should be either
> "keyboard@0" or "mouse@0", but of course the two interfaces are
> identical and EDK doesn't have any information about how they are
> used.  Perhaps the node name should be: "ps2@0".  David, thoughts?

I don't think keyboard or mouse really makes sense here.  Went with ps2.

> > -       plb-v34-0 {
> > +       plb_v34 {
>=20
> Steve, when I wrote this I was lazy and I didn't add the bus address.
> However, if we don't have the base address I think we'll end up with
> name collisions (especially in the MPMC case).  So, based on generic
> names convention, this should probably simply be "plb@<baseaddr>".

I wondered at one point if this would be a problem... in any event, you
now get the baseaddress.

> >                 #address-cells =3D <1>;
> >                 #size-cells =3D <1>;
> > +               compatible =3D "xlnx,plb-v34-1.02.a";
> >                 device_type =3D "ibm,plb";
> >                 ranges; // 1:1 translation
> >
> > -               plb-bram-if-cntrl-0@ffff0000 {
> > +               plb_bram_if_cntrl_0: plb-bram-if-cntrl@ffff0000 {
>=20
> Node name should probably just be "bram@ffff0000" here.

What actually gets generated is a memory node at the toplevel, which is
currently suppressed, since it appears that having disjoint memory
locations doesn't work.  If you have more than one 'real' memory
controller, such as an plb_emc connected to flash, then you currently
get the warning:

"Warning!: More than one memory found.  Note that most platforms don't
support non-contiguous memory maps!"

So, there is some divergence here, but I'm not too concerned about it
since the way that such memory might get used is still up for
discussion.

Also note that memory nodes which are not at the toplevel don't appear
to be detected.  Is this by intention or omission?

Obviously there is room for improvement here.  Having a some way to
leverage brams, in particular the dummy bram that you have to have at
high memory in order to get the ppc to boot would be nice!

Steve