* Re: [DTC PATCH] libfdt: Add ft_get_next_node(), ft_get_next_prop(), and ft_getprop_offset().
From: David Gibson @ 2008-01-16 7:15 UTC (permalink / raw)
To: Scott Wood, jdl, linuxppc-dev
In-Reply-To: <20080116034939.GB5016@localhost.localdomain>
On Wed, Jan 16, 2008 at 02:49:39PM +1100, David Gibson wrote:
> On Tue, Jan 15, 2008 at 10:52:30AM -0600, Scott Wood wrote:
> > On Tue, Jan 15, 2008 at 11:16:57AM +1100, David Gibson wrote:
> > > On Mon, Jan 14, 2008 at 10:30:04AM -0600, Scott Wood wrote:
[snip]
> > > > + if (depth != 0)
> > > > + return -FDT_ERR_BADSTRUCTURE;
> > >
> > > I think this should be FDT_ERR_TRUNCATED.
> >
> > I'd expect TRUNCATED when we hit totalsize without an FDT_END, not when
> > we hit FDT_END in an inappropriate context.
>
> Well, TRUNCATED is valid for either situation, and fdt_next_tag() also
> returns FDT_END if it reaches totalsize.
Thought I should elaborate on this a bit - I'm not sure that the
current handling of FDT_ERR_TRUNCATED is entirely correct. The
description says only when the FDT_END tag is missing, but the way
fdt_next_tag() works means we will also (for some functions, at least)
give this error when FDT_END appears without a suitable number of
FDT_END_NODE tags preceding it.
The rationale behind FDT_ERR_TRUNCATED - why it exists as a separate
code from FDT_ERR_BADSTRUCTURE - is that the read-only functions
should work more-or-less sanely on incomplete trees created by the
sequential-write functions (fdt_sw.c). FDT_ERR_TRUNCATED is supposed
to indicate that the function couldn't complete properly because the
tree is malformed, but that suitable calls to the fdt_sw functions
could complete the tree so that it's no longer malformed.
I'm not sure that either the comment describing TRUNCATED, or the code
entirely matches that rationale...
--
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
^ permalink raw reply
* Re: [PATCH] net: NEWEMAC: Fix problem with mtu > 4080 on non TAH equipped 4xx PPC's
From: Benjamin Herrenschmidt @ 2008-01-16 7:15 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, netdev
In-Reply-To: <1200467475-1663-1-git-send-email-sr@denx.de>
On Wed, 2008-01-16 at 08:11 +0100, Stefan Roese wrote:
> Currently, all non TAH equipped 4xx PPC's call emac_start_xmit() upon
> xmit. This routine doesn't check if the frame length exceeds the max.
> MAL buffer size.
>
> This patch now changes the driver to call emac_start_xmit_sg() on all
> GigE platforms and not only the TAH equipped ones (440GX). This enables
> an MTU of 9000 instead 4080.
>
> Signed-off-by: Stefan Roese <sr@denx.de>
> ---
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Jeff, please pick up for .25.
Ben.
> drivers/net/ibm_newemac/core.c | 14 ++++----------
> 1 files changed, 4 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c
> index cb06280..b24bd2d 100644
> --- a/drivers/net/ibm_newemac/core.c
> +++ b/drivers/net/ibm_newemac/core.c
> @@ -1297,7 +1297,6 @@ static int emac_start_xmit(struct sk_buff *skb, struct net_device *ndev)
> return emac_xmit_finish(dev, len);
> }
>
> -#ifdef CONFIG_IBM_NEW_EMAC_TAH
> static inline int emac_xmit_split(struct emac_instance *dev, int slot,
> u32 pd, int len, int last, u16 base_ctrl)
> {
> @@ -1410,9 +1409,6 @@ static int emac_start_xmit_sg(struct sk_buff *skb, struct net_device *ndev)
> DBG2(dev, "stopped TX queue" NL);
> return 1;
> }
> -#else
> -# define emac_start_xmit_sg emac_start_xmit
> -#endif /* !defined(CONFIG_IBM_NEW_EMAC_TAH) */
>
> /* Tx lock BHs */
> static void emac_parse_tx_error(struct emac_instance *dev, u16 ctrl)
> @@ -2683,13 +2679,8 @@ static int __devinit emac_probe(struct of_device *ofdev,
>
> /* Fill in the driver function table */
> ndev->open = &emac_open;
> -#ifdef CONFIG_IBM_NEW_EMAC_TAH
> - if (dev->tah_dev) {
> - ndev->hard_start_xmit = &emac_start_xmit_sg;
> + if (dev->tah_dev)
> ndev->features |= NETIF_F_IP_CSUM | NETIF_F_SG;
> - } else
> -#endif
> - ndev->hard_start_xmit = &emac_start_xmit;
> ndev->tx_timeout = &emac_tx_timeout;
> ndev->watchdog_timeo = 5 * HZ;
> ndev->stop = &emac_close;
> @@ -2697,8 +2688,11 @@ static int __devinit emac_probe(struct of_device *ofdev,
> ndev->set_multicast_list = &emac_set_multicast_list;
> ndev->do_ioctl = &emac_ioctl;
> if (emac_phy_supports_gige(dev->phy_mode)) {
> + ndev->hard_start_xmit = &emac_start_xmit_sg;
> ndev->change_mtu = &emac_change_mtu;
> dev->commac.ops = &emac_commac_sg_ops;
> + } else {
> + ndev->hard_start_xmit = &emac_start_xmit;
> }
> SET_ETHTOOL_OPS(ndev, &emac_ethtool_ops);
>
^ permalink raw reply
* [PATCH 2/2] [POWERPC] 4xx: Add AMCC Haleakala (405EXr) dts
From: Stefan Roese @ 2008-01-16 7:24 UTC (permalink / raw)
To: linuxppc-dev
The patch adds the Haleakala dts. The Haleakala is a stripped down
version of the Kilauea (405EX) with only one EMAC and only one PCIe
interface.
Signed-off-by: Stefan Roese <sr@denx.de>
---
arch/powerpc/boot/dts/haleakala.dts | 274 +++++++++++++++++++++++++++++++++++
1 files changed, 274 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/haleakala.dts
diff --git a/arch/powerpc/boot/dts/haleakala.dts b/arch/powerpc/boot/dts/haleakala.dts
new file mode 100644
index 0000000..5dd3d15
--- /dev/null
+++ b/arch/powerpc/boot/dts/haleakala.dts
@@ -0,0 +1,274 @@
+/*
+ * Device Tree Source for AMCC Haleakala (405EXr)
+ *
+ * Copyright 2008 DENX Software Engineering, Stefan Roese <sr@denx.de>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without
+ * any warranty of any kind, whether express or implied.
+ */
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ model = "amcc,haleakala";
+ compatible = "amcc,kilauea";
+ dcr-parent = <&/cpus/cpu@0>;
+
+ aliases {
+ ethernet0 = &EMAC0;
+ serial0 = &UART0;
+ serial1 = &UART1;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ device_type = "cpu";
+ model = "PowerPC,405EXr";
+ reg = <0>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ timebase-frequency = <0>; /* Filled in by U-Boot */
+ i-cache-line-size = <20>;
+ d-cache-line-size = <20>;
+ i-cache-size = <4000>; /* 16 kB */
+ d-cache-size = <4000>; /* 16 kB */
+ dcr-controller;
+ dcr-access-method = "native";
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0 0>; /* Filled in by U-Boot */
+ };
+
+ UIC0: interrupt-controller {
+ compatible = "ibm,uic-405exr", "ibm,uic";
+ interrupt-controller;
+ cell-index = <0>;
+ dcr-reg = <0c0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ };
+
+ UIC1: interrupt-controller1 {
+ compatible = "ibm,uic-405exr","ibm,uic";
+ interrupt-controller;
+ cell-index = <1>;
+ dcr-reg = <0d0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <1e 4 1f 4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ UIC2: interrupt-controller2 {
+ compatible = "ibm,uic-405exr","ibm,uic";
+ interrupt-controller;
+ cell-index = <2>;
+ dcr-reg = <0e0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <1c 4 1d 4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ plb {
+ compatible = "ibm,plb-405exr", "ibm,plb4";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+
+ SDRAM0: memory-controller {
+ compatible = "ibm,sdram-405exr";
+ dcr-reg = <010 2>;
+ };
+
+ MAL0: mcmal {
+ compatible = "ibm,mcmal-405exr", "ibm,mcmal2";
+ dcr-reg = <180 62>;
+ num-tx-chans = <2>;
+ num-rx-chans = <2>;
+ interrupt-parent = <&MAL0>;
+ interrupts = <0 1 2 3 4>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = </*TXEOB*/ 0 &UIC0 a 4
+ /*RXEOB*/ 1 &UIC0 b 4
+ /*SERR*/ 2 &UIC1 0 4
+ /*TXDE*/ 3 &UIC1 1 4
+ /*RXDE*/ 4 &UIC1 2 4>;
+ interrupt-map-mask = <ffffffff>;
+ };
+
+ POB0: opb {
+ compatible = "ibm,opb-405exr", "ibm,opb";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <80000000 80000000 10000000
+ ef600000 ef600000 a00000
+ f0000000 f0000000 10000000>;
+ dcr-reg = <0a0 5>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+
+ EBC0: ebc {
+ compatible = "ibm,ebc-405exr", "ibm,ebc";
+ dcr-reg = <012 2>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ /* ranges property is supplied by U-Boot */
+ interrupts = <5 1>;
+ interrupt-parent = <&UIC1>;
+
+ nor_flash@0,0 {
+ compatible = "amd,s29gl512n", "cfi-flash";
+ bank-width = <2>;
+ reg = <0 000000 4000000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ partition@0 {
+ label = "kernel";
+ reg = <0 200000>;
+ };
+ partition@200000 {
+ label = "root";
+ reg = <200000 200000>;
+ };
+ partition@400000 {
+ label = "user";
+ reg = <400000 3b60000>;
+ };
+ partition@3f60000 {
+ label = "env";
+ reg = <3f60000 40000>;
+ };
+ partition@3fa0000 {
+ label = "u-boot";
+ reg = <3fa0000 60000>;
+ };
+ };
+ };
+
+ UART0: serial@ef600200 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600200 8>;
+ virtual-reg = <ef600200>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ current-speed = <0>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <1a 4>;
+ };
+
+ UART1: serial@ef600300 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600300 8>;
+ virtual-reg = <ef600300>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ current-speed = <0>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <1 4>;
+ };
+
+ IIC0: i2c@ef600400 {
+ compatible = "ibm,iic-405exr", "ibm,iic";
+ reg = <ef600400 14>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <2 4>;
+ };
+
+ IIC1: i2c@ef600500 {
+ compatible = "ibm,iic-405exr", "ibm,iic";
+ reg = <ef600500 14>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <7 4>;
+ };
+
+
+ RGMII0: emac-rgmii@ef600b00 {
+ compatible = "ibm,rgmii-405exr", "ibm,rgmii";
+ reg = <ef600b00 104>;
+ has-mdio;
+ };
+
+ EMAC0: ethernet@ef600900 {
+ linux,network-index = <0>;
+ device_type = "network";
+ compatible = "ibm,emac-405exr", "ibm,emac4";
+ interrupt-parent = <&EMAC0>;
+ interrupts = <0 1>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = </*Status*/ 0 &UIC0 18 4
+ /*Wake*/ 1 &UIC1 1d 4>;
+ reg = <ef600900 70>;
+ local-mac-address = [000000000000]; /* Filled in by U-Boot */
+ mal-device = <&MAL0>;
+ mal-tx-channel = <0>;
+ mal-rx-channel = <0>;
+ cell-index = <0>;
+ max-frame-size = <5dc>;
+ rx-fifo-size = <1000>;
+ tx-fifo-size = <800>;
+ phy-mode = "rgmii";
+ phy-map = <00000000>;
+ rgmii-device = <&RGMII0>;
+ rgmii-channel = <0>;
+ has-inverted-stacr-oc;
+ has-new-stacr-staopc;
+ };
+ };
+
+ PCIE0: pciex@0a0000000 {
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ compatible = "ibm,plb-pciex-405exr", "ibm,plb-pciex";
+ primary;
+ port = <0>; /* port number */
+ reg = <a0000000 20000000 /* Config space access */
+ ef000000 00001000>; /* Registers */
+ dcr-reg = <040 020>;
+ sdr-base = <400>;
+
+ /* Outbound ranges, one memory and one IO,
+ * later cannot be changed
+ */
+ ranges = <02000000 0 80000000 90000000 0 08000000
+ 01000000 0 00000000 e0000000 0 00010000>;
+
+ /* Inbound 2GB range starting at 0 */
+ dma-ranges = <42000000 0 0 0 0 80000000>;
+
+ /* This drives busses 0x00 to 0x3f */
+ bus-range = <00 3f>;
+
+ /* Legacy interrupts (note the weird polarity, the bridge seems
+ * to invert PCIe legacy interrupts).
+ * We are de-swizzling here because the numbers are actually for
+ * port of the root complex virtual P2P bridge. But I want
+ * to avoid putting a node for it in the tree, so the numbers
+ * below are basically de-swizzled numbers.
+ * The real slot is on idsel 0, so the swizzling is 1:1
+ */
+ interrupt-map-mask = <0000 0 0 7>;
+ interrupt-map = <
+ 0000 0 0 1 &UIC2 0 4 /* swizzled int A */
+ 0000 0 0 2 &UIC2 1 4 /* swizzled int B */
+ 0000 0 0 3 &UIC2 2 4 /* swizzled int C */
+ 0000 0 0 4 &UIC2 3 4 /* swizzled int D */>;
+ };
+ };
+};
--
1.5.4.rc3
^ permalink raw reply related
* [PATCH] [POWERPC] 4xx: Remove "i2c" and "xxmii-interface" device_types from dts
From: Stefan Roese @ 2008-01-16 9:00 UTC (permalink / raw)
To: linuxppc-dev
Remove all "i2c" and "xxmii-interface" (rgmii etc) device_type entries
from the 4xx dts files.
Signed-off-by: Stefan Roese <sr@denx.de>
---
arch/powerpc/boot/dts/bamboo.dts | 3 ---
arch/powerpc/boot/dts/ebony.dts | 2 --
arch/powerpc/boot/dts/katmai.dts | 2 --
arch/powerpc/boot/dts/kilauea.dts | 3 ---
arch/powerpc/boot/dts/makalu.dts | 3 ---
arch/powerpc/boot/dts/rainier.dts | 4 ----
arch/powerpc/boot/dts/sequoia.dts | 4 ----
arch/powerpc/boot/dts/taishan.dts | 4 ----
8 files changed, 0 insertions(+), 25 deletions(-)
diff --git a/arch/powerpc/boot/dts/bamboo.dts b/arch/powerpc/boot/dts/bamboo.dts
index 29f1a6f..7dc37c9 100644
--- a/arch/powerpc/boot/dts/bamboo.dts
+++ b/arch/powerpc/boot/dts/bamboo.dts
@@ -185,7 +185,6 @@
};
IIC0: i2c@ef600700 {
- device_type = "i2c";
compatible = "ibm,iic-440ep", "ibm,iic-440gp", "ibm,iic";
reg = <ef600700 14>;
interrupt-parent = <&UIC0>;
@@ -193,7 +192,6 @@
};
IIC1: i2c@ef600800 {
- device_type = "i2c";
compatible = "ibm,iic-440ep", "ibm,iic-440gp", "ibm,iic";
reg = <ef600800 14>;
interrupt-parent = <&UIC0>;
@@ -201,7 +199,6 @@
};
ZMII0: emac-zmii@ef600d00 {
- device_type = "zmii-interface";
compatible = "ibm,zmii-440ep", "ibm,zmii-440gp", "ibm,zmii";
reg = <ef600d00 c>;
};
diff --git a/arch/powerpc/boot/dts/ebony.dts b/arch/powerpc/boot/dts/ebony.dts
index f8790c4..106ef37 100644
--- a/arch/powerpc/boot/dts/ebony.dts
+++ b/arch/powerpc/boot/dts/ebony.dts
@@ -215,7 +215,6 @@
IIC0: i2c@40000400 {
/* FIXME */
- device_type = "i2c";
compatible = "ibm,iic-440gp", "ibm,iic";
reg = <40000400 14>;
interrupt-parent = <&UIC0>;
@@ -223,7 +222,6 @@
};
IIC1: i2c@40000500 {
/* FIXME */
- device_type = "i2c";
compatible = "ibm,iic-440gp", "ibm,iic";
reg = <40000500 14>;
interrupt-parent = <&UIC0>;
diff --git a/arch/powerpc/boot/dts/katmai.dts b/arch/powerpc/boot/dts/katmai.dts
index 9bdfc0f..bc32ac7 100644
--- a/arch/powerpc/boot/dts/katmai.dts
+++ b/arch/powerpc/boot/dts/katmai.dts
@@ -187,7 +187,6 @@
};
IIC0: i2c@10000400 {
- device_type = "i2c";
compatible = "ibm,iic-440spe", "ibm,iic-440gp", "ibm,iic";
reg = <10000400 14>;
interrupt-parent = <&UIC0>;
@@ -195,7 +194,6 @@
};
IIC1: i2c@10000500 {
- device_type = "i2c";
compatible = "ibm,iic-440spe", "ibm,iic-440gp", "ibm,iic";
reg = <10000500 14>;
interrupt-parent = <&UIC0>;
diff --git a/arch/powerpc/boot/dts/kilauea.dts b/arch/powerpc/boot/dts/kilauea.dts
index 67c7ea1..8baef61 100644
--- a/arch/powerpc/boot/dts/kilauea.dts
+++ b/arch/powerpc/boot/dts/kilauea.dts
@@ -182,7 +182,6 @@
};
IIC0: i2c@ef600400 {
- device_type = "i2c";
compatible = "ibm,iic-405ex", "ibm,iic";
reg = <ef600400 14>;
interrupt-parent = <&UIC0>;
@@ -190,7 +189,6 @@
};
IIC1: i2c@ef600500 {
- device_type = "i2c";
compatible = "ibm,iic-405ex", "ibm,iic";
reg = <ef600500 14>;
interrupt-parent = <&UIC0>;
@@ -199,7 +197,6 @@
RGMII0: emac-rgmii@ef600b00 {
- device_type = "rgmii-interface";
compatible = "ibm,rgmii-405ex", "ibm,rgmii";
reg = <ef600b00 104>;
has-mdio;
diff --git a/arch/powerpc/boot/dts/makalu.dts b/arch/powerpc/boot/dts/makalu.dts
index bdd70e4..710c011 100644
--- a/arch/powerpc/boot/dts/makalu.dts
+++ b/arch/powerpc/boot/dts/makalu.dts
@@ -182,7 +182,6 @@
};
IIC0: i2c@ef600400 {
- device_type = "i2c";
compatible = "ibm,iic-405ex", "ibm,iic";
reg = <ef600400 14>;
interrupt-parent = <&UIC0>;
@@ -190,7 +189,6 @@
};
IIC1: i2c@ef600500 {
- device_type = "i2c";
compatible = "ibm,iic-405ex", "ibm,iic";
reg = <ef600500 14>;
interrupt-parent = <&UIC0>;
@@ -199,7 +197,6 @@
RGMII0: emac-rgmii@ef600b00 {
- device_type = "rgmii-interface";
compatible = "ibm,rgmii-405ex", "ibm,rgmii";
reg = <ef600b00 104>;
has-mdio;
diff --git a/arch/powerpc/boot/dts/rainier.dts b/arch/powerpc/boot/dts/rainier.dts
index d3c2ac3..f947c75 100644
--- a/arch/powerpc/boot/dts/rainier.dts
+++ b/arch/powerpc/boot/dts/rainier.dts
@@ -229,7 +229,6 @@
};
IIC0: i2c@ef600700 {
- device_type = "i2c";
compatible = "ibm,iic-440grx", "ibm,iic";
reg = <ef600700 14>;
interrupt-parent = <&UIC0>;
@@ -237,7 +236,6 @@
};
IIC1: i2c@ef600800 {
- device_type = "i2c";
compatible = "ibm,iic-440grx", "ibm,iic";
reg = <ef600800 14>;
interrupt-parent = <&UIC0>;
@@ -245,13 +243,11 @@
};
ZMII0: emac-zmii@ef600d00 {
- device_type = "zmii-interface";
compatible = "ibm,zmii-440grx", "ibm,zmii";
reg = <ef600d00 c>;
};
RGMII0: emac-rgmii@ef601000 {
- device_type = "rgmii-interface";
compatible = "ibm,rgmii-440grx", "ibm,rgmii";
reg = <ef601000 8>;
has-mdio;
diff --git a/arch/powerpc/boot/dts/sequoia.dts b/arch/powerpc/boot/dts/sequoia.dts
index d9046c1..276f596 100644
--- a/arch/powerpc/boot/dts/sequoia.dts
+++ b/arch/powerpc/boot/dts/sequoia.dts
@@ -236,7 +236,6 @@
};
IIC0: i2c@ef600700 {
- device_type = "i2c";
compatible = "ibm,iic-440epx", "ibm,iic";
reg = <ef600700 14>;
interrupt-parent = <&UIC0>;
@@ -244,7 +243,6 @@
};
IIC1: i2c@ef600800 {
- device_type = "i2c";
compatible = "ibm,iic-440epx", "ibm,iic";
reg = <ef600800 14>;
interrupt-parent = <&UIC0>;
@@ -252,13 +250,11 @@
};
ZMII0: emac-zmii@ef600d00 {
- device_type = "zmii-interface";
compatible = "ibm,zmii-440epx", "ibm,zmii";
reg = <ef600d00 c>;
};
RGMII0: emac-rgmii@ef601000 {
- device_type = "rgmii-interface";
compatible = "ibm,rgmii-440epx", "ibm,rgmii";
reg = <ef601000 8>;
has-mdio;
diff --git a/arch/powerpc/boot/dts/taishan.dts b/arch/powerpc/boot/dts/taishan.dts
index 0706a4a..8278068 100644
--- a/arch/powerpc/boot/dts/taishan.dts
+++ b/arch/powerpc/boot/dts/taishan.dts
@@ -203,7 +203,6 @@
IIC0: i2c@40000400 {
/* FIXME */
- device_type = "i2c";
compatible = "ibm,iic-440gp", "ibm,iic";
reg = <40000400 14>;
interrupt-parent = <&UIC0>;
@@ -211,7 +210,6 @@
};
IIC1: i2c@40000500 {
/* FIXME */
- device_type = "i2c";
compatible = "ibm,iic-440gp", "ibm,iic";
reg = <40000500 14>;
interrupt-parent = <&UIC0>;
@@ -225,13 +223,11 @@
};
ZMII0: emac-zmii@40000780 {
- device_type = "zgmii-interface";
compatible = "ibm,zmii-440gx", "ibm,zmii";
reg = <40000780 c>;
};
RGMII0: emac-rgmii@40000790 {
- device_type = "rgmii-interface";
compatible = "ibm,rgmii";
reg = <40000790 8>;
};
--
1.5.4.rc3
^ permalink raw reply related
* PPC440SPe: generating PCIe INTx
From: kannappan @ 2008-01-16 8:46 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 867 bytes --]
Hello All,
I would like to know how to generate PCIe INTx interrupt from Legacy
PCIe EP in PPC440SPe.
Also, please clarify,
Page 741 of the user manual (PPC440SPe_UM2014_V1_26.pdf) write
Assert_INTx message to INT_ADDR[61:63].
Page 739, table 27-9, mentions, Assert_INTA by writing to Outbound GBIF
write channel 9, A[52:59]=0x20.
Whether the INT_ADDR is any addresses BAR3 / POM3 address?
What is the Assert_INTx value to be written to INT_ADDR[61:63]? How do
I correlate with the message code values given in PCI express system
architecture?
The message codes given in PCI express system architecture is as follows
INTx Messages
Message Code
Assert_INTA
0010 0000
Assert_INTB
0010 0001
Assert_INTC
0010 0010
Assert_INTD
0010 0011
Deassert_INTA
0010 0100
Deassert_INTB
0010 0101
Deassert_INTC
0010 0110
Deassert_INTD
0010 0111
Regards,
Kans.
[-- Attachment #2: Type: text/html, Size: 12516 bytes --]
^ permalink raw reply
* [PATCH] net: NEWEMAC: Remove "rgmii-interface" from rgmii matching table
From: Stefan Roese @ 2008-01-16 9:37 UTC (permalink / raw)
To: linuxppc-dev, netdev
With the removal the the "rgmii-interface" device_type property from the
dts files, the newemac driver needs an update to only rely on compatible
property.
Signed-off-by: Stefan Roese <sr@denx.de>
---
drivers/net/ibm_newemac/rgmii.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ibm_newemac/rgmii.c b/drivers/net/ibm_newemac/rgmii.c
index 9bc1132..5757788 100644
--- a/drivers/net/ibm_newemac/rgmii.c
+++ b/drivers/net/ibm_newemac/rgmii.c
@@ -302,7 +302,6 @@ static int __devexit rgmii_remove(struct of_device *ofdev)
static struct of_device_id rgmii_match[] =
{
{
- .type = "rgmii-interface",
.compatible = "ibm,rgmii",
},
{
--
1.5.4.rc3
^ permalink raw reply related
* Re: [PATCH] net: NEWEMAC: Remove "rgmii-interface" from rgmii matching table
From: David Gibson @ 2008-01-16 9:39 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, netdev
In-Reply-To: <1200476230-14026-1-git-send-email-sr@denx.de>
On Wed, Jan 16, 2008 at 10:37:10AM +0100, Stefan Roese wrote:
> With the removal the the "rgmii-interface" device_type property from the
> dts files, the newemac driver needs an update to only rely on compatible
> property.
In fact, this patch should go in before the one changing the dts
files.
--
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
^ permalink raw reply
* Re: [PATCH] [POWERPC] 4xx: Remove "i2c" and "xxmii-interface" device_types from dts
From: David Gibson @ 2008-01-16 9:40 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <1200474000-5630-1-git-send-email-sr@denx.de>
On Wed, Jan 16, 2008 at 10:00:00AM +0100, Stefan Roese wrote:
> Remove all "i2c" and "xxmii-interface" (rgmii etc) device_type entries
> from the 4xx dts files.
>
> Signed-off-by: Stefan Roese <sr@denx.de>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
--
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
^ permalink raw reply
* Re: [PATCH] net: NEWEMAC: Remove "rgmii-interface" from rgmii matching table
From: Benjamin Herrenschmidt @ 2008-01-16 9:53 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, netdev
In-Reply-To: <1200476230-14026-1-git-send-email-sr@denx.de>
On Wed, 2008-01-16 at 10:37 +0100, Stefan Roese wrote:
> With the removal the the "rgmii-interface" device_type property from the
> dts files, the newemac driver needs an update to only rely on compatible
> property.
>
> Signed-off-by: Stefan Roese <sr@denx.de>
I need to test if it works on CAB, can't change the DT on those. I'll
let you know tomorrow.
> ---
> drivers/net/ibm_newemac/rgmii.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/ibm_newemac/rgmii.c b/drivers/net/ibm_newemac/rgmii.c
> index 9bc1132..5757788 100644
> --- a/drivers/net/ibm_newemac/rgmii.c
> +++ b/drivers/net/ibm_newemac/rgmii.c
> @@ -302,7 +302,6 @@ static int __devexit rgmii_remove(struct of_device *ofdev)
> static struct of_device_id rgmii_match[] =
> {
> {
> - .type = "rgmii-interface",
> .compatible = "ibm,rgmii",
> },
> {
^ permalink raw reply
* ppc: 4xx: sysctl table check failed: /kernel/l2cr .1.31 Missing strategy
From: Stefan Roese @ 2008-01-16 10:55 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel
I'm seeing this error message when booting an recent arch/ppc kernel on
4xx platforms (tested on Ocotea and other 4xx platforms). Booting NFS
rootfs still works fine, but this message kind of makes me "nervous".
This is not seen on 4xx arch/powerpc platforms. Here the bootlog:
Linux version 2.6.24-rc8 (stefan@ubuntu) (gcc version 4.2.2) #1 Wed Jan 16 11:51:57 CET 2008
IBM Ocotea port (MontaVista Software, Inc. <source@mvista.com>)
Zone PFN ranges:
DMA 0 -> 65536
Normal 65536 -> 65536
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0 -> 65536
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024
Kernel command line: root=/dev/nfs rw nfsroot=192.168.1.1:/opt/eldk-4.1/ppc_4xx ip=192.168.80.2:192.168.1.1::255.255.0.0:ocotea:eth0:off panic=1 console=ttyS0,115200
PID hash table entries: 1024 (order: 10, 4096 bytes)
console [ttyS0] enabled
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 257536k available (1660k kernel code, 540k data, 104k init, 0k highmem)
SLUB: Genslabs=11, HWalign=32, Order=0-1, MinObjects=4, CPUs=1, Nodes=1
Mount-cache hash table entries: 512
net_namespace: 64 bytes
NET: Registered protocol family 16
PCI: Probing PCI hardware
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP reno registered
sysctl table check failed: /kernel/l2cr .1.31 Missing strategy
Call Trace:
[cfc11df0] [c00082d0] show_stack+0x44/0x1ac (unreliable)
[cfc11e30] [c0034ffc] set_fail+0x50/0x68
[cfc11e50] [c0035428] sysctl_check_table+0x414/0x70c
[cfc11ec0] [c003543c] sysctl_check_table+0x428/0x70c
[cfc11f30] [c0021fe4] register_sysctl_table+0x64/0xb4
[cfc11f50] [c0213858] register_ppc_htab_sysctl+0x18/0x2c
[cfc11f60] [c02121f4] kernel_init+0xd0/0x2b0
[cfc11ff0] [c0003b3c] kernel_thread+0x44/0x60
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
...
Any ideas?
Thanks.
Best regards,
Stefan
^ permalink raw reply
* MPC52xx problems with fec-driver
From: Mehlan, Markus (Ritter Elektronik) @ 2008-01-16 12:20 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
i have a mpc5200b-based board with 2 ethernet interfaces,
Kernel 2.6.23.1-rt5 (arch=3Dpowerpc), last fec/bestcomm-patches:
eth0: mpc52xx_FEC
eth1: natsemi dp8381x
The natsemi driver works pretty, but the FEC makes problems:
If i ping the board i get damaged packages. The interrupt-counter
for the control-irq (mpc52xx-fec_ctrl) stays on zero.
The FEC interface works with an older kernel (2.6.14-rt22 arch=3Dppc).
Markus
root@phyCORE-MPC5200B-tiny:~ cat /proc/interrupts
CPU0
66: 5 MPC52xx IRQ[0-3] Edge eth1
132: 1368 MPC52xx Peripherals Edge mpc52xx_psc_uart
133: 0 MPC52xx Peripherals Edge mpc52xx-fec_ctrl
143: 2 MPC52xx Peripherals Edge i2c-mpc
144: 60 MPC52xx Peripherals Edge i2c-mpc
145: 0 MPC52xx Peripherals Edge can0
146: 0 MPC52xx Peripherals Edge can1
192: 32 MPC52xx SDMA Edge mpc52xx-fec_rx
193: 35 MPC52xx SDMA Edge mpc52xx-fec_tx
BAD: 0
ritter-ewc2:/home/meh # ping -a 192.168.0.9
PING 192.168.0.9 (192.168.0.9) 56(84) bytes of data.
64 bytes from 192.168.0.9: icmp_seq=3D3 ttl=3D64 time=3D0.267 ms
64 bytes from 192.168.0.9: icmp_seq=3D11 ttl=3D64 time=3D0.271 ms
64 bytes from 192.168.0.9: icmp_seq=3D17 ttl=3D64 time=3D0.266 ms
wrong data byte #20 should be 0x14 but was 0x0
#8 8 9 a b c d e f 10 11 12 13 0 15 16 17 18 19 1a 1b 1c 1d 1e 1f
20 21 22 23 24 25 26 27
#40 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37
--- 192.168.0.9 ping statistics ---
19 packets transmitted, 3 received, 84% packet loss, time 18026ms
------------------------------------------------------------------
Using ritter_el392 machine description
Linux version 2.6.23.1-rt5-el392trunk (meh@ritter-ewc2) (gcc version
4.1.2) #445 PREEMPT RT Wed Jan 16 12:05:52 CET 2008
Found initrd at 0xc3a2e000:0xc3f47e63
Zone PFN ranges:
DMA 0 -> 16384
Normal 16384 -> 16384
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0 -> 16384
Real-Time Preemption Support (C) 2004-2007 Ingo Molnar
Built 1 zonelists in Zone order. Total pages: 16256
Kernel command line: console=3DttyPSC0,115200 root=3D/dev/ram0 rw
ip=3D192.168.0.10:192.168.0.1::255.255.255.0:RITTER_EL392:eth1:off =
panic=3D1
WARNING: experimental RCU implementation.
MPC52xx PIC is up and running!
PID hash table entries: 256 (order: 8, 1024 bytes)
console [ttyPSC0] enabled
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 56972k/65536k available (2412k kernel code, 8500k reserved, 132k
data, 101k bss, 148k init)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
PCI: Probing PCI hardware
DMA: MPC52xx BestComm driver
DMA: MPC52xx BestComm engine @f0001200 ok !
Generic PHY xxx: Registered new driver
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 2048 (order: 4, 73728 bytes)
TCP bind hash table entries: 2048 (order: 3, 57344 bytes)
TCP: Hash tables configured (established 2048 bind 2048)
TCP reno registered
checking if image is initramfs...it isn't (no cpio magic); looks like an
initrd
Freeing initrd memory: 5223k freed
io scheduler noop registered (default)
Serial: MPC52xx PSC UART driver
f0002c00.serial: ttyPSC0 at MMIO 0xf0002c00 (irq =3D 132) is a MPC52xx =
PSC
RAMDISK driver initialized: 2 RAM disks of 20480K size 1024 blocksize
mpc52xx-mscan initializing
mpc52xx-mscan mpc52xx-mscan.0: probe for a port 0xC500A900 done
mpc52xx-mscan mpc52xx-mscan.1: probe for a port 0xC500C980 done
mpc52xx MII bus: probed
natsemi dp8381x driver, version 2.1, Sept 11, 2006
originally by Donald Becker <becker@scyld.com>
2.4.x kernel port by Jeff Garzik, Tjeerd Mulder
PCI: Enabling device 0000:00:18.0 (0006 -> 0007)
natsemi eth1: NatSemi DP8381[56] at 0xa0000000 (0000:00:18.0),
00:0b:93:80:01:00, IRQ 66, port TP.
i2c /dev entries driver
pcf8563 1-0051: chip found, driver version 0.4.2
pcf8563 1-0051: rtc core: registered pcf8563 as rtc0
MPC52xx Watchdog Timer on GPT0
MPC52xx Watchdog-Relay on GPIO
Registered led device: el392:right
Registered led device: el392:middle
Registered led device: el392:left
EL392 Front-LEDs found
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
NET: Registered protocol family 15
can: controller area network core (rev 20070916 abi 8)
NET: Registered protocol family 29
can: raw protocol (rev 20070916)
pcf8563 1-0051: setting the system clock to 2008-01-16 12:06:42
(1200485202)
eth1: DSPCFG accepted after 0 usec.
eth1: link up.
eth1: Setting full-duplex based on negotiated link capability.
IP-Config: Complete:
device=3Deth1, addr=3D192.168.0.10, mask=3D255.255.255.0,
gw=3D255.255.255.255,
host=3DRITTER_EL392, domain=3D, nis-domain=3D(none),
bootserver=3D192.168.0.1, rootserver=3D192.168.0.1, rootpath=3D
RAMDISK: Compressed image found at block 0
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 148k init
mounting filesystems...done.
running rc.d services...
mounting... tmpfs at /dev
creating static nodes
creating initial udev device nodes...done
udev startup is finished
loading modules
syslogd starting
klogd starting
starting network interfaces...
can0: baudrate 250
can1: baudrate 250
net eth0: attached phy 0 to driver Generic PHY
PURE-FTPD: No /etc/pure-ftpd.defaults found.
/usr/sbin/pure-ftpd
PURE-FTPD: Starting pure-ftpd: /usr/sbin/pure-ftpd
PURE-FTPD: no upload script defined, skipping
Done
Starting telnetd...
thttpd: starting
thttpd: done
el392 login:=20
PHY: f0003000:00 - Link is Up - 100/Full
net eth0: attached phy 0 to driver Generic PHY
^ permalink raw reply
* Re: [PATCH] [POWERPC] 4xx: Remove "i2c" and "xxmii-interface" device_types from dts
From: Josh Boyer @ 2008-01-16 12:40 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <1200474000-5630-1-git-send-email-sr@denx.de>
On Wed, 16 Jan 2008 10:00:00 +0100
Stefan Roese <sr@denx.de> wrote:
> Remove all "i2c" and "xxmii-interface" (rgmii etc) device_type entries
> from the 4xx dts files.
Holding on this one until Ben or I can check Axon to see if it's DT can
handle no device_type for xxmii-interface.
josh
^ permalink raw reply
* Re: i2c device for a linux 2.6 in XUPV2P
From: greenlean @ 2008-01-16 12:43 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <ef1737dc0712241327t3cc7c14kcb91e9a4e550df18@mail.gmail.com>
Hi Josep,
I have read this post in linuxppc-embedded and you said that you're running
linux 2.6 in the XUPV2P. I'm beginning in this world (fpga and linux) and
nothing is running. I'm trying to boot kernel 2.6 on that board, but it is
resisting me. I have successfully booted it up on the ML403, but all my
attempts in the XUPV2P are crashing, maybe you could help me.
My problem is that I can't see anything in the minicom console when I
download the kernel. I build the kernel succesfully, using both UART IP
cores (UARTLite and UART16550) but in both cases there is no prompt in
minicom. I start with the TestApp generated by EDK and both MemTest and
PeripheralTest are running fine. But then when I do dow zImage, there is no
prompt.
I think I'm using correctly the drivers, when I use UARTLite I configure the
boud rate at arch/ppc/boot/common/ns16550.c and I configure the kernel with:
* initial command string console=ttyUL0,<baudrate>
* and in Device Drivers/Character Devices/Serial Drivers I choose Xilinx
uartlite serial port to include in the kernel and Support for console on
Xilinx UartLite serial port.
and when I use the UART16550 I configure it
* initial command string console=ttyS0,<baudrate>
* and in Device Drivers/Character Devices/Serial Drivers I choose Xilinx
8250/16550 and compatible support and console on 8250/16550 and compatible
serial port
I think that's the correct configuration,I read it in this list and in some
application notes from Xilinx which isn't very well.
By the other side I'm overwriting the xparameter_ml300.h file of the kernel
with the one generated by EDK 9.1i SP2, I'm using only this file from the
bsp generated by EDK.
I'm using the kernel from xilinx git and I've tried the one from secretlab,
but not the same as you, I'm using the (linux-2.6-virtex). I don't know how
to download or change to the branch "virtex-for-2.6.24" that you're using
(I'm new to git too, some help will be welcome).
Thanks I really need some guide for the process. If you know about any patch
or which is the problem I'm suffering please tell me.
Josep Maria Batlle wrote:
>
> Hi all,
>
> I have booted up linux 2.6 on Xilinx XUPV2P (using the base of ml300
> config
> file).
> Now I am trying to use the i2c in the user-space. First of all: is it
> possible?
>
> My first attempts have not worked. I have made this:
> 1) I enable "I2C Support" and "I2C device interface" in the kernel
> recompilation.
> 2) I added the "i2c-0" device in /dev (# mknod i2c-0 c 89 0)
> 3) then I run a simple program to open the device (provided by the
> "dev-interface" file of i2c kernel documentation) that returns this errno
> message: "No such device".
>
> I have tried to use the device number 1, 2, 3, 4 but these have not
> worked.
> I have tried to use the device "i2cn" but not worked. I have tried to use
> all the BSP's from the EDK (7.1i) and then only the "xparameters_ml300.h"
> in
> the compilation. After all of this, now I am modifying the RFS for
> "mdev"...
> Somebody can tell me what I am doing wrong if this use is possible?
>
> I use the kernel tree "virtex-for-2.6.24" from SecretLab and Busybox
> 1.7.2.
>
> Thanks.
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--
View this message in context: http://www.nabble.com/i2c-device-for-a-linux-2.6-in-XUPV2P-tp14491409p14879785.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Please pull from 'for-2.6.25' branch of 4xx tree
From: Josh Boyer @ 2008-01-16 12:49 UTC (permalink / raw)
To: paulus, linuxppc-dev
Hi Paul,
Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git for-2.6.25
to pick up a small number of changes for 2.6.25. Mostly Xilinx stuff
from Stephen and Grant, with a couple of EMAC enables and a bug fix.
I'll likely send another pull request with some more patches from
Stefan and David, as well as the PIKA Warp platform patches. But I
need to look at those a bit longer.
josh
Grant Likely (1):
[POWERPC] 4xx: typo in calling machine_device_initcall() for Sequoia board
Hollis Blanchard (1):
[POWERPC] 4xx: enable built-in networking for Sequoia defconfig
Josh Boyer (1):
Merge branch 'virtex-for-2.6.25' of git://git.secretlab.ca/git/linux-2.6-v
Matthias Fuchs (1):
[POWERPC] 4xx: Add 405GPr and 405EP support in boot wrapper
Stefan Roese (2):
[POWERPC] 4xx: Add EMAC support to Kilauea defconfig
[POWERPC] 4xx: PCIe: Increase max busses per port to 64
Stephen Neuendorffer (5):
[POWERPC] Xilinx: update compatible list for interrupt controller
[POWERPC] Xilinx: Add correct compatible list for device tree bus bindings
[POWERPC] Xilinx: Update booting-without-of.
[POWERPC] Xilinx: updated device tree compatibility to match uboot bsp gen
[POWERPC] Xilinx uartlite: Section type fixups
Documentation/powerpc/booting-without-of.txt | 56 +++++++++++-------
arch/powerpc/boot/4xx.c | 81 +++++++++++++++++++++++--
arch/powerpc/boot/4xx.h | 1 +
arch/powerpc/boot/dcr.h | 5 ++
arch/powerpc/boot/serial.c | 3 +-
arch/powerpc/configs/bamboo_defconfig | 4 +-
arch/powerpc/configs/kilauea_defconfig | 23 +++++++-
arch/powerpc/configs/sequoia_defconfig | 24 ++++++-
arch/powerpc/platforms/40x/virtex.c | 12 ++++-
arch/powerpc/platforms/44x/sequoia.c | 2 +-
arch/powerpc/sysdev/ppc4xx_pci.c | 2 +-
arch/powerpc/sysdev/xilinx_intc.c | 8 ++-
drivers/serial/uartlite.c | 6 +-
13 files changed, 180 insertions(+), 47 deletions(-)
^ permalink raw reply
* Re: [PATCH] [POWERPC] 4xx: Remove "i2c" and "xxmii-interface" device_types from dts
From: Stefan Roese @ 2008-01-16 13:01 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20080116064008.390db210@zod.rchland.ibm.com>
Josh,
On Wednesday 16 January 2008, Josh Boyer wrote:
> > Remove all "i2c" and "xxmii-interface" (rgmii etc) device_type entries
> > from the 4xx dts files.
>
> Holding on this one until Ben or I can check Axon to see if it's DT can
> handle no device_type for xxmii-interface.
Best would be, if you would hold this patch at least until the newemac patch
is pulled.
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH] [POWERPC] 4xx: Remove "i2c" and "xxmii-interface" device_types from dts
From: Josh Boyer @ 2008-01-16 13:08 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <200801161401.22855.sr@denx.de>
On Wed, 16 Jan 2008 14:01:22 +0100
Stefan Roese <sr@denx.de> wrote:
> Josh,
>
> On Wednesday 16 January 2008, Josh Boyer wrote:
> > > Remove all "i2c" and "xxmii-interface" (rgmii etc) device_type entries
> > > from the 4xx dts files.
> >
> > Holding on this one until Ben or I can check Axon to see if it's DT can
> > handle no device_type for xxmii-interface.
>
> Best would be, if you would hold this patch at least until the newemac patch
> is pulled.
Sure, I was already planning on doing that anyway. It's early, and
the Axon verification is really for that newemac patch anyway, not
this one :)
josh
^ permalink raw reply
* ml310 kernel2.6 booting problems
From: Joachim Meyer @ 2008-01-16 13:25 UTC (permalink / raw)
To: linuxppc-embedded
Hi
I made an Ace file with my Kernel and load it with the Flash Card.
I made the Initial release CF image on the card and copied my ace file in an folder, from which I boot with the DIP-Switch.
If I used
"console=ttyUL0 ,9600 root=/dev/xsysace/disc0/part2 rw "
in the Kernel config booting aborts like this:
----------------------------------------------------------------------------------------------------------------
....
[ 5.715168] 000001c0: 00000000 00000000 00000000 00000000 ................
[ 5.797484] 000001d0: 00000000 00000000 00000000 00000000 ................
[ 5.879741] 000001e0: 00000000 00000000 00000000 00000000 ................
[ 5.962057] 000001f0: 00000000 00000000 00000000 00000000 ................
[ 6.044365] xsysace xsysace.0: capacity: 1000944 sectors
[ 6.109986] xsa:<7>xsysace xsysace.0: fsm_state=0, id_req_count=0
[ 6.207902] xsa1 xsa2
[ 6.226842] Xilinx SystemACE device driver, major=254
[ 6.281419] tun: Universal TUN/TAP device driver, 1.6
[ 6.341706] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[ 6.419485] mice: PS/2 mouse device common for all mice
[ 6.478716] TCP cubic registered
[ 6.516974] NET: Registered protocol family 1
[ 6.568940] NET: Registered protocol family 17
[ 6.627483] VFS: Cannot open root device "xsysace/disc0/part2" or unknown-block(0,0)
[ 6.714743] Please append a correct "root=" boot option; here are the available partitions:
[ 6.814732] fe00 500472 xsa (driver?)
[ 6.862193] fe01 98248 xsa1
[ 6.902974] fe02 402192 xsa2
[ 6.943603] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[ 7.042832] Rebooting in 180 seconds..
------------------------------------------------------------------------------------------------------------------------------------
I tried to use this:
"console=ttyUL0 ,9600 root=fe02 rw"
and with this, after making ace-file etc. I get:
-------------------------------------------------------------------------------------------------------
...
[ 5.447429] 00000190: 00000000 00000000 00000000 00000000 ................
[ 5.529734] 000001a0: 00000000 00000000 00000000 00000000 ................
[ 5.612002] 000001b0: 00000000 00000000 00000000 00000000 ................
[ 5.694288] 000001c0: 00000000 00000000 00000000 00000000 ................
[ 5.776594] 000001d0: 00000000 00000000 00000000 00000000 ................
[ 5.858861] 000001e0: 00000000 00000000 00000000 00000000 ................
[ 5.941167] 000001f0: 00000000 00000000 00000000 00000000 ................
[ 6.023453] xsysace xsysace.0: capacity: 1000944 sectors
[ 6.090042] xsa:<7>xsysace xsysace.0: fsm_state=0, id_req_count=0
[ 6.186832] xsa1 xsa2
[ 6.205880] Xilinx SystemACE device driver, major=254
[ 6.260331] tun: Universal TUN/TAP device driver, 1.6
[ 6.320626] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[ 6.398443] mice: PS/2 mouse device common for all mice
[ 6.457695] TCP cubic registered
[ 6.495755] NET: Registered protocol family 1
[ 6.547840] NET: Registered protocol family 17
[ 12.726608] kjournald starting. Commit interval 5 seconds
[ 12.862678] EXT3 FS on xsa2, internal journal
[ 12.899229] EXT3-fs: recovery complete.
[ 12.982635] EXT3-fs: mounted filesystem with ordered data mode.
[ 13.038505] VFS: Mounted root (ext3 filesystem).
[ 13.094113] Freeing unused kernel memory: 96k init
[ 13.159079] Warning: unable to open an initial console.
-------------------------------------------------------------------------------------------------
what is the Problem here?
What should I consider when I configure the kernel, what when building an rootfs?
Greetings
Joachim
_________________________________________________________________________
In 5 Schritten zur eigenen Homepage. Jetzt Domain sichern und gestalten!
Nur 3,99 EUR/Monat! http://www.maildomain.web.de/?mc=021114
^ permalink raw reply
* Re: ml310 kernel2.6 booting problems
From: Grant Likely @ 2008-01-16 14:50 UTC (permalink / raw)
To: Joachim Meyer; +Cc: linuxppc-embedded
In-Reply-To: <537566320@web.de>
On 1/16/08, Joachim Meyer <Jogi95@web.de> wrote:
> Hi
>
> I made an Ace file with my Kernel and load it with the Flash Card.
> I made the Initial release CF image on the card and copied my ace file in an folder, from which I boot with the DIP-Switch.
> If I used
> "console=ttyUL0 ,9600 root=/dev/xsysace/disc0/part2 rw "
try root=/dev/xsa2
Also, the ',9600' is unnecessary with the uartlite.
>
> I tried to use this:
> "console=ttyUL0 ,9600 root=fe02 rw"
> and with this, after making ace-file etc. I get:
> [ 12.862678] EXT3 FS on xsa2, internal journal
> [ 12.899229] EXT3-fs: recovery complete.
> [ 12.982635] EXT3-fs: mounted filesystem with ordered data mode.
> [ 13.038505] VFS: Mounted root (ext3 filesystem).
> [ 13.094113] Freeing unused kernel memory: 96k init
> [ 13.159079] Warning: unable to open an initial console.
You're probably missing the /dev/console device file
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] net: NEWEMAC: Remove "rgmii-interface" from rgmii matching table
From: Josh Boyer @ 2008-01-16 15:01 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Stefan Roese, netdev
In-Reply-To: <1200477239.6755.21.camel@pasglop>
On Wed, 16 Jan 2008 20:53:59 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> On Wed, 2008-01-16 at 10:37 +0100, Stefan Roese wrote:
> > With the removal the the "rgmii-interface" device_type property from the
> > dts files, the newemac driver needs an update to only rely on compatible
> > property.
> >
> > Signed-off-by: Stefan Roese <sr@denx.de>
>
> I need to test if it works on CAB, can't change the DT on those. I'll
> let you know tomorrow.
This should be fine on CAB. The rgmii node has:
compatible = "ibm,rgmii-axon", "ibm,rgmii"
so the match should still catch on the latter.
josh
^ permalink raw reply
* Fixed phy
From: Rune Torgersen @ 2008-01-16 16:50 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 372 bytes --]
Hi
We're doing a port to 2.6.24-rc7, and we need to set up two ethernets with fixed phy's as they have phyless interfaces to a switch.
WE cannot find any good examples on how to do this. We've found the fixed speed PHY emulation in the configuration, but are unsure on how to set the PHY's up in the device tree.
This is using a 8280 cpu and ethernet on the FCC's
[-- Attachment #2: Type: text/html, Size: 748 bytes --]
^ permalink raw reply
* Re: ml310 kernel2.6 booting problems
From: Joachim Meyer @ 2008-01-16 20:02 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
Thx for the answer
It's right, there is no /dev/console, but the MontaVista-Linux-kernel can =
fully boot with this rootFS, how comes=3F
Doesn't matter, I was going to make my own RootFS anyway, so can you give =
me an hint how I would
do this best=3F
I tried the Klingauf-Script (www.klingauf.com) with busybox, but I still h=
ave no console in my /dev/ and it doesn't work.
I tried out buildroot, but I was a little overstrained with the configurat=
ion and when I did "make" it aborted with an error message
after a long time of working
Then I tried ELDK. I read that I could use the Directory "<install-dir>/pp=
c=5F4xx/" as rootfs but when I go there and look inside=20
/dev I find only one entry:
prw------- 1 jogi jogi 0 2007-01-20 04:58 initctl
So this won't work, would it=3F
Which way would be the best for me to get an good RootFS easily=3F
If the answer would be buildroot can you give me a short summary which set=
tings are importent=3F
I read I can use my crosstool-Xcompiler, but I couldn't figure out how.=20
Greetings & Thx
Joachim
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
Erweitern Sie FreeMail zu einem noch leistungsst=E4rkeren E-Mail-Postfach! =09
Mehr Infos unter http://produkte.web.de/club/=3Fmc=3D021131
^ permalink raw reply
* Re: ml310 kernel2.6 booting problems
From: Grant Likely @ 2008-01-16 20:30 UTC (permalink / raw)
To: Joachim Meyer; +Cc: linuxppc-embedded
In-Reply-To: <538215286@web.de>
On 1/16/08, Joachim Meyer <Jogi95@web.de> wrote:
> Thx for the answer
>
> It's right, there is no /dev/console, but the MontaVista-Linux-kernel can fully boot with this rootFS, how comes?
hmmm, I don't know. The montavista kernel might be running a
different binary as the init process. Compare the kernel parameter
lines between the two.
> Doesn't matter, I was going to make my own RootFS anyway, so can you give me an hint how I would
> do this best?
> I tried the Klingauf-Script (www.klingauf.com) with busybox, but I still have no console in my /dev/ and it doesn't work.
Creating a console device is easy:
$ mknod /dev/console c 5 1
> I tried out buildroot, but I was a little overstrained with the configuration and when I did "make" it aborted with an error message
> after a long time of working
> Then I tried ELDK. I read that I could use the Directory "<install-dir>/ppc_4xx/" as rootfs but when I go there and look inside
> /dev I find only one entry:
> prw------- 1 jogi jogi 0 2007-01-20 04:58 initctl
> So this won't work, would it?
Looks like you haven't installed ELDK correctly. I recommend
rereading the instructions and giving it another try. ELDK is a great
starting point.
>
> Which way would be the best for me to get an good RootFS easily?
> If the answer would be buildroot can you give me a short summary which settings are importent?
Personally, I use buildroot, but you should start with ELDK to get things going.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 3/4] powerpc: Katana750i - Add DTS file
From: Mark A. Greer @ 2008-01-16 20:48 UTC (permalink / raw)
To: Mark A. Greer, linuxppc-dev
In-Reply-To: <20080116002228.GC4283@localhost.localdomain>
On Wed, Jan 16, 2008 at 11:22:28AM +1100, David Gibson wrote:
> On Tue, Jan 15, 2008 at 12:08:06PM -0700, Mark A. Greer wrote:
> > On Tue, Jan 15, 2008 at 10:34:06AM +1100, David Gibson wrote:
> > > On Mon, Jan 14, 2008 at 03:59:26PM -0700, Mark A. Greer wrote:
> > > > From: Mark A. Greer <mgreer@mvista.com>
> >
> > Hi David. Thanks for the review.
> >
> > > > Add DTS file for the Emerson Katana 750i & 752i platforms.
> > >
> > > [snip]
> > > > +/dts-v1/;
> > > > +
> > > > +/ {
> > > > + #address-cells = <1>;
> > > > + #size-cells = <1>;
> > > > + model = "Katana-75xi"; /* Default */
> > > > + compatible = "emerson,katana-750i";
> > > > + coherency-off;
> > >
> > > Where is this flag used from?
> >
> > Its used in the bootwrapper if & when you use the mv64x60 code to setup
> > some of the windows to the I/O ctlrs. This port does use that code
> > (because firmware doesn't do it properly) so I need the flag.
>
> Hrm.. ok. I'm just wondering if a new flag is really the right
> approach for this, or whether you should be basing the setup off the
> compatible property, either for the board or for the main bridge.
I'd prefer to keep the flag. Otherwise, the bootwrapper will need a
table to look up the compatible field to see if coherency is supposed
to be on or off. We'd have to add an entry to that table for any
compatible that need coherency off, etc. A flag seems cleaner.
<snip>
> > > > + flash@e8000000 {
> > > > + #address-cells = <1>;
> > > > + #size-cells = <1>;
> > > > + compatible = "cfi-flash";
> > > > + bank-width = <4>;
> > > > + device-width = <2>;
> > > > + reg = <0xe8000000 0x04000000>;
> > > > + monitor@0 {
> > > > + label = "Monitor";
> > >
> > > If you're using the "label" property, it would be normal to name the
> > > nodes simply "partition@address".
> >
> > I'm using the partition names that were used in the equivalent code
> > under arch/ppc. I'm trying to keep things looking the same as they used
> > to as much as possible. Besides, I don't see any others doing it that
> > way.
>
> My point is that the partition code uses either "label" (if present)
> or the node name for the partition name. If label properties are
> present, the node name is redundant information, so it seems more
> sensible to leave something generic there.
Ah, okay. I'll do:
partition@0 {
label = "Monitor";
reg = <0x00000000 0x00100000>;
}
partition@100000 {
label = "Primary Kernel";
reg = <0x00100000 0x00180000>;
}
...
> [snip]
> > > > + CUNIT: cunit@f200 {
> > >
> > > What is this device? It needs some sort of "compatible" value.
> >
> > Does it? Its a separate block of regs but its only used in the mpsc
> > node--its never looked up on its own by kernel code. Do all nodes need
> > "compatible" even when it'll never be used? (Just want to know.)
>
> Hrm.. if it's really just extra mpsc registers, should it be a
> seperate device, or just another range in the mpsc's "reg" property?
Okay, putting into the reg property makes sense. Its values will be
put into both mpsc@xxx 'reg' properties since its share. That doesn't
matter, correct?
Also, would you mind letting it go thru as it is now and I'll make a
separate patch to change this dts, the prpmc2800.dts, and related code
afterwards?
> [snip]
> > > > + mpp@f000 {
> > > > + compatible = "marvell,mv64360-mpp";
> > > > + reg = <0xf000 0x10>;
> > > > + };
> > > > +
> > > > + gpp@f100 {
> > > > + compatible = "marvell,mv64360-gpp";
> > > > + reg = <0xf100 0x20>;
> > > > + };
> > >
> > > What are these two devices?
> >
> > mpp == multi-purpose pins
> > gpp == general purpose pins
> >
> > They're really 2 separate reg blocks and are used for any number of
> > things including incoming PCI interrupts. I'm not accessing them
> > currently so I can eliminate them in this dts.
>
> Hrm. The device tree should generally describe the hardware, even if
> Linux doesn't use it yet. Are these basically some sort of GPIO
> interface? If so you should look at the new GPIO binding which has
> been proposed.
I should take the time to read up on that but neither of these are used
by the katana so I'll get rid of them for now. I can always put them
back.
> [snip]
> > > > + chosen {
> > > > + bootargs = "ip=on";
> > >
> > > The dts file should not include a "bootargs" value. The wrapper will
> > > fill that in from the kernel config.
> >
> > Actually, the kernel .config CONFIG_CMDLINE is only used by the kernel
> > when nothing is passed in from the bootwrapper. The bootwrapper gets
> > the cmdline from either bootargs or from the __builtin_cmdline section.
> >
> > I prefer to not rely on CONFIG_CMDLINE because it doesn't afford the
> > user a chance to edit or add to the cmdline when booting. You can always
> > type in the whole thing at the "Linux/PowerPC load: " prompt but I'd rather
> > see what is going to be used and then edit it if I want to. With
> > CONFIG_CMDLINE, it just gets used if nothing was passed in from the
> > bootwrapper.
> >
> > That raises an issue that I've for time time (I've tried to get rid of
> > __builtin_cmdline before but was unsuccessful).
> >
> > We currently have 3 possible sources for a default cmdline--seems like
> > at least one too many.
>
> Yes :(. I've looked at this before, though obviously I never got to
> figuring out what to do about it.
>
> > IMHO we need a way to change the default cmdline in the field so
> > sysadmins can change it per board and not have to type it in every time
> > they boot. /chosen/bootargs and __builtin_cmdline can both do that.
> > We don't need both, though. And, since bootargs is specified by OF
> > and documented in booting-without-of.txt, can we finally get rid of
> > __builtin_cmdline? I'd sure like to.
> >
> > We can probably get rid of CONFIG_CMDLINE too since everyone uses DTs
> > now and they can have a /chosen/bootargs. Anyone have a reason to keep
> > CONFIG_CMDLINE around?
> >
> > Would you mind elaborating on why you are opposed to /chosen/bootargs?
>
> Just because it's nasty for people to have to go in and change the dts
> just to change their default command line - which they might well want
> to do for things as simple as setting a default root device.
Yeah, but changing CONFIG_CMDLINE requires a kernel rebuild so
that's not great either. Modifying __builtin_cmdline is probably the
easiest way to change things in the field (assuming you have a zImage)
but its also the least standard way of the three. :(
Mark
^ permalink raw reply
* Re: [PATCH] MTD for Taco
From: Sean MacLennan @ 2008-01-16 21:25 UTC (permalink / raw)
Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <478AEB39.70106@pikatech.com>
Sean MacLennan wrote:
> How about adding a config option that lets you specify 8 bit access?
> Something like CONFIG_NDFC_8BIT_ACCESS. We could default it to no and
> put a little blurb that says something like:
>
> On some platforms the 32bit read/writes cause a machine access
> exception. If you get a machine access exception while reading the NAND
> bad block table, try turning on 8 bit access.
>
I know it would be better if 32 bit access just worked, but nobody
actively objected to this idea, so here is a patch ;)
Cheers,
Sean
Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
---
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 246d451..2809ded 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -153,11 +153,21 @@ config MTD_NAND_S3C2410_HWECC
config MTD_NAND_NDFC
tristate "NDFC NanD Flash Controller"
- depends on 4xx && !PPC_MERGE
+ depends on 4xx
select MTD_NAND_ECC_SMC
help
NDFC Nand Flash Controllers are integrated in IBM/AMCC's 4xx SoCs
+config NDFC_8BIT_ACCESS
+ bool "NDFC 8-bit access only"
+ depends on MTD_NAND_NDFC
+ default n
+ help
+ The NDFC supports 32 bit read/writes to the NAND to improve
+ performance. On some platforms this does not work. If you get
+ a machine access exception while reading the bad block table,
+ try setting this to Y.
+
config MTD_NAND_S3C2410_CLKSTOP
bool "S3C2410 NAND IDLE clock stop"
depends on MTD_NAND_S3C2410
diff --git a/drivers/mtd/nand/ndfc.c b/drivers/mtd/nand/ndfc.c
index 1c0e89f..ac06099 100644
--- a/drivers/mtd/nand/ndfc.c
+++ b/drivers/mtd/nand/ndfc.c
@@ -24,11 +24,13 @@
#include <linux/platform_device.h>
#include <asm/io.h>
+#ifndef CONFIG_PPC_MERGE
#ifdef CONFIG_40x
#include <asm/ibm405.h>
#else
#include <asm/ibm44x.h>
#endif
+#endif
struct ndfc_nand_mtd {
struct mtd_info mtd;
@@ -110,6 +112,37 @@ static int ndfc_calculate_ecc(struct mtd_info *mtd,
return 0;
}
+#ifdef CONFIG_NDFC_8BIT_ACCESS
+static void ndfc_read_buf(struct mtd_info *mtd, uint8_t *buf, int len)
+{
+ struct ndfc_controller *ndfc = &ndfc_ctrl;
+ uint8_t *p = (uint8_t *) buf;
+
+ for (; len > 0; len--)
+ *p++ = __raw_readb(ndfc->ndfcbase + NDFC_DATA);
+}
+
+static void ndfc_write_buf(struct mtd_info *mtd, const uint8_t *buf, int len)
+{
+ struct ndfc_controller *ndfc = &ndfc_ctrl;
+ uint8_t *p = (uint8_t *) buf;
+
+ for (; len > 0; len--)
+ __raw_writeb(*p++, ndfc->ndfcbase + NDFC_DATA);
+}
+
+static int ndfc_verify_buf(struct mtd_info *mtd, const uint8_t *buf, int len)
+{
+ struct ndfc_controller *ndfc = &ndfc_ctrl;
+ uint8_t *p = (uint8_t *) buf;
+
+ for (; len > 0; len--)
+ if (*p++ != __raw_readb(ndfc->ndfcbase + NDFC_DATA))
+ return -EFAULT;
+
+ return 0;
+}
+#else
/*
* Speedups for buffer read/write/verify
*
@@ -145,6 +178,7 @@ static int ndfc_verify_buf(struct mtd_info *mtd, const uint8_t *buf, int len)
return -EFAULT;
return 0;
}
+#endif
/*
* Initialize chip structure
@@ -236,6 +270,8 @@ static int ndfc_nand_probe(struct platform_device *pdev)
#ifndef CONFIG_PHYS_64BIT
ndfc->ndfcbase = ioremap((phys_addr_t)phys, res->end - res->start + 1);
+#elif defined(CONFIG_PPC_MERGE)
+ ndfc->ndfcbase = ioremap(phys, res->end - res->start + 1);
#else
ndfc->ndfcbase = ioremap64(phys, res->end - res->start + 1);
#endif
^ permalink raw reply related
* [Add mpc5121 support PATCH v2 4/8] Device tree for MPC5121 ADS
From: John Rigby @ 2008-01-16 21:37 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1200519447-25555-3-git-send-email-jrigby@freescale.com>
Minimal tree for mpc5121 ads.
Signed-off-by: John Rigby <jrigby@freescale.com>
---
arch/powerpc/boot/dts/mpc5121ads.dts | 116 ++++++++++++++++++++++++++++++++++
1 files changed, 116 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/mpc5121ads.dts
diff --git a/arch/powerpc/boot/dts/mpc5121ads.dts b/arch/powerpc/boot/dts/mpc5121ads.dts
new file mode 100644
index 0000000..fac1f15
--- /dev/null
+++ b/arch/powerpc/boot/dts/mpc5121ads.dts
@@ -0,0 +1,116 @@
+/*
+ * MPC5121E MDS Device Tree Source
+ *
+ * Copyright 2007 Freescale Semiconductor Inc.
+ *
+ * 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.
+ */
+
+/ {
+ model = "MPC5121ADS";
+ compatible = "fsl,mpc5121ads";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,5121@0 {
+ device_type = "cpu";
+ reg = <0>;
+ d-cache-line-size = <20>; // 32 bytes
+ i-cache-line-size = <20>; // 32 bytes
+ d-cache-size = <8000>; // L1, 32K
+ i-cache-size = <8000>; // L1, 32K
+ timebase-frequency = <d#49500000>; // 49.5 MHz (csb/4)
+ bus-frequency = <d#198000000>; // 198 MHz csb bus
+ clock-frequency = <d#396000000>;// 396 MHz ppc core
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <00000000 10000000>; // 256MB at 0
+ };
+
+ localbus@80000020 {
+ compatible = "fsl,mpc5121ads_localbus";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ reg = <80000020 40>;
+
+ ranges = <0 0 fc000000 04000000
+ 2 0 82000000 00008000>;
+
+ flash@0,0 {
+ compatible = "cfi-flash";
+ reg = <0 0 4000000>;
+ bank-width = <4>;
+ device-width = <1>;
+ };
+
+ board-control@2,0 {
+ compatible = "fsl,mpc5121ads-cpld";
+ reg = <2 0 8000>;
+ };
+ };
+
+ soc@80000000 {
+ compatible = "fsl,mpc5121-immr";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ #interrupt-cells = <2>;
+ ranges = <0 80000000 400000>;
+ reg = <80000000 400000>;
+ bus-frequency = <d#66000000>; // 66 MHz ips bus
+
+
+ // IPIC
+ // interrupts cell = <intr #, sense>
+ // sense values match linux IORESOURCE_IRQ_* defines:
+ // sense == 8: Level, low assertion
+ // sense == 2: Edge, high-to-low change
+ //
+ ipic: interrupt-controller@c00 {
+ compatible = "fsl,ipic";
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ reg = <c00 100>;
+ };
+
+ // 512x PSCs are not 52xx PSCs compatible
+ // PSC3 serial port A aka ttyPSC0
+ serial@11300 {
+ device_type = "serial";
+ compatible = "fsl,mpc5121-psc-uart";
+ port-number = <0>; // Logical port assignment
+ cell-index = <3>;
+ reg = <11300 100>;
+ interrupts = <28 8>; // actually the fifo irq
+ interrupt-parent = < &ipic >;
+ };
+
+ // PSC4 serial port B aka ttyPSC1
+ serial@11400 {
+ device_type = "serial";
+ compatible = "fsl,mpc5121-psc-uart";
+ port-number = <1>; // Logical port assignment
+ cell-index = <4>;
+ reg = <11400 100>;
+ interrupts = <28 8>; // actually the fifo irq
+ interrupt-parent = < &ipic >;
+ };
+
+ pscsfifo@11f00 {
+ compatible = "fsl,mpc512x-psc-fifo";
+ reg = <11f00 100>;
+ interrupts = <28 8>;
+ interrupt-parent = < &ipic >;
+ };
+ };
+};
--
1.5.3.5.726.g41a7a
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox