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 <[EMAIL PROTECTED]> > > [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: [EMAIL PROTECTED] { > > + 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] > > + [EMAIL PROTECTED] { > > + 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 > > + >; > > + > > + [EMAIL PROTECTED],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 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev