Re: [PATCH 2/10] sbc8560: Add v1 device tree source for Wind River SBC8560 board
On Feb 4, 2008, at 8:40 PM, David Gibson wrote:
On Fri, Feb 01, 2008 at 08:46:32AM -0600, Kumar Gala wrote:
On Feb 1, 2008, at 1:54 AM, David Gibson wrote:
On Thu, Jan 24, 2008 at 06:41:24PM -0500, Paul Gortmaker wrote:
[snip]
+ [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.
It seems reasonable if you had a FPGA off of the localbus to have a
two level representation. One for the localbus controller on the FSL
part and the child to describe the FPGA.
What are you expecting beyond what we have today? I guess I'm asking
what's missing from the localbus nodes we have?
Sorry, I was probably misleading. All I really meant is that I don't
know enough about these FSL bus bridge arrangements to assess if this
representation is the most sensible one. I'm presuming that this
chipselect bridge unit is a more-or-less standard ASIC appearing on
lots of the FSL chips, so it would be nice to have a standard binding
for them, as we do for the roughly-equivalent EBC bridge on 4xx.
Is there a writeup for EBC? I'll take a look at it and see if it
makes senses for the freescale 'localbus'.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/10] sbc8560: Add v1 device tree source for Wind River SBC8560 board
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 0xff80 0x080// 8MB boot flash
+ 0x1 0x0 0xe400 0x400// 64MB flash
+ 0x3 0x0 0x2000 0x400// 64MB SDRAM
+ 0x4 0x0 0x2400 0x400// 64MB SDRAM
+ 0x5 0x0 0xfc00 0x0c0// EPLD
+ 0x6 0x0 0xe000 0x400// 64MB flash
+ 0x7 0x0 0x8000 0x020// 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 0xc0;
+ ranges =
+ 0x0 0x0 0x5 0x00 0x1fff // LED disp.
+ 0x1 0x0 0x5 0x10 0x1fff // switches
+ 0x2 0x0 0x5 0x20 0x1fff // ID reg.
+ 0x3 0x0 0x5 0x30 0x1fff // status reg.
+ 0x4 0x0 0x5 0x40 0x1fff // reset reg.
+ 0x5 0x0 0x5 0x50 0x1fff // Wind port
+ 0x7 0x0 0x5 0x70 0x1fff // UART #1
+ 0x8 0x0 0x5 0x80 0x1fff // UART #2
+ 0x9 0x0 0x5 0x90 0x1fff // RTC
+ 0xb 0x0 0x5 0xb0 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
Re: [PATCH 2/10] sbc8560: Add v1 device tree source for Wind River SBC8560 board
On Tue, Feb 05, 2008 at 09:44:23AM -0600, Kumar Gala wrote:
On Feb 4, 2008, at 8:40 PM, David Gibson wrote:
On Fri, Feb 01, 2008 at 08:46:32AM -0600, Kumar Gala wrote:
On Feb 1, 2008, at 1:54 AM, David Gibson wrote:
On Thu, Jan 24, 2008 at 06:41:24PM -0500, Paul Gortmaker wrote:
[snip]
+[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.
It seems reasonable if you had a FPGA off of the localbus to have a
two level representation. One for the localbus controller on the FSL
part and the child to describe the FPGA.
What are you expecting beyond what we have today? I guess I'm asking
what's missing from the localbus nodes we have?
Sorry, I was probably misleading. All I really meant is that I don't
know enough about these FSL bus bridge arrangements to assess if this
representation is the most sensible one. I'm presuming that this
chipselect bridge unit is a more-or-less standard ASIC appearing on
lots of the FSL chips, so it would be nice to have a standard binding
for them, as we do for the roughly-equivalent EBC bridge on 4xx.
Is there a writeup for EBC? I'll take a look at it and see if it
makes senses for the freescale 'localbus'.
Uh... not as such. I'll try to write it up and add a binding to
b-w-o.txt next week when I'm back at work for real. I wouldn't expect
it to be usable as is for the Freescale localbus, but it should be
pretty similar in spirit.
--
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
Re: [PATCH 2/10] sbc8560: Add v1 device tree source for Wind River SBC8560 board
On Fri, Feb 01, 2008 at 08:46:32AM -0600, Kumar Gala wrote:
On Feb 1, 2008, at 1:54 AM, David Gibson wrote:
On Thu, Jan 24, 2008 at 06:41:24PM -0500, Paul Gortmaker wrote:
[snip]
+ [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.
It seems reasonable if you had a FPGA off of the localbus to have a
two level representation. One for the localbus controller on the FSL
part and the child to describe the FPGA.
What are you expecting beyond what we have today? I guess I'm asking
what's missing from the localbus nodes we have?
Sorry, I was probably misleading. All I really meant is that I don't
know enough about these FSL bus bridge arrangements to assess if this
representation is the most sensible one. I'm presuming that this
chipselect bridge unit is a more-or-less standard ASIC appearing on
lots of the FSL chips, so it would be nice to have a standard binding
for them, as we do for the roughly-equivalent EBC bridge on 4xx.
--
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
Re: [PATCH 2/10] sbc8560: Add v1 device tree source for Wind River SBC8560 board
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.
[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).
[snip]
+ [EMAIL PROTECTED] {
+ compatible = fsl,mpc8560-localbus;
+ #address-cells = 2;
+ #size-cells = 1;
+ reg = 0xff705000 0x100; // BRx, ORx, etc.
+
+ ranges =
+ 0x0 0x0 0xff80 0x080// 8MB boot flash
+ 0x1 0x0 0xe400 0x400// 64MB flash
+ 0x3 0x0 0x2000 0x400// 64MB SDRAM
+ 0x4 0x0 0x2400 0x400// 64MB SDRAM
+ 0x5 0x0 0xfc00 0x0c0// EPLD
+ 0x6 0x0 0xe000 0x400// 64MB flash
+ 0x7 0x0 0x8000 0x020// 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.
+ compatible = wrs,epld-localbus;
+ #address-cells = 2;
+ #size-cells = 1;
+ reg = 0x5 0x0 0xc0;
+ ranges =
+ 0x0 0x0 0x5 0x00 0x1fff // LED disp.
+ 0x1 0x0 0x5 0x10 0x1fff // switches
+ 0x2 0x0 0x5 0x20 0x1fff // ID reg.
+ 0x3 0x0 0x5 0x30 0x1fff // status reg.
+ 0x4 0x0 0x5 0x40 0x1fff // reset reg.
+ 0x5 0x0 0x5 0x50 0x1fff // Wind port
+ 0x7 0x0 0x5 0x70 0x1fff // UART #1
+ 0x8 0x0 0x5 0x80 0x1fff // UART #2
+ 0x9 0x0 0x5 0x90 0x1fff // RTC
+ 0xb 0x0 0x5 0xb0 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
[PATCH 2/10] sbc8560: Add v1 device tree source for Wind River SBC8560 board
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]
---
arch/powerpc/boot/dts/sbc8560.dts | 330 +
1 files changed, 330 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/sbc8560.dts
b/arch/powerpc/boot/dts/sbc8560.dts
new file mode 100644
index 000..0476802
--- /dev/null
+++ b/arch/powerpc/boot/dts/sbc8560.dts
@@ -0,0 +1,330 @@
+/*
+ * SBC8560 Device Tree Source
+ *
+ * Copyright 2007 Wind River Systems Inc.
+ *
+ * Paul Gortmaker (see MAINTAINERS for contact information)
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/dts-v1/;
+
+/ {
+ model = SBC8560;
+ compatible = SBC8560;
+ #address-cells = 1;
+ #size-cells = 1;
+
+ aliases {
+ ethernet0 = enet0;
+ ethernet1 = enet1;
+ ethernet2 = enet2;
+ ethernet3 = enet3;
+ serial0 = serial0;
+ serial1 = serial1;
+ pci0 = pci0;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,[EMAIL PROTECTED] {
+ device_type = cpu;
+ reg = 0;
+ d-cache-line-size = 0x20; // 32 bytes
+ i-cache-line-size = 0x20; // 32 bytes
+ d-cache-size = 0x8000;// L1, 32K
+ i-cache-size = 0x8000;// L1, 32K
+ timebase-frequency = 0; // From uboot
+ bus-frequency = 0;
+ clock-frequency = 0;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x 0x2000;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 1;
+ device_type = soc;
+ ranges = 0x0 0xff70 0x0010;
+ reg = 0xff70 0x0010;
+ clock-frequency = 0;
+
+ [EMAIL PROTECTED] {
+ compatible = fsl,8560-memory-controller;
+ reg = 0x2000 0x1000;
+ interrupt-parent = mpic;
+ interrupts = 0x12 0x2;
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = fsl,8560-l2-cache-controller;
+ reg = 0x2 0x1000;
+ cache-line-size = 0x20; // 32 bytes
+ cache-size = 0x4; // L2, 256K
+ interrupt-parent = mpic;
+ interrupts = 0x10 0x2;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
+ cell-index = 0;
+ compatible = fsl-i2c;
+ reg = 0x3000 0x100;
+ interrupts = 0x2b 0x2;
+ interrupt-parent = mpic;
+ dfsrr;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
+ cell-index = 1;
+ compatible = fsl-i2c;
+ reg = 0x3100 0x100;
+ interrupts = 0x2b 0x2;
+ interrupt-parent = mpic;
+ dfsrr;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = fsl,gianfar-mdio;
+ reg = 0x24520 0x20;
+ phy0: [EMAIL PROTECTED] {
+ interrupt-parent = mpic;
+ interrupts = 0x6 0x1;
+ reg = 0x19;
+ device_type = ethernet-phy;
+ };
+ phy1: [EMAIL PROTECTED] {
+ interrupt-parent = mpic;
+ interrupts = 0x7 0x1;
+ reg = 0x1a;
+ device_type = ethernet-phy;
+ };
+ phy2: [EMAIL PROTECTED] {
+ interrupt-parent = mpic;
+ interrupts = 0x8 0x1;
+ reg = 0x1b;
+ device_type = ethernet-phy;
+
