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

[Stephen Neuendorffer]

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: glikely at secretlab.ca [mailto:glikely at secretlab.ca] On Behalf Of
> Grant Likely
> Sent: Monday, December 17, 2007 7:20 AM
> To: Stephen Neuendorffer
> Cc: simekm2 at fel.cvut.cz; jwilliams at itee.uq.edu.au; linuxppc-
> dev at ozlabs.org; David Gibson
> Subject: Re: [PATCH 7/7] [POWERPC] Xilinx: Update booting-without-of.
> 
> > -       (name)@(base-address) {
> > +       (name): (ip-core-name)@(base-address) {
> 
> (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 at a9000000 {
> > +       opb_ps2_dual_ref_0: opb-ps2-dual-ref at a9000000 {
> > +               #address-cells = <1>;
> > +               #size-cells = <1>;
> > +               compatible = "xlnx,compound";
> >                 ranges = <0 a9000000 2000>;
> >                 // If this device had extra parameters, then they
would
> >                 // go here.
> > -               ps2 at 0 {
> > +               opb-ps2-dual-ref at 0 {
> 
> According to the generic names recommendation, this should be either
> "keyboard at 0" or "mouse at 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 at 0".  David, thoughts?

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

> > -       plb-v34-0 {
> > +       plb_v34 {
> 
> 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 = <1>;
> >                 #size-cells = <1>;
> > +               compatible = "xlnx,plb-v34-1.02.a";
> >                 device_type = "ibm,plb";
> >                 ranges; // 1:1 translation
> >
> > -               plb-bram-if-cntrl-0 at ffff0000 {
> > +               plb_bram_if_cntrl_0: plb-bram-if-cntrl at ffff0000 {
> 
> Node name should probably just be "bram at 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