[PATCH 2/10] sbc8560: Add v1 device tree source for Wind River SBC8560 board
Paul Gortmaker
paul.gortmaker at windriver.com
Wed Feb 6 03:53:09 EST 2008
In message: Re: [PATCH 2/10] sbc8560: Add v1 device tree source for Wind River SBC8560 board
on 01/02/2008 David Gibson wrote:
> On Thu, Jan 24, 2008 at 06:41:24PM -0500, Paul Gortmaker wrote:
> > This adds a v1 device tree source for the Wind River SBC8560 board. The
> > biggest difference between this and the MPC8560ADS reference platform
> > dts is the use of an external 16550 compatible UART instead of the CPM2.
> >
> > Signed-off-by: Paul Gortmaker <paul.gortmaker at windriver.com>
>
> [snip]
> > +/dts-v1/;
> > +
> > +/ {
> > + model = "SBC8560";
> > + compatible = "SBC8560";
>
> This is not the conventional format for board-level compatible
> entries, which should generally be "vendor,model" and all in lower
> case.
No problem - I can change to "sbc8560" and "wrs,sbc8560" on this board
and others.
>
> [snip]
> > + enet0: ethernet at 24000 {
> > + cell-index = <0>;
> > + device_type = "network";
> > + model = "TSEC";
> > + compatible = "gianfar";
>
> This looks like the old dodgy gianfar binding, and needs updating
> (mdio node will probably also need changes).
I thought I'd merged in all Kumar's updates to the gianfar nodes at that
point in time, but I'll go back and re-check.
>
> [snip]
> > + localbus at ff705000 {
> > + compatible = "fsl,mpc8560-localbus";
> > + #address-cells = <2>;
> > + #size-cells = <1>;
> > + reg = <0xff705000 0x100>; // BRx, ORx, etc.
> > +
> > + ranges = <
> > + 0x0 0x0 0xff800000 0x0800000 // 8MB boot flash
> > + 0x1 0x0 0xe4000000 0x4000000 // 64MB flash
> > + 0x3 0x0 0x20000000 0x4000000 // 64MB SDRAM
> > + 0x4 0x0 0x24000000 0x4000000 // 64MB SDRAM
> > + 0x5 0x0 0xfc000000 0x0c00000 // EPLD
> > + 0x6 0x0 0xe0000000 0x4000000 // 64MB flash
> > + 0x7 0x0 0x80000000 0x0200000 // ATM1,2
> > + >;
> > +
> > + epld at 5,0 {
>
> I'm not entirely convinced on this two-level representation. I think
> the FSL people need to get together and define a binding (or set of
> bindings) for their various chipselect style external bus bridges.
I'd tried to capture what you'd outlined for the localbus node, and the
epld child seemed like a natural extension of that. I suspect that a
lot of boards would just have the localbus node and not the extra node
that fans things out a step further. There wasn't really any similar
precedent for that to work off of that I noticed. I'm agreeable to
change or restructuring if Kumar recommends re-using some standard as
set by the 4xx/EBC.
Paul.
>
> > + compatible = "wrs,epld-localbus";
> > + #address-cells = <2>;
> > + #size-cells = <1>;
> > + reg = <0x5 0x0 0xc00000>;
> > + ranges = <
> > + 0x0 0x0 0x5 0x000000 0x1fff // LED disp.
> > + 0x1 0x0 0x5 0x100000 0x1fff // switches
> > + 0x2 0x0 0x5 0x200000 0x1fff // ID reg.
> > + 0x3 0x0 0x5 0x300000 0x1fff // status reg.
> > + 0x4 0x0 0x5 0x400000 0x1fff // reset reg.
> > + 0x5 0x0 0x5 0x500000 0x1fff // Wind port
> > + 0x7 0x0 0x5 0x700000 0x1fff // UART #1
> > + 0x8 0x0 0x5 0x800000 0x1fff // UART #2
> > + 0x9 0x0 0x5 0x900000 0x1fff // RTC
> > + 0xb 0x0 0x5 0xb00000 0x1fff // EEPROM
> > + >;
>
> --
> David Gibson | I'll have my music baroque, and my code
> david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
> | _way_ _around_!
> http://www.ozlabs.org/~dgibson
More information about the Linuxppc-dev
mailing list