Re: [Bugme-new] [Bug 8778] New: Ocotea board: kernel reports access of bad area during boot with DEBUG_SLAB=y
On Wed, Jul 18, 2007 at 12:52:53AM -0700, Andrew Morton wrote: On Wed, 18 Jul 2007 00:07:50 -0700 (PDT) [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=8778 Summary: Ocotea board: kernel reports access of bad area during boot with DEBUG_SLAB=y Slab debugging is probably the culprit here. I had similar problem couple of years ago, not sure something has changed since then, haven't checked. When slab debugging was enabled it made memory allocations non L1 cache line aligned. This is very bad for DMA on non-coherent cache arches (PPC440 is one of those archs). I have a hack for EMAC which tries to workaround this problem: http://kernel.ebshome.net/emac_slab_debug.diff which might help. -- Eugene ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [Bugme-new] [Bug 8778] New: Ocotea board: kernel reports access of bad area during boot with DEBUG_SLAB=y
On Wed, Jul 18, 2007 at 08:41:10AM -0500, Josh Boyer wrote: On Wed, 2007-07-18 at 01:34 -0700, Eugene Surovegin wrote: On Wed, Jul 18, 2007 at 12:52:53AM -0700, Andrew Morton wrote: On Wed, 18 Jul 2007 00:07:50 -0700 (PDT) [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=8778 Summary: Ocotea board: kernel reports access of bad area during boot with DEBUG_SLAB=y Slab debugging is probably the culprit here. I had similar problem couple of years ago, not sure something has changed since then, haven't checked. When slab debugging was enabled it made memory allocations non L1 cache line aligned. This is very bad for DMA on non-coherent cache arches (PPC440 is one of those archs). I have a hack for EMAC which tries to workaround this problem: http://kernel.ebshome.net/emac_slab_debug.diff which might help. Would you be opposed to including that patch in mainline? Yes. I don't think it's the right way to fix this issue. IMO, the right one is to fix slab allocator. You cannot change all drivers to do this kind of cache flushing, and yes, I saw the same problem with PCI based NIC I tried on Ocotea at the time. -- Eugene ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [Bugme-new] [Bug 8778] New: Ocotea board: kernel reports access of bad area during boot with DEBUG_SLAB=y
On Wed, Jul 18, 2007 at 09:55:37AM -0700, Andrew Morton wrote: On Wed, 18 Jul 2007 08:59:40 -0700 Eugene Surovegin [EMAIL PROTECTED] wrote: On Wed, Jul 18, 2007 at 08:41:10AM -0500, Josh Boyer wrote: On Wed, 2007-07-18 at 01:34 -0700, Eugene Surovegin wrote: On Wed, Jul 18, 2007 at 12:52:53AM -0700, Andrew Morton wrote: On Wed, 18 Jul 2007 00:07:50 -0700 (PDT) [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=8778 Summary: Ocotea board: kernel reports access of bad area during boot with DEBUG_SLAB=y Slab debugging is probably the culprit here. I had similar problem couple of years ago, not sure something has changed since then, haven't checked. When slab debugging was enabled it made memory allocations non L1 cache line aligned. This is very bad for DMA on non-coherent cache arches (PPC440 is one of those archs). I have a hack for EMAC which tries to workaround this problem: http://kernel.ebshome.net/emac_slab_debug.diff which might help. Would you be opposed to including that patch in mainline? Yes. I don't think it's the right way to fix this issue. IMO, the right one is to fix slab allocator. You cannot change all drivers to do this kind of cache flushing, and yes, I saw the same problem with PCI based NIC I tried on Ocotea at the time. hm. It should be the case that providing SLAB_HWCACHE_ALIGN at kmem_cache_create() time will override slab-debugging's offsetting of the returned addresses. Or is the problem occurring with memory which is returned from kmalloc(), rather than from kmem_cache_alloc()? It's kmalloc, at least this is how I think skbs are allocated. Andrew, I don't have access to PPC hw right now (doing MIPS development these days), so I cannot quickly check that my theory is still correct for the latest kernel. I'd wait for the reporter to try my hack and then we can decide what to do. IIRC there was some provision in slab allocator to enforce alignment, when I was debugging this problem more then a year ago, that option didn't work. BTW, I think slob allocator had the same issue with alignment as slab with enabled debugging (at least at the time I looked at it). -- Eugene ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[PATCH 1/3] ibm_emac: fix section mismatch warnings
Fix Section mismatch warnings
Signed-off-by: Eugene Surovegin [EMAIL PROTECTED]
---
drivers/net/ibm_emac/ibm_emac_mal.c |3 +--
drivers/net/ibm_emac/ibm_emac_mal.h |3 +--
drivers/net/ibm_emac/ibm_emac_rgmii.c |2 +-
drivers/net/ibm_emac/ibm_emac_rgmii.h |2 +-
drivers/net/ibm_emac/ibm_emac_tah.c |2 +-
drivers/net/ibm_emac/ibm_emac_tah.h |2 +-
drivers/net/ibm_emac/ibm_emac_zmii.c |2 +-
drivers/net/ibm_emac/ibm_emac_zmii.h |2 +-
8 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ibm_emac/ibm_emac_mal.c
b/drivers/net/ibm_emac/ibm_emac_mal.c
index 6c0f071..cabd984 100644
--- a/drivers/net/ibm_emac/ibm_emac_mal.c
+++ b/drivers/net/ibm_emac/ibm_emac_mal.c
@@ -59,8 +59,7 @@ int __init mal_register_commac(struct ibm_ocp_mal *mal,
return 0;
}
-void __exit mal_unregister_commac(struct ibm_ocp_mal *mal,
- struct mal_commac *commac)
+void mal_unregister_commac(struct ibm_ocp_mal *mal, struct mal_commac *commac)
{
unsigned long flags;
local_irq_save(flags);
diff --git a/drivers/net/ibm_emac/ibm_emac_mal.h
b/drivers/net/ibm_emac/ibm_emac_mal.h
index 407d2ac..64bc338 100644
--- a/drivers/net/ibm_emac/ibm_emac_mal.h
+++ b/drivers/net/ibm_emac/ibm_emac_mal.h
@@ -223,8 +223,7 @@ void mal_exit(void) __exit;
int mal_register_commac(struct ibm_ocp_mal *mal,
struct mal_commac *commac) __init;
-void mal_unregister_commac(struct ibm_ocp_mal *mal,
- struct mal_commac *commac) __exit;
+void mal_unregister_commac(struct ibm_ocp_mal *mal, struct mal_commac *commac);
int mal_set_rcbs(struct ibm_ocp_mal *mal, int channel, unsigned long size);
/* Returns BD ring offset for a particular channel
diff --git a/drivers/net/ibm_emac/ibm_emac_rgmii.c
b/drivers/net/ibm_emac/ibm_emac_rgmii.c
index 53d281c..9dbb5e5 100644
--- a/drivers/net/ibm_emac/ibm_emac_rgmii.c
+++ b/drivers/net/ibm_emac/ibm_emac_rgmii.c
@@ -162,7 +162,7 @@ void rgmii_set_speed(struct ocp_device *ocpdev, int input,
int speed)
out_be32(dev-base-ssr, ssr);
}
-void __exit __rgmii_fini(struct ocp_device *ocpdev, int input)
+void __rgmii_fini(struct ocp_device *ocpdev, int input)
{
struct ibm_ocp_rgmii *dev = ocp_get_drvdata(ocpdev);
BUG_ON(!dev || dev-users == 0);
diff --git a/drivers/net/ibm_emac/ibm_emac_rgmii.h
b/drivers/net/ibm_emac/ibm_emac_rgmii.h
index 117ea48..971e458 100644
--- a/drivers/net/ibm_emac/ibm_emac_rgmii.h
+++ b/drivers/net/ibm_emac/ibm_emac_rgmii.h
@@ -37,7 +37,7 @@ struct ibm_ocp_rgmii {
#ifdef CONFIG_IBM_EMAC_RGMII
int rgmii_attach(void *emac) __init;
-void __rgmii_fini(struct ocp_device *ocpdev, int input) __exit;
+void __rgmii_fini(struct ocp_device *ocpdev, int input);
static inline void rgmii_fini(struct ocp_device *ocpdev, int input)
{
if (ocpdev)
diff --git a/drivers/net/ibm_emac/ibm_emac_tah.c
b/drivers/net/ibm_emac/ibm_emac_tah.c
index e287b45..3c2d5ba 100644
--- a/drivers/net/ibm_emac/ibm_emac_tah.c
+++ b/drivers/net/ibm_emac/ibm_emac_tah.c
@@ -63,7 +63,7 @@ int __init tah_attach(void *emac)
return 0;
}
-void __exit __tah_fini(struct ocp_device *ocpdev)
+void __tah_fini(struct ocp_device *ocpdev)
{
struct tah_regs *p = ocp_get_drvdata(ocpdev);
BUG_ON(!p);
diff --git a/drivers/net/ibm_emac/ibm_emac_tah.h
b/drivers/net/ibm_emac/ibm_emac_tah.h
index 3815394..ccf6491 100644
--- a/drivers/net/ibm_emac/ibm_emac_tah.h
+++ b/drivers/net/ibm_emac/ibm_emac_tah.h
@@ -55,7 +55,7 @@ struct tah_regs {
#ifdef CONFIG_IBM_EMAC_TAH
int tah_attach(void *emac) __init;
-void __tah_fini(struct ocp_device *ocpdev) __exit;
+void __tah_fini(struct ocp_device *ocpdev);
static inline void tah_fini(struct ocp_device *ocpdev)
{
if (ocpdev)
diff --git a/drivers/net/ibm_emac/ibm_emac_zmii.c
b/drivers/net/ibm_emac/ibm_emac_zmii.c
index 37dc8f3..2c0fdb0 100644
--- a/drivers/net/ibm_emac/ibm_emac_zmii.c
+++ b/drivers/net/ibm_emac/ibm_emac_zmii.c
@@ -215,7 +215,7 @@ void __zmii_set_speed(struct ocp_device *ocpdev, int input,
int speed)
out_be32(dev-base-ssr, ssr);
}
-void __exit __zmii_fini(struct ocp_device *ocpdev, int input)
+void __zmii_fini(struct ocp_device *ocpdev, int input)
{
struct ibm_ocp_zmii *dev = ocp_get_drvdata(ocpdev);
BUG_ON(!dev || dev-users == 0);
diff --git a/drivers/net/ibm_emac/ibm_emac_zmii.h
b/drivers/net/ibm_emac/ibm_emac_zmii.h
index 972e3a4..fad6d8b 100644
--- a/drivers/net/ibm_emac/ibm_emac_zmii.h
+++ b/drivers/net/ibm_emac/ibm_emac_zmii.h
@@ -40,7 +40,7 @@ struct ibm_ocp_zmii {
#ifdef CONFIG_IBM_EMAC_ZMII
int zmii_attach(void *emac) __init;
-void __zmii_fini(struct ocp_device *ocpdev, int input) __exit;
+void __zmii_fini(struct ocp_device *ocpdev, int input);
static inline void zmii_fini(struct ocp_device *ocpdev, int input)
{
if (ocpdev)
___
Linuxppc-embedded mailing list
Linuxppc
[PATCH 2/3] ibm_emac: improved PHY support
Original patch is from Jeff Haran [EMAIL PROTECTED] with my minor style
fixes. His comments follow:
The first problem was in the function that configures the PHY for
autonegotiation, genmii_setup_aneg(). The original code does a
read/modify/write of the autonegotiation advertizement register (reg 4),
followed by a read/modify/write of the control register (reg 0). While
the original code follows the proper procedure as per reading the IEEE
specs, what I found is that on at least one PHY model (National DP83843)
the read of the control register comes back with the soft reset bit set
(bit 15). Because of the read/modify/write operation, this causes the
write to write a 1 back to the reset bit, which initiates a software
reset of the PHY. This software reset causes the PHY to return to its
power up state which advertizes all modes of operation, thus negating
the write to the autoneg advertizement register. The modification is to
spin reading the control register until the soft reset bit is clear
before doing the modify/write.
The second problem was in the function that configures the PHY for
forced operation, genmii_setup_forced(). The original code initiates a
software reset operation via a write of a 1 to bit 15 of the control
register (reg 0), but then proceeds to do a second write to that same
register without waiting until that reset bit is cleared by the PHY
itself (which according to the IEEE specs indicates that the PHY reset
is complete). This is a violation of how one is supposed to use this
software reset feature of these PHYs and I believe was the cause of
mysterious, difficult to reproduce link failures that we've observed on
some of our systems that use this driver. The fix is to modify the
function so that it spins waiting for the reset bit to clear after doing
the soft reset and before doing the subsequent write.
Signed-off-by: Jeff Haran [EMAIL PROTECTED]
CC: Benjamin Herrenschmidt [EMAIL PROTECTED]
Signed-off-by: Eugene Surovegin [EMAIL PROTECTED]
---
drivers/net/ibm_emac/ibm_emac_phy.c | 60 ++-
1 files changed, 45 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ibm_emac/ibm_emac_phy.c
b/drivers/net/ibm_emac/ibm_emac_phy.c
index 9074f76..e57862b 100644
--- a/drivers/net/ibm_emac/ibm_emac_phy.c
+++ b/drivers/net/ibm_emac/ibm_emac_phy.c
@@ -22,6 +22,7 @@
#include asm/ocp.h
+#include ibm_emac_core.h
#include ibm_emac_phy.h
static inline int phy_read(struct mii_phy *phy, int reg)
@@ -34,11 +35,39 @@ static inline void phy_write(struct mii_phy *phy, int reg,
int val)
phy-mdio_write(phy-dev, phy-address, reg, val);
}
-int mii_reset_phy(struct mii_phy *phy)
+/*
+ * polls MII_BMCR until BMCR_RESET bit clears or operation times out.
+ *
+ * returns:
+ * = 0 = success, value in BMCR returned to caller
+ * -EBUSY = failure, RESET bit never cleared
+ * otherwise = failure, lower level PHY read failed
+ */
+static int mii_spin_reset_complete(struct mii_phy *phy)
{
int val;
int limit = 1;
+ while (limit--) {
+ val = phy_read(phy, MII_BMCR);
+ if (val = 0 !(val BMCR_RESET))
+ return val; /* success */
+ udelay(10);
+ }
+ if (val BMCR_RESET)
+ val = -EBUSY;
+
+ if (net_ratelimit())
+ printk(KERN_ERR emac%d: PHY reset timeout (%d)\n,
+ ((struct ocp_enet_private *)phy-dev-priv)-def-index,
+ val);
+ return val;
+}
+
+int mii_reset_phy(struct mii_phy *phy)
+{
+ int val;
+
val = phy_read(phy, MII_BMCR);
val = ~BMCR_ISOLATE;
val |= BMCR_RESET;
@@ -46,16 +75,11 @@ int mii_reset_phy(struct mii_phy *phy)
udelay(300);
- while (limit--) {
- val = phy_read(phy, MII_BMCR);
- if (val = 0 (val BMCR_RESET) == 0)
- break;
- udelay(10);
- }
- if ((val BMCR_ISOLATE) limit 0)
+ val = mii_spin_reset_complete(phy);
+ if (val = 0 (val BMCR_ISOLATE))
phy_write(phy, MII_BMCR, val ~BMCR_ISOLATE);
- return limit = 0;
+ return val 0;
}
static int genmii_setup_aneg(struct mii_phy *phy, u32 advertise)
@@ -102,8 +126,14 @@ static int genmii_setup_aneg(struct mii_phy *phy, u32
advertise)
}
/* Start/Restart aneg */
- ctl = phy_read(phy, MII_BMCR);
- ctl |= (BMCR_ANENABLE | BMCR_ANRESTART);
+ /* on some PHYs (e.g. National DP83843) a write to MII_ADVERTISE
+* causes BMCR_RESET to be set on the next read of MII_BMCR, which
+* if not checked for causes the PHY to be reset below */
+ ctl = mii_spin_reset_complete(phy);
+ if (ctl 0)
+ return ctl;
+
+ ctl |= BMCR_ANENABLE | BMCR_ANRESTART;
phy_write(phy, MII_BMCR, ctl);
return 0;
@@ -118,13 +148,13 @@ static int
[PATCH 3/3] ibm_emac: fix link speed detection change
Fix link speed detection change. Thanks to Stefan Roese [EMAIL PROTECTED] for finding this bug. CC: Stefan Roese [EMAIL PROTECTED] Signed-off-by: Eugene Surovegin [EMAIL PROTECTED] --- drivers/net/ibm_emac/ibm_emac_core.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/ibm_emac/ibm_emac_core.c b/drivers/net/ibm_emac/ibm_emac_core.c index 50035eb..f752e5f 100644 --- a/drivers/net/ibm_emac/ibm_emac_core.c +++ b/drivers/net/ibm_emac/ibm_emac_core.c @@ -926,7 +926,7 @@ static int emac_link_differs(struct ocp_enet_private *dev) int duplex = r EMAC_MR1_FDE ? DUPLEX_FULL : DUPLEX_HALF; int speed, pause, asym_pause; - if (r (EMAC_MR1_MF_1000 | EMAC_MR1_MF_1000GPCS)) + if (r EMAC_MR1_MF_1000) speed = SPEED_1000; else if (r EMAC_MR1_MF_100) speed = SPEED_100; ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: How to force the 1000M network interface work in 100M mode?(AMCC 440GX, board based on ocotea)
On Tue, Feb 13, 2007 at 10:34:17AM +0800, Lonsn wrote: Hi, all: We have design a new board based on AMCC ocotea board. The linux kernel version we use is 2.6.18 from kernel.org. The network interface is the same as ocotea(eth0 and eth1 work in SMII mode, eth2 and eth3 work in RGMII mode).The 1000Mbit ehernet physical transceiver chip is also CIS8201(VSC8201). These pins(ANEG_DIS,FRC_DPLX,MODE10,MODE100,MODE1000) of CIS8201 are set as 0. Maybe because of the signal integrity problem of the gigabit clockdata,eth3 doesn't work in 1000M mode(eth2 is ok). If we connect eth3 with a host which has 100M ethernet, then eth3 works in 100M mode well. If we connect eth3 with a host which has 1000M ethernet interface, then eth3 can recognize the link is 1000Mbit, but ping is not ok. So we want to force the eth3 work in 100M mode even eth3 is connected with a 1000M host.(we think the hardware is ok when eth3 works in 100M mode). We have used ethtool in the board and in the host to force the eth3 work in 100M mode, but failed. Maybe we can't change this setting in userspace? or we should changed the IBM_EMAC driver? Any suggestions? Use ethtool to limit advertised auto-negotiation mode or force 100 on _both_ ends of the link. Probably, when you forced 100, you did it only on 440GX side, that's why it failed. Personally, I prefer forcing link speed by tweaking advertised modes, this way you have to do this only on one side of the link. -- Eugene ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: JTAG emulator for MPC8548E (v2)
On Wed, Jan 24, 2007 at 08:57:19AM +0100, Laurent Pinchart wrote: The new unit works *mostly* fine. No debugging issue (not that I use it that much anyway, now that the board boots Linux), but still a flash programming issue. Programming the target parallel NOR flash works in slow JTAG mode, but not in faster mode using the internal workspace. I reported the problem several months ago and still haven't received any solution. Most likely problem isn't in BDI but in your setup. Depending on the particular chip model, to be able use workspace you must have initialized memory first. In fact, I'm pretty sure you haven't configured chip correctly to make workspace usable. I've been using BDI with various PowerPC and MIPS SoCs for many years. It's an excellent tool, you just have to use it correctly. -- Eugene ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: JTAG emulator for MPC8548E (v2)
On Wed, Jan 24, 2007 at 12:06:17PM +0100, Laurent Pinchart wrote: Hi Eugene, The new unit works *mostly* fine. No debugging issue (not that I use it that much anyway, now that the board boots Linux), but still a flash programming issue. Programming the target parallel NOR flash works in slow JTAG mode, but not in faster mode using the internal workspace. I reported the problem several months ago and still haven't received any solution. Most likely problem isn't in BDI but in your setup. Depending on the particular chip model, to be able use workspace you must have initialized memory first. In fact, I'm pretty sure you haven't configured chip correctly to make workspace usable. I've been using BDI with various PowerPC and MIPS SoCs for many years. It's an excellent tool, you just have to use it correctly. I wish it was that simple. Sorry, but it is. It's a low level tool which requires deep knowledge of the chip. It is probably a target processor configuration issue, as I can use the workspace if a) the target flash has already been programmed with U-Boot b) the BDI-2000 is misconfigured and fails to stop the target processor at startup. I can thus use the workspace when U-Boot initializes the processor. Wow, so you knew it wasn't BDI but a configuration problem from the start. So it all was just a FUD, how low. I had a look at U-Boot code and tried to initialize the processor registers with the same values, without luck. I asked Abatron's French distributor for technical support, and they haven't been able to help me. They made me try lots of different initialization sequences. Several people online sent me their configuration file, and none of them worked for me. So, there must be a configuration problem somewhere, but even Abatron's technical support haven't been able to find it. That's why I complained about their support in my e-mail. In your original e-mail you made it look like BDI has a bug in it, which in fact isn't true. Bad support might be a concern, I agree, but this doesn't make a tool bad, IMHO. -- Eugene ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Howto use PPC4xx memory to memory DMA
On Sun, Jan 21, 2007 at 09:28:34PM +, - Reyneke wrote: This seems to be one of those ongoing uncertainties. It seems commonly advocated that you shouldn't use it, but as yet I've found no suitable alternative. Really? Could you elaborate, why API described in Documentation/DMA-API.txt (e.g. Streaming DMA mappings) is not suitable for you?. -- Eugene ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: shared config registers and locking
On Wed, Dec 06, 2006 at 04:16:29PM +1100, Benjamin Herrenschmidt wrote: On my work in porting emac over to arch/powerpc (and make it work on SMP platforms since there's at least one coming, possibly too), I ended up with a problem with things like the workarounds for the EMAC loss of RX clock (CONFIG_IBM_EMAC_PHY_RX_CLK_FIX) that I think uncovers a more generic problem about access global system wide configuration registers in a race free way. BTW, Eugene, in the specific case of this RX clock problem causing the transmitter to stall... I've had this problem with sungem in the past and a few other drivers have to deal with it as well. The general approach seems to be a bit different, and if you think it can work for EMAC, I'll implement it that way in the driver I'm working on. The idea is rather to try to find magic bits to force the chip clocks on when there is no link, simply ack the fact that when there is no link, nothing gets transmitted and thus ignore tx timeouts. Doing netif_carrier_off() (which is the right thing to do when the link is down anyway) should cause the net stack to ignore them. Now, some chips (like GEM) have a problem recovering when the link finally comes back up and thus can have the transmitter stuck. That's why drivers like this will simply reset the TX side when the link is back up. That should be simpler and avoid the need for the workaround, don't you think ? No, it's not simpler. This just does not handle the problem this workaround was implemented for. You don't understand what this workaround does. It has nothing to do with TX path at all. It deals with RX one and the fact that in that particular MAC design whole RX domain is clocked from this clock, meaning some parts of EMAC just simply stop working. For some modes (e.g. SMII) this problem will not arise as this clock is always present, there are other cases when it's not needed (like sane PHY). For example, how do you handle PHY detection if you cannot talk to the PHY? Ben, my suggestion, before you start forking and cleaning up this code, understand what it does. -- Eugene ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: PPC440GX ethernet oddities
On Sun, Nov 26, 2006 at 08:05:49PM -0800, Jeff Mock wrote: I'm having a slightly strange behavior with PPC440GX ethernet, I'm looking for a little advice where I can poke around to see what's going on. I have a custom 440GX board, I use the two RGMII gigabit interfaces to two Vistesse PHYs. This works nicely. What is the CPU clock speed? The board has a large FPGA signal processor that is DMA'ing data into main memory, the PPC sends data from main memory out the ethernet interfaces. This all works well. For testing purposes I'm DMA'ing a pseudo random sequence at 80MB/s, sending this over ethernet on a TCP socket to a server machine and checking the sequence at the receiving end. Could you elaborate a little here. Is it a user-space program or some kernel mode code which does the copying? [snip] Only one of my four boxes shows this strange behavior, and only when the second ethernet port is connected to an ethernet switch. Everything still works properly, my 80MB/s pseudo random sequence is still generated by the FPGAs and checked by a server on the other end of the network connection. I let the ring buffer get as large as 64MB before failing, but the large ring buffer says that the network connection sometimes gets as much as 25MB behind the FPGA DMA, or 25/80 = 0.3125 seconds, which seems kind of crazy. Well, 300ms doesn't look particularly crazy to me given a data stream and the fact you are using non-realtime OSes on both ends. I look at ifconfig (busybox ifconfig) and I see no errors on the ethernet interface. Try ethtool -S, EMAC driver supports it. I'm guessing there might be some design problem or maybe just a problem with this one particular board that is causing errors that occasionally slows down the TCP connection, perhaps crosstalk between the two RGMII interfaces or maybe some interaction between the magnetics on the two ports, but I can't figure out where to look to measure errors on the physical ethernet interface. Can someone give me a hint about where to look for this problem? This is a 2.6.15 kernel. There are some stuff you can do: 1) Try another GigE switch, better if from the different vendor 2) Try another peer system you are streaming your data to (better with different GigE NIC) 3) Check if hw flow-control is enabled and try disabling it on both ends 4) Play with socket buffer sizes on both ends 5) And the final, but the most useful one - get a realtime capture of the TCP stream when your ring buffer starts growing. The best way is to get GigE switch which supports port mirroring or use special hw network analyzer. -- Eugene ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH v2 -- fixed changelog] [POWERPC] Add support for Rev. B of PowerPC 440SPe
On Wed, Nov 15, 2006 at 02:29:51PM -0800, Roland Dreier wrote: [snip] I think there have to be switches (or equivalently, look-up tables) since there's no regularity in where the DCRs/SDRs for the different PCIe ports are. Uhh, I was afraid you were gonna say this. HW guys don't make our life easier :). I think look-up tables are fine. It's not a fast path, is it? -- Eugene ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: 440SP External Interrupt IRQ
On Fri, Oct 06, 2006 at 03:27:38AM -0700, Jeff Stevens wrote: [snip] Based on their schematics, I assume: IRQ Line IRQ# IRQ048 IRQ149 IRQ250 IRQ351 IRQ452 IRQ553 No, this mapping doesn't depend on board shematics. This is fixed, see Universal Interrupt controller chapter in user manual. What is not fixed is mapping between IDSEL line which selects your PCI device and INTx# line from that PCI device to IRQx line in 440SP. -- Eugene ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] IBM GPIO driver for PowerPC 4xx is back from the dead
On Fri, Sep 29, 2006 at 09:46:04AM +0200, Jean-Baptiste Maneyrol wrote: Here is a patch for linux 2.6.18 that makes come back the old ibm gpio driver from 2.6.10. It is mainly useful for compatibility with old linux 2.4 from Montavista I think, because direct memory access seems the new way to go. In my opinion it should stay dead. And no, direct memory access isn't a way to go - how are you gonna provide synchronization in this case? Think about different processes mucking with GPIO registers. I think such low-level functionality should never be exported to the user-space in the first place. If your user-space needs such access make it explicit through procfs/sysfs (e.g. /proc/sys/dev/my_board/reset_that_device for GPIO pin wired to some chip reset) or just make a specific driver for your hardware. -- Eugene ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] IBM GPIO driver for PowerPC 4xx is back from the dead
On Fri, Sep 29, 2006 at 11:06:19AM +0200, Arnd Bergmann wrote:
+{
+ u32 cfg_reg;
+
+ if (device != 0)
+ return -ENXIO;
+
+#ifdef CONFIG_40x
+#ifdef DCRN_CHCR0
+ /*
+ * PPC405 uses CPC0_CR0 to select multiplexed GPIO pins.
+ */
+ cfg_reg = mfdcr(DCRN_CHCR0);
+ cfg_reg = (cfg_reg ~mask) | (data mask);
+ mtdcr(DCRN_CHCR0, cfg_reg);
+#endif
+#elif CONFIG_440GP
+ /*
+ * PPC440GP uses CPC0_GPIO to select multiplexed GPIO pins.
+ */
+ cfg_reg = mfdcr(DCRN_CPC0_GPIO);
+ cfg_reg = (cfg_reg ~mask) | (data mask);
+ mtdcr(DCRN_CPC0_GPIO, cfg_reg);
+#elif CONFIG_440GX
+ /*
+ * PPC440GX uses SDR0_PFC0 to select multiplexed GPIO pins
+ */
+ cfg_reg = SDR_READ(DCRN_SDR_PFC0);
+ cfg_reg = (cfg_reg ~mask) | (data mask);
+ SDR_WRITE(DCRN_SDR_PFC0, cfg_reg);
+#else
+#error This driver is only supported on PPC40x and PPC440 CPUs
+#endif
This prevents building a single kernel for multiple 440 version.
Please use a run-time check, or better get the necessary information
from the device tree.
440 kernels _are_ built for each particular 440 chip separately, and
not all these defines are even available simultaneously.
So, frankly, I don't understand your complain here. We don't support
single kernel image running on different 440s. Also, last time I
checked, 440 port wasn't using device tree as well.
--
Eugene
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Asterisk on Embedded Linux
On Tue, Sep 26, 2006 at 08:44:51AM +0200, Iwan Koenig wrote: Does anyone known how to compile Asterisk for a powerpc-processor? I have tryed: ./configure --target=powerpc-linux --host=powerpc-604-linux-gnu --prefix=/opt/packages And it gives following error: /root/pwlib/include/ptlib.h... configure: error: cannot check for file existence when cross compiling Ok! I see that it is trying to find the PWLIB-Library. Also, i have tryed to compile the pwlib. But it didn't work :(. For PWLIB i need the OpenLDAP, and when i have compiled the OpenLDAP, than needs PWLIB other packages... Also, have anyone ideas, how to compile Asterisk f?r a powerpc-processor with another way? Usually, a lot of open-source software isn't cross-compile friendly. The easiest way to actually build such stuff is to do a native build - yes, this will be slow, but you'll probably spend more time fixing makefiles and scripts (and will likely just gave up on this). -- Eugene ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[BUG] ibm_emac: kernel panic with CONFIG_SLOB=y
On Tue, Aug 01, 2006 at 10:40:11PM +0200, Karol Lewandowski wrote: Hi, I'm getting reproductible kernel panic when I use smaller SLOB allocator (instead of SLAB). This is reproductible but very randomly -- sometimes it happens during bootup, sometimes few minutes later. Hardware is custom board with IBM405EP (very close to Bubingna, just no RTC): # cat /proc/cpuinfo processor : 0 cpu : 405EP clock : 200MHz revision : 9.80 (pvr 5121 0950) bogomips : 199.47 machine : MagicBox plb bus clock : 100MHz pci bus clock : 25MHz Enabling SLAB instead of SLOB fixes this, so I assume this is driver issue. This is probably the same issue I had with SLAB debugging. In short, those allocators aren't compatible with non-coherent cache archs (like 4xx), because driver assumes at least L1 cache line alignment for all allocated memory. For more info, you can read this post: http://ozlabs.org/pipermail/linuxppc-embedded/2006-February/022087.html -- Eugene
Problem with ibm_emac driver
On Thu, Jul 20, 2006 at 01:32:42PM -0500, Ian Remmler wrote: Hi, I'm having a problem with the ibm_emac driver for the built in gigabit ethernet on the 440gx. I was hoping someone could shed some light or at least point me in the right direction. I'm using a GMS P502 board runing 2.4.27-pre3 (from GMS). The problem we are having is this: when we push data over the emac interface (eth0 and eth1 both show the problem), we sporadically get a MAL: Rx descriptor error... from mal_rxde in ibm_ocp_mal.c. Occasionally, the interface will freeze up for a few seconds. An ifconfig down/up will bring it back, but from then on it will freeze up again right away. It looks to me like this error indicates that we're out of RX buffers, but I don't how we would be running out. I'm no kernel or networking expert, but I thought the TCP stack would take care of throttling itself to prevent that sort of thing. I would appreciate any help. No idea what GMS is, but they seem to use old buggy EMAC driver. You can use kernel.org's 2.6 or 2.4.31 backport at http://kernel.ebshome.net/ As a side note, TCP cannot throttle _all_ Rx traffic, think for example of a fast box sending a lot of small UDP packets to the 440gx. -- Eugene
page locking in PowerPC cores
On Tue, Jul 18, 2006 at 04:03:50AM -0700, Parav Pandit wrote: Hi, We allocate memory for DMA operation on PCI device using pci_alloc_constistent(). I want to know how this function is boil down to the actual instruction which locks the page in the RAM so that it cannot be paged out and dma can do its work. This is trivial - you can start with looking at the implementation. Can anybody tell me which instructions do we use to set this page entry in TLB and page table? What bit gets set in the PTE for this? Why do you need this page in TLB? In general you don't have to worry about _any_ memory you allocated in the kernel to be paged out. -- Eugene
Interrupt occurs but UIC0 MSR is still 0
On Thu, Jun 15, 2006 at 05:38:19PM -0400, Chris Dumoulin wrote: Hi All, I'm working with a 2.6 linux kernel in a board with a PPC405 in a Virtex II Pro FPGA. I'm trying to generate interrupts and handle them in a device driver that I've written. Here is the sequence of events that happen currently: 1. I generate an interrupt by setting registers in an interrupt controller we've got in the FPGA (it's a Xilinx LogicCORE OPB Interrupt Controller). 2. The function do_IRQ, in arch/powerpc/kernel/irq.c, is called. 3. ppc_md.get_irq is called from do_IRQ. 4. ppc_md.get_irq points to ppc4xx_pic_get_irq in arch/ppc/syslib/ppc4xx_pic.c. 5. ppc4xx_pic_get_irq reads the MSR from UIC0 to determine the IRQ. In my case, the MSR is all zero, so ppc4xx_pic_get_irq returns -1. 6. After this, we return from the interrupt, and do_IRQ is called again and again, going through the same steps indefinitely. I don't think ppc4xx_pic.c is correct file for Xilinx Virtex II Pro. You should be using xilinx_pic.c probably. -- Eugene
Pinned TLB entries with 2.6 linux kernel on PPC4xx
On Thu, Jun 01, 2006 at 03:29:37PM -0400, Chris Dumoulin wrote: Does the idea of creating pinned TLB entries (ones that will never be overwritten) make sense for a PPC4xx (specifically PPC405) 2.6 linux kernel? If so, how would this be accomplished? 44x kernel already pins some TLB entries, 40x may use this approach to increase performance (I use this in my internal 2.4 tree quite successfully). Old 2.4 trees (linuxppc-2.4 or devel_2_4) have TLB pinning support for 40x, you can look at the implementation there. -- Eugene
undefined symbols of modules
On Tue, May 30, 2006 at 09:45:46AM +0200, Josef Angermeier wrote: Hello, when i try to compile my kernel extension as modul, i get some undefined references. But a look in System.map shows, that the relevant symbols are defined in the main kernel. Why then those undefined references ? Symbol must be exported to be available for modules, just being listed in System.map isn't enough. Try adding EXPORT_SYMBOL(...) for those undefined references. -- Eugene
MPC8xx: resolution of gettimeofday() ?
On Fri, May 19, 2006 at 10:08:26AM +0200, Steven Scholz wrote: Eugene, what is the resolution of gettimeofday() for an MPC8xx? IIUC then the decrementer is used to generate the timer interrupts every 10ms. This decrementer runs at cpuclk/16. Thus with 80MHz CPU clock has a resolution of 16/80MHz = 200ns and overflows every 5 ticks. But is this decrementer used to update xtime? Will gettimeofday() have a resolution of 200ns? How about linux 2.4 where xtime is a struct timeval rather then struct timespec? Usually on PPC we use timebase to interpolate time between Decrementer interrupts. In this case gettimeofday resolution is determined by timebase resolution which is quite high (megahertz range). Sorry. I don't understand. What do you mean with timebase? Is there a second timer/counter? PowerPC has a facility called timebase. This is 64-bit counter which can be accessed using special instructions (mftb, mftbu on 32-bit PPC). Counter resolution depends on particular chip implementation, some use core clock, other use bus clock... It's similar to the time-stamp counter in Intel CPUs (accessed with rdtsc instruction). Please, refer to PPC arch manuals for more information. Also, if you really interested in how gettimeofday() is implemented, why don't you look at the source code yourself? -- Eugene
Calculating virtual address from physical address
On Wed, May 10, 2006 at 07:04:30AM -0400, David H. Lynch Jr. wrote: [skip] Unless I am completely mistaken, machine checks are not cause by softwded are or programming errors, they are cause by hardware problems, You can trivially trigger MachineChecks without any hardware problems - just map some non-existent physical address and try to access it. -- Eugene
Viable PPC platform?
On Wed, May 10, 2006 at 12:11:41PM +0100, Alex Zeffertt wrote: On Tue, 9 May 2006 10:15:20 -0700 Eugene Surovegin ebs at ebshome.net wrote: On Tue, May 09, 2006 at 05:41:01PM +0100, Alex Zeffertt wrote: On Tue, 09 May 2006 10:38:19 -0400 geneSmith gd.smth at gmail.com wrote: I have a ppc405gpr system with 64M ram and 4Meg flash in a AM29LV320. Is this a viable platform for linux? Can a filesystem (JFFS2?) be put this flash type? I would create an initrd and put every file that doesn't need to be changed persistently into it instead of JFFS2. After many years of doing embedded Linux stuff I still don't understand why people are so fond of initrd. For temporary stuff - tempfs is much better and flexible. For r/o stuff - just make separate MTD partition (cramfs, squashfs) and mount it directly as root. Both options will waste significantly less memory. Okay, let me qualify my answer. It depends on whether you need to make persistent changes to the filesystem in flash. If so, and given that your flash is only 4MB, I would recommend moving files to somewhere else, e.g. an initrd, because if when a JFFS2 FS is approaching full, you often find that writes to flash hang while JFFS2 searches for blocks to use as a scratchpad. This has been my experience anyway. If you don't need to make persistent changes to files, then I'm sure cramfs in flash as a rootfs would work well, with a tmpfs partition mounted on /tmp and /var. You missed my point. initrd should be stored somewhere - in the same flash . In this case there is no reason to actually use initrd instead of just direct mount from flash. -- Eugene
Viable PPC platform?
On Tue, May 09, 2006 at 05:41:01PM +0100, Alex Zeffertt wrote: On Tue, 09 May 2006 10:38:19 -0400 geneSmith gd.smth at gmail.com wrote: I have a ppc405gpr system with 64M ram and 4Meg flash in a AM29LV320. Is this a viable platform for linux? Can a filesystem (JFFS2?) be put this flash type? I would create an initrd and put every file that doesn't need to be changed persistently into it instead of JFFS2. After many years of doing embedded Linux stuff I still don't understand why people are so fond of initrd. For temporary stuff - tempfs is much better and flexible. For r/o stuff - just make separate MTD partition (cramfs, squashfs) and mount it directly as root. Both options will waste significantly less memory. -- Eugene
Viable PPC platform?
On Tue, May 09, 2006 at 03:52:20PM -0700, Howard, Marc wrote: In message 20060509171520.GA10886 at gate.ebshome.net you wrote: After many years of doing embedded Linux stuff I still don't understand why people are so fond of initrd. For temporary stuff - tempfs is much better and flexible. For r/o stuff - just make separate MTD partition (cramfs, squashfs) and mount it directly as root. Both options will waste significantly less memory. Agreed. And if somebody wants to see facts and numbers, please see http://www.denx.de/wiki/view/DULG/RootFileSystemSelection One size does not fit all. We have an application with a very large file system. It can't fit in the available flash, however we do have a ton of RAM (512MB). NFS is not an option nor is it desirable (latency and availability issues). Boot time is not an issue either in this case as it takes the equipment many minutes to calibrate and initialize. initrd also solves another problem. The combined uBoot multi-image although huge (32 MB) represents a complete system firmware snapshot in a single (huge) file. By selecting the appropriate uImage the host can guarantee the linux build, device drivers, application version and FPGA firmware revs (the embedded board is rebooted to guarantee a repeatable starting state). This makes revision control for the overall system much easier, especially since the host system is running windoze. This all is nice provided you use network for boot. IMHO this is quite _rare_ setup (especially Windows host!!!). For 99% of embedded designs this is obviously not a viable option. -- Eugene
Fw: Configuring PCI w/ 44x
On Wed, May 03, 2006 at 01:11:26PM -0400, Stephen Winiecki wrote: Eugene Surovegin ebs at ebshome.net wrote on 05/02/2006 07:49:16 PM: On Tue, May 02, 2006 at 04:58:32PM -0400, Stephen Winiecki wrote: I have a question regarding configuring PCI with 44x. Using 2.6.17-rc3 as a reference, PCI_CONFIG is defined for the 44x defconfigs, and Kconfig is not enabled to reflect/change the setting for 44x. When I update arch/ppc/Kconfig to enable configuring or not configuring PCI with 44x, and then don't configure it, the kernel won't compile: Hmm, you cannot disable PCI for 44x in the current 2.6. It's always enabled. If you changed Konfig to be able to do so, why are you complaining here? It's not enough to just change Konfig, you have to modify Ocotea port as well. Look for example how this is handled for 85xx. Patches are welcome. -- Eugene I was first wondering if for some reason defaulting/forcing PCI to always be configured for 44x was intentional. Yes. I think it's quite obvious from the way it's configured in Konfig. I was second reporting the fact that if a change is made to not configure PCI for 44x, the kernel will not compile. Well, I don't follow you here. You made the wrong change and report here that it broke the build. How is this interesting? Your report looked as you discovered a bug, when in fact you broke the build yourself. And again, if disabling PCI is important to you you are welcome to submit patches instead of sending misleading e-mails to this list. -- Eugene
U-boot1.1.4 porting problem on PPC 440GX
On Tue, May 02, 2006 at 03:32:59PM -0700, pravin wrote: Hi All, I build uboot1.1.4 for ocotea_config and run on an ocotea without SPD on DIMMS (SDRAM) and It works. We manufactured another board derived from Ocotea Ref design, 440GX processor and on baord SDRAM (DIMMS) 256MB discrete parts. I use the same Uboot1.1.4 for this board. It boots upto calling the relocate_code in cpu/ppc4xx/start.S and hangs. The same code works well on Ocotea. I run the memory tests and it passed all. Any idea why this could hang and never finish the relocate_code function. Trying relocating Uboot to SDRAM memory to get the C environment and run from memory. Any help would be appreciated. Any idea if i need any special code because of the discrete parts of SDRAM on our board. You can use Ocotea code (kernel and/or U-Boot) as-is for your board only in one case - your board is _identical_ to Ocotea. I doubt that this is the case, so you have to modify U-Boot and/or kernel board support code to accommodate any differences between Ocotea and your design. Start with asking your hardware people about such differences. -- Eugene
Configuring PCI w/ 44x
On Tue, May 02, 2006 at 04:58:32PM -0400, Stephen Winiecki wrote: I have a question regarding configuring PCI with 44x. Using 2.6.17-rc3 as a reference, PCI_CONFIG is defined for the 44x defconfigs, and Kconfig is not enabled to reflect/change the setting for 44x. When I update arch/ppc/Kconfig to enable configuring or not configuring PCI with 44x, and then don't configure it, the kernel won't compile: Hmm, you cannot disable PCI for 44x in the current 2.6. It's always enabled. If you changed Konfig to be able to do so, why are you complaining here? It's not enough to just change Konfig, you have to modify Ocotea port as well. Look for example how this is handled for 85xx. Patches are welcome. -- Eugene
PPC 405GPr support in linux 2.4.32
On Wed, Apr 26, 2006 at 04:57:21PM -0700, Stephen Williams wrote: Is there a git tree for main line 2.4 maintenance (against which I could maintain patches) git://git.kernel.org/pub/scm/linux/kernel/git/marcelo/linux-2.4.git -- Eugene
PPC 405GPr support in linux 2.4.32
On Wed, Apr 26, 2006 at 04:35:40PM -0700, Matt Porter wrote: linuxppc-2.4 tree to linux-2.4. Oh, and Marcelo didn't want to take new stuff into linux-2.4 at that time either. There's still rsync://source.mvista.com/linuxppc-2.4 available with the 405gpr/sycamore support. There are bigger problems with 4xx support in 2.4 mainline than just missing some chips support. Some parts which are already in 2.4 (e.g. ethernet driver) are of non-production quality. I can imagine Marcelo agreeing to commit 405GPr/405EP support as this change shouldn't break anything, but this will not make 2.4 support really useful for real world deployments. I think we are stuck with maintaining our own 2.4 trees with backports from 2.6. This is what I do myself of all our products (and yeah, diff between stock 2.4.32 and my internal version has already grown quite big to be acceptable for 2.4 inclusion). -- Eugene
PPC 405GPr support in linux 2.4.32
On Thu, Apr 27, 2006 at 11:32:45AM -0700, Stephen Williams wrote: Eugene Surovegin wrote: There are bigger problems with 4xx support in 2.4 mainline than just missing some chips support. Some parts which are already in 2.4 (e.g. ethernet driver) are of non-production quality. I can imagine Marcelo agreeing to commit 405GPr/405EP support as this change shouldn't break anything, but this will not make 2.4 support really useful for real world deployments. I think we are stuck with maintaining our own 2.4 trees with backports from 2.6. This is what I do myself of all our products (and yeah, diff between stock 2.4.32 and my internal version has already grown quite big to be acceptable for 2.4 inclusion). Of course we are going to have to keep our own per-board trees. but the blatantly common stuff, like the core 405gpr support and certain drivers, might as well go in if the gatekeeper can be convinced. You and I both probably have huge drivers for custom devices hanging off our PPCs, with various hacks to squeeze extra performance out. These make our transition to 2.6 difficult, and surely we are not alone. Well, personally, I don't migrate to 2.6 not because I have many custom drivers in my tree (if they are properly written, migration is relatively easy), but because 2.6 in my opinion isn't production ready, at least for architectures I work with. 2.6 is slower, bigger, is constantly being broken by huge amount of changes, etc. I spent enough time making 2.4 work on our hardware given limitations and requirements put on performance, resources etc. I just don't have time to go through this cycle again. And I'm not talking about PPC stuff, I mean mostly generic stuff - filesystems, scheduling, networking, etc. So 2.4 is going to be around for a while longer for us, so we might as well make an effort to keep the house in some sort of order. It serves no one to keep these fixes a secret:-) They aren't secret, but I can understand the simple fact that 2.4 is closed for a new stuff, we might not like that (although I do, just look at the mess stable 2.6 is :). There is a point in every piece of software life-cycle when you have to stop adding features. 2.4 is already at this point, and we should accept that. -- Eugene
How do you make linux 2.6.10 U-Boot aware?
On Wed, Apr 26, 2006 at 11:54:13AM -0700, Howard, Marc wrote: Hi, I'm using MontaVista linux 4.01 for the PPC440GX which is based on 2.6.10. It doesn't read the bootargs from U-Boot however. Does anyone out there have a synopsis of what needs to be modified (bd_info, etc.) to make this work with a 2.6.10 based release? Please, take a look at Ocotea port in the latest 2.6 kernel. It supports booting from PIBS and U-Boot. --
[PATCH] ppc32: add 440GX erratum 440_43 workaround
This patch adds workaround for PPC 440GX erratum 440_43. According to
this erratum spurious MachineChecks (caused by L1 cache parity) can
happen during DataTLB miss processing. We disable L1 cache parity
checking for 440GX rev.C and rev.F
Signed-off-by: Eugene Surovegin ebs at ebshome.net
diff --git a/arch/ppc/platforms/4xx/ocotea.c b/arch/ppc/platforms/4xx/ocotea.c
index f841972..554776d 100644
--- a/arch/ppc/platforms/4xx/ocotea.c
+++ b/arch/ppc/platforms/4xx/ocotea.c
@@ -331,7 +331,7 @@ static void __init ocotea_init(void)
void __init platform_init(unsigned long r3, unsigned long r4,
unsigned long r5, unsigned long r6, unsigned long r7)
{
- ibm44x_platform_init(r3, r4, r5, r6, r7);
+ ibm440gx_platform_init(r3, r4, r5, r6, r7);
ppc_md.setup_arch = ocotea_setup_arch;
ppc_md.show_cpuinfo = ocotea_show_cpuinfo;
diff --git a/arch/ppc/syslib/ibm440gx_common.c
b/arch/ppc/syslib/ibm440gx_common.c
index a7dd55f..f6cc168 100644
--- a/arch/ppc/syslib/ibm440gx_common.c
+++ b/arch/ppc/syslib/ibm440gx_common.c
@@ -2,7 +2,7 @@
* PPC440GX system library
*
* Eugene Surovegin eugene.surovegin at zultys.com or ebs at ebshome.net
- * Copyright (c) 2003, 2004 Zultys Technologies
+ * Copyright (c) 2003 - 2006 Zultys Technologies
*
* 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
@@ -282,3 +282,14 @@ int ibm440gx_show_cpuinfo(struct seq_fil
return 0;
}
+void __init ibm440gx_platform_init(unsigned long r3, unsigned long r4,
+ unsigned long r5, unsigned long r6,
+ unsigned long r7)
+{
+ /* Erratum 440_43 workaround, disable L1 cache parity checking */
+ if (!strcmp(cur_cpu_spec-cpu_name, 440GX Rev. C) ||
+ !strcmp(cur_cpu_spec-cpu_name, 440GX Rev. F))
+ mtspr(SPRN_CCR1, mfspr(SPRN_CCR1) | CCR1_DPC);
+
+ ibm44x_platform_init(r3, r4, r5, r6, r7);
+}
diff --git a/arch/ppc/syslib/ibm440gx_common.h
b/arch/ppc/syslib/ibm440gx_common.h
index a2ab9fa..a03ec60 100644
--- a/arch/ppc/syslib/ibm440gx_common.h
+++ b/arch/ppc/syslib/ibm440gx_common.h
@@ -29,6 +29,10 @@ #include syslib/ibm44x_common.h
void ibm440gx_get_clocks(struct ibm44x_clocks*, unsigned int sys_clk,
unsigned int ser_clk) __init;
+/* common 440GX platform init */
+void ibm440gx_platform_init(unsigned long r3, unsigned long r4, unsigned long
r5,
+ unsigned long r6, unsigned long r7) __init;
+
/* Enable L2 cache */
void ibm440gx_l2c_enable(void) __init;
diff --git a/include/asm-ppc/reg_booke.h b/include/asm-ppc/reg_booke.h
index 00ad9c7..4944c0f 100644
--- a/include/asm-ppc/reg_booke.h
+++ b/include/asm-ppc/reg_booke.h
@@ -237,6 +237,7 @@ #define SPRN_CSRR1 SPRN_SRR3 /* Critical
#endif
/* Bit definitions for CCR1. */
+#defineCCR1_DPC0x0100 /* Disable L1 I-Cache/D-Cache parity
checking */
#defineCCR1_TCS0x0080 /* Timer Clock Select */
/* Bit definitions for the MCSR. */
IIC troubles w/ ppc4xx (STB04)
On Sun, Apr 16, 2006 at 03:41:28AM +0200, Andre Draszik wrote: Hi, I am having trouble using iic_smbus_quick() of i2c/busses/i2c-ibm-iic.c I am trying to i2c_probe() to probe for some devices, which at the end calls iic_smbus_quick(). Basically, I get a Data Machine Check as soon as iic-directcntl is accessed. Actually, this register is not described in the (old) documentation I have. Does everything else work? I mean ordinary I2C access like read/write. If everything else is fine, just comment out that iic_smbus_quick() call or just don't use i2c_probe(). It's a hack anyway, because I2C spec has no provision for probing. I wrote this bit-banging implementation just to get some people off my back :). BTW, I never tested my driver on STB4, maybe ocp_defs are wrong (in this case i2c will not work at all). -- Eugene
IIC troubles w/ ppc4xx (STB04)
On Sun, Apr 16, 2006 at 07:33:45AM +0200, Andre Draszik wrote: I see :) So if that doesn't work, what is the preferred way of testing for existence of a device in a kernel module? Should I just unconditionally i2c_client_register() a static struct and then i2c_master_send() to see if it works? There is no generic reliable way to detect that some i2c device exists on the bus. Even if smbus_quick worked it cannot guarantee that device you found is actually device you are expected - same i2c address can be used by different devices. Frankly, I never saw this as a problem in embedded world, because most of the time you have a custom built kernel for your particular board or family of the boards, and you already know what devices might be there, so just trying to access those devices from whatever drivers and/or user-space applications you wrote is sufficient. In fact, I never needed i2c probing in any of almost dozen different embedded projects I wrote firmware/Linux board support for. So, I think unconditional i2c_master_send() should be fine, just be prepared to handle errors in case device isn't there or broken. -- Eugene
Slab errors on 4xx (STB04)
On Mon, Apr 10, 2006 at 12:33:56AM +0200, Andre Draszik wrote: Since it _seems_ to work nevertheless - is CONFIG_DEBUG_SLAB known to be broken on this platform? Yes, it's very likely that CONFIG_DEBUG_SLAB is the culprit here. This config option changes allocation alignment (it becomes not L1 cache line aligned). For 4xx which has non-coherent L1 cache this with almost 100% probability will break DMA, resulting in memory corruption. You can try changing __dma_sync() to do flush_dcache_range() even for DMA_FROM_DEVICE case. However, do this only to check this theory, not as a permanent solution :). -- Eugene
where do applications get loaded in virtual memory on a 4xx?
On Mon, Apr 03, 2006 at 08:46:13AM -0400, Ralph Blach wrote: I would like to know where in virtual memory application get loaded. I can do an NM and see the address in an a.out file? How do these address actually translate to 4xx virtual address? There is nothing 4xx specific here. cat /proc/pid/maps -- Eugene
Yosemite board ala, PPC405EP
On Wed, Mar 08, 2006 at 02:45:54PM -0500, Jeff.Fellin at rflelect.com wrote: I have been using an Albatron BDI for a PPC405GP board in a project. According to the documentation I've read the Yosemite board is identical register wise to the 405GP, except for two sets of EMAC registers. My problem is when I use the Albatron BDI using the register definitions for the 405GP, the BDI cannot communicate with the 405EP. Anyone have experience with usingg the BDI for the PPC 405EP? AFAIK, Yosemite is 440EP, not 405EP. And 440EP is quite different from 405GP. -- Eugene
scatter/gather DMA and cache coherency
On Thu, Feb 16, 2006 at 05:51:20PM +1030, Phil Nitschke wrote: Hi, I've been using a PCI device driver developed by a third party company. It uses a scatter/gather DMA I/O to transfer data from the PCI device into user memory. When using a buffer size of about 1 MB, the driver achieves a transfer bandwidth of about 60 MB/s, on a 66 MHz, 32-bit bus. The problem is, that sometimes the data is corrupt (usually on the first transfer). We've concluded that the problem is related to cache coherency. The Artesyn 2.6.10 reference kernel (branched from the kernel at penguinppc.org) must be built with CONFIG_NOT_COHERENT_CACHE=y, as Artesyn have never successfully verified operation with hardware coherency enabled. My understanding is that their Marvel system controller (MV64460) supports cache snooping, but their Linux kernel support hasn't caught up yet. So if I understand my situation correctly, the device driver must use software-enforced coherency to avoid data corruption. Is this correct? What currently happens is this: The buffers are allocated with get_user_pages(...) After each DMA transfer is complete, the driver invalidates the cache using __dma_sync_page(...) No, buffers must be invalidated _before_ DMA transfer, not after. Also, don't use internal PPC functions like __dma_sync_page. Please, read Documentation/DMA-API.txt for official API. -- Eugene
scatter/gather DMA and cache coherency
On Fri, Feb 17, 2006 at 12:22:11AM +1030, Phil Nitschke wrote: ES == Eugene Surovegin ebs at ebshome.net writes: ES On Thu, Feb 16, 2006 at 05:51:20PM +1030, Phil Nitschke wrote: Hi, I've been using a PCI device driver developed by a third party company. It uses a scatter/gather DMA I/O to transfer data from the PCI device into user memory. When using a buffer size of about 1 MB, the driver achieves a transfer bandwidth of about 60 MB/s, on a 66 MHz, 32-bit bus. The problem is, that sometimes the data is corrupt (usually on the first transfer). We've concluded that the problem is related to cache coherency. The Artesyn 2.6.10 reference kernel (branched from the kernel at penguinppc.org) must be built with CONFIG_NOT_COHERENT_CACHE=y, as Artesyn have never successfully verified operation with hardware coherency enabled. My understanding is that their Marvel system controller (MV64460) supports cache snooping, but their Linux kernel support hasn't caught up yet. So if I understand my situation correctly, the device driver must use software-enforced coherency to avoid data corruption. Is this correct? What currently happens is this: The buffers are allocated with get_user_pages(...) After each DMA transfer is complete, the driver invalidates the cache using __dma_sync_page(...) ES No, buffers must be invalidated _before_ DMA transfer, not ES after. Also, don't use internal PPC functions like ES __dma_sync_page. Please, read Documentation/DMA-API.txt for ES official API. [snip] 2/. I'm not _sure_ I understand terms like software-enforced coherency, non-consistent platforms, etc. So should I be looking at the API in section I or II of DMA-API.txt ? (I think section 'Id') Non-consistent means without cache snooping. On such platforms you have to use software enforced cache coherency or non-cached memory for DMA. 3/. I think I did not explain the DMA process clearly enough. This is how the third party documentation says the driver should be used (my annotations in parenthesis): - Allocate and lock buffer into physical memory (Call driver ioctl function to map user DMA buffer using get_user_pages()) - Configure DMA chain - Start DMA transfer (Set ID of the DMA descriptor that the DMA controller shall load first. Allow target to perform bus-mastered DMA into platform memory) - Wait for DMA transfer to complete (interrupt signals end of transfer from target) - Do Cache Invalidate (Call driver ioctl which calls __dma_sync_page(), to invalidate the cache prior to reading the buffer from the host CPU. Then copy data from buffer into other user memory.) - Unlock and free buffer from physical memory (Call device driver ioctl function which calls free_user_pages()) So is __dma_sync_page being called by their driver routines at the wrong time? As I said before, invalidate must be done _before_ initiating DMA transfer. If that third party documentation states otherwise, that means people who wrote it didn't understand how caches work. Consider the following scenario, you allocated page from kernel page allocator. Some parts of that page are in L1 cache and are dirty (e.g. because they were recently used), I'm assuming cache is write-back. You start DMA transfer and go on with some other tasks. For some reason, those dirty lines are forced out of cache, e.g. because L1 needs cache lines for some other data. During this write back you overwrite already DMAed data and end up with memory corruption. 4/. The DMA-API.txt says: Memory coherency operates at a granularity called the cache line width. In order for memory mapped by this API to operate correctly, the mapped region must begin exactly on a cache line boundary and end exactly on one (to prevent two separately mapped regions from sharing a single cache line). Given that we're not relying on cache snooping, and we call functions to invalidate the cache, does this statement still apply? Yes. Cache line granularity is very important for software enforced cache coherency. I'd recommend you look at any driver which works on non-coherent cache platform like 4xx or 8xx for good examples on how to manage cache coherency. -- Eugene
scatter/gather DMA and cache coherency
On Fri, Feb 17, 2006 at 08:49:50AM +1030, Phil Nitschke wrote: GB == Buhler, Greg greg.buhler at viasat.com writes: GB Phil, If the third party DMA driver is not proprietary send it GB over and I'd be happy to take a look at it for you. I don't think I can, due to this in the code: /* Copyright Notice: This computer software is proprietary to VMETRO. The use of this software is governed by a licensing agreement. VMETRO retains all rights under the copyright laws of the United States of America and other countries. This software may not be furnished or disclosed to any third party and may not be copied or reproduced by any means, electronic, mechanical, or otherwise, in whole or in part, without specific authorization in writing from VMETRO. Copyright (c) 1996-2005 by VMETRO, ASA. All Rights Reserved. */ [snip] /* Set the right GPL license to avoid warrnings then loading the driver */ MODULE_LICENSE(GPL); I'm not a lawyer, but what they are doing is of questionable legality at least, they circumvent Linux protection but claiming that module is GPL, but that copyright notice isn't GPL compatible. If you are going to sell systems with this module, you may have trouble with your customers, because you'll clearly be violating GPL. My experience with such vendors - their code isn't worth the trouble (I have yet to see good Linux driver written by hw vendor) and I'd rather avoid them completely. -- Eugene
Gigabit ethernet support of ppc440gx in 2.6 and 2.4
On Wed, Feb 15, 2006 at 02:08:52PM +0800, ? wrote: We want to get a data rate of 600Mbits/s over gigabit ethernet of ppc440gx. How about the status of support to ppc440gx GigE in Linux kernel? Which kernel version should we select? 2.6 or 2.4? GigE support for 440GX is in official 2.6. Patch for 2.4 is available at http://kernel.ebshome.net. If you don't feel comfortable dealing with kernel patches, I'd recommend 2.6 Effective Ethernet throughput highly depends on packet size. For some small packet sizes 600Mb/s is theoretically impossible over GigE. I achieved 900+ Mb/s TCP throughput with my driver (packets around 4K long) and using sendfile(2) based test application. -- Eugene
MMU is enabled in u-boot?
On Wed, Feb 15, 2006 at 10:58:08PM +0100, dibacco at inwind.it wrote: u-boot works with MMU enabled? Why is it needed, if so? Depends on CPU. Some CPUs just don't work without MMU. -- Eugene
Gigabit ethernet support of ppc440gx in 2.6 and 2.4
On Thu, Feb 16, 2006 at 12:45:15PM +0800, ? wrote: Does the TCP/IP Acceleration Hardware of 440GX have been supported in official 2.6 kernel? How about the CPU utilization when you get 900+Mb/s? Since we want to do something such as simple datas codec at the same time. My driver (both 2.4 and 2.6) supports TCP/UDP checksum offload. No TSO yet. I don't remember exact CPU load numbers, but it was less than 20% for TX case (Ocotea was transmitting data). -- Eugene
440gx GPIO
On Tue, Feb 14, 2006 at 08:48:56AM -0500, Ed Goforth wrote: I posted the original from home, and didn't have the contents of the config register. It is cfg 0x00103e00 Which I interpret as having bit 11 set: 1 Enable GPIO11 as GPIO11 from the manual. I originally tried to call ioremap64(PPC440GX_GPIO0_ADDR,) directly, but got unresolved symbol ioremap64. From inspection of ioremap(), the fixup for 0x4700 translates to 0x14700, and I get the same values in my code as I see from a /proc/ocotea/gpio. Is my approach valid? It seems to be. Try writing the same GPIO output register value as you read from it (without clearing bit 11). Also, try changing some other GPIO bit (e.g. one which is not connected in your design). Maybe board hangs exactly because you set GPIO bit 11 low :). Also, connect scope to that GPIO pin and see what is really going on. -- Eugene
440gx GPIO
On Tue, Feb 14, 2006 at 12:20:35AM -0500, Ed Goforth wrote: I am struggling with a problem and I hope someone can give me some pointers. We have a custom board with a 440gx. I need to drive GPIO11 low. The best as I can tell from the docs, I need to set bit 11 of the TCR to 1 and bit 11 of the OR to 0 to do this. Check that this pin is enabled as GPIO not as a function pin (SDR0_PFC0 register). Also, just to be sure that you remapped GPIO registers correctly, use ioremap64 with full physical address (not just low 32 bits). -- Eugene
system tick in PPC
On Sun, Feb 12, 2006 at 06:47:15PM +0100, dibacco at inwind.it wrote: Someone knows how the jiffies is incremented in PPC? Using PIT, Decrementer or what? I think you should be looking at include/asm-powerpc/time.h, set_dec() get_dec() functions. timer_interrupt() uses set_dec(). In short, usually PPC uses decrementer, but some sub-archs are special. -- Eugene
CONFIG_DEBUG_SLAB and non-cache coherent CPUs
Hi! I just wanted to let people on this list know that turning slab debugging may cause slab corruption on non-coherent cache CPUs (4xx, 8xx). The reason for this is that usually drivers which use DMA assume L1 cache line alignment for buffers (e.g. returned from alloc_skb). Unfortunately, with slab debugging enabled this is no longer the case, and during cache invalidates we corrupt slab cache (or at least slab poison markers). I tried to define ARCH_KMALLOC_MINALIGN and/or ARCH_SLAB_MINALIGN but it didn't work (and even if it did, it'd effectively disabled slab debugging anyway). I don't understand why slab debugging feature has to change allocation alignment, as it can be obviously implemented without breaking this alignment. Probably the reason is the usual one - nobody cares/cared about non-coherent cache CPUs and saving couple of bytes was more important :). Anyway, I made a hack for my EMAC driver: http://kernel.ebshome.net/emac_slab_debug.diff which helps with this problem, although other drivers may experience the same problem when used on 4xx/8xx with slab debugging enabled. In fact, 3COM 905 driver crashed Ocotea in this configuration too. -- Eugene
IBM_EMAC_PHY_RX_CLK_FIX depends on non-existing option 440GR
On Tue, Feb 07, 2006 at 11:14:49PM +0100, Adrian Bunk wrote: Jean-Luc Leger reiga at dspnet.fr.eu.org reported the following: from drivers/net/Kconfig: config IBM_EMAC_PHY_RX_CLK_FIX bool PHY Rx clock workaround depends on IBM_EMAC (405EP || 440GX || 440EP || 440GR) - maybe this is 440GP ? The non-existing CONFIG_440GR is also present in the driver itself. Is this a typo or a not yet merged platform? Not yet merged platform. -- Eugene
Yosemite/440EP why are readl()/ioread32() setup to readlittle-endian?
On Thu, Feb 02, 2006 at 09:09:17AM +0100, Peter Korsgaard wrote:
On 2/2/06, Kumar Gala galak at kernel.crashing.org wrote:
What is the preferred way of accessing non-PCI devices then? Direct
pointer access?
No direct pointer access is bad. On PPC You can use
in_be{8,16,32}/out_be{8,16,32}
What about arch independent drivers? Are there any generic approach
for this or do you have to stick to ugly #ifdefs to decide between
in_be32/inl ?
I'm curious, could you give an example of such arch independent
driver?
--
Eugene
Yosemite/440EP why are readl()/ioread32() setup to readlittle-endian?
On Thu, Feb 02, 2006 at 09:35:56AM -, Jenkins, Clive wrote: A driver for some device that could be connected to (or plugged into) a variety of different platforms of different architecture. A driver for a core that could be implemented within an FPGA on multiple platforms. Well, this is all nice but I was wondering about _real_ examples. When you are talking about connecting or plugging you have to keep in mind actual bus interconnect. So far AFAIK PCI (and derivatives) are the only cross-arch bus. So basically, you have no _real_ life examples, so I'm wondering why people need this arch-independent non-PCI I/O accessors for something which doesn't exist. I think the reason why Linux doesn't have this stuff follows from the previous paragraph. -- Eugene
Yosemite/440EP why are readl()/ioread32() setup toreadlittle-endian?
On Thu, Feb 02, 2006 at 10:28:05AM -, Jenkins, Clive wrote: And what about direct connection to the local bus of the processor chip? What about it? It's _chip_ specific. And the way your generic stuff will be connected to it will be chip or even design specific (yeah, hw guys sometime wire it in some weird way). I fail to see how you can have _generic_ I/O accessors for this case. So basically, you have no _real_ life examples, so I'm wondering why people need this arch-independent non-PCI I/O accessors for something which doesn't exist. I could draft a design of such an example, and I could realise that design by building it. But I don't want to spend the time and money doing it. Neither do I want to spend time researching _real_ examples. It is much easier to allow for obvious possibilities that _could_ exist and probably will exist if they don't already, than searching the world. It's not as easy as you might think :). It must be arch/bus/device/board specific in the general case. You can try _specifying_ semantics for such generic accessors and _then_ we can discuss this and I will very likely give you _real_ world examples when they will not work. Why be PCI-centric now, when we have experienced no end of problems because Linux was x86-centric in the past? Well, until there is another _standard_ bus which is used on different archs, having _generic_ cross-arch I/O accessors doesn't make any sense. I don't understand your point about not being PCI specific. It's of no relevance what you or I think about PCI and x86. I have ported several standard bus drivers to chip specific interconnects (MIPS and PPC) and in every case code was bus or even board specific. I'm pretty much aware about problems and solutions. But this is not what is being discussed here. Until there is _standard_ for such interconnects (like PCI) everything else is just wishful thinking. -- Eugene
Yosemite/440EP why are readl()/ioread32() setuptoreadlittle-endian?
On Thu, Feb 02, 2006 at 11:26:22AM -, Jenkins, Clive wrote:
Regardless of what standards or hardware might exist, I would be
happy if Linux provided alternatives to readl()... that converted
between big-endian and cpu-endian, so that I could write in my
driver, for example:
static inline my_readl(...)
{
#if (my interconnect is PCI or other little-endian)
return(readl(...));
#else
return(readl_be(...));
#endif
}
That must make my driver more portable in future circumstances
Huh?
If you re-read this thread, you'll notice that I was responding to
e-mail where original poster did NOT want to do exactly this in his
driver. But you are suggesting what we were discussing on how to
_avoid_. I'm really confused, what is your point?
What I was talking, in short, that if we _really_ want generic non-PCI
accessors, we need something similar to the way IDE layer defines its
I/O operations - bunch of per-bus/device function pointers which can
be overridden depending on arch, bus and the way peripheral is wired.
--
Eugene
Yosemite/440EP why are readl()/ioread32() setup to readlittle-endian?
On Thu, Feb 02, 2006 at 07:37:01AM -0700, Matt Porter wrote:
I mentioned the BE iomap variants that are being used on some non-pci
parisc devices already. I'll give a partial example of something that
is non-pci yet arch-independent.
Take a non-pci EHCI core (yes, I know it's little endian by definition
but suspend reality for a second). You can create an arch-independent
EHCI driver that uses the platform bus by using the iomap accessors.
Since these cores are licensed every day by XYZ startups for their
latest gee-whiz SoC, it reasons that you'll see the same core on
multiple licensable SoC architectures. I've seen one such thing
on MIPS.
We also know that major semiconductor companies do the same thing
for their peripherals in some cases. They're just as willing to
buy somebody else's USB core, for example. So, having a BE
non-pci device cross platform isn't a stretch.
Take a look at drivers/scsi/53c700.{c,h}. That generic driver
is why BE iomap accessors were added. It's in the process of
being shared between parisc and m68k.
Matt, my problem with this approach is that it repeats the same
old mistakes but in BE-mode, e.g. _assuming_ some access mode and
hard-coding it into the driver. I fail to see how assuming big-endian
is any better than assuming little-endian in this case. And this is
not _portable_ in my book, no matter what some people want me to
believe.
This fails miserably when for example you have a bus which does byte
swaps in every half-word. And yes, I have such device on my table and
I have to port PCMCIA/PCI drivers to this SoC :).
Here is how inb looks like:
static inline u8 fpi_inb(unsigned long port)
{
port ^= 1;
return inb(port);
}
IMO, truly portable and driver independent I/O accessors should be
implemented as a function pointers on per-bus (at least) basis which
can be overridden by arch or board code. In this case we can get rid
of ugly ifdefs in driver code :).
--
Eugene
Yosemite/440EP why are readl()/ioread32() setup to readlittle-endian?
On Wed, Feb 01, 2006 at 10:04:15AM -0800, David Hawkins wrote: Matt, In the same vein as the readl()/writel() question, what are the assumptions regarding memcpy_toio and memcpy_fromio? If the memcpy_to/fromio operations are intended only for access to PCI devices, then they should also inherently perform little-endianness conversion. For the test driver I was working on, I did *not* find this the case, eg. I implemented the test driver read() and write() using the memcpy_to/fromio calls, and the data transfers occur in big-endian (well, 'native' mode, since I also test the same test driver with the PCI adapter in an x86 system). If memcpy_to/fromio can be used in a more general context, then I can see why they operate in native mode. Just looking for enlightenment. This commands IIRC are intended for copying chunk of _bytes_. There are no issues with endianess for bytes, e.g. they work just like ordinary memcpy. -- Eugene
Yosemite/440EP why are readl()/ioread32() setup to read little-endian?
On Wed, Jan 25, 2006 at 10:26:55AM -0800, David Hawkins wrote: Hi Stefan, readl() and ioread32() read the registers in little-endian format! Correct. That's how it is implemented on all platforms. Think for example of an pci device driver. Using these IO functions, the driver will become platform independent, running without modifications on little- and big-endian machines. Ok, I figured that was probably the case. Thanks for the confirmation. Should I just be using pointers for remapped processor registers, and only use readl(), ioread32(), etc, on external memory? That's how I do it. Only use readl() and friends for pci spaces (or other little endian memory mapped areas). I took a look at the Yosemite network and USB drivers, it looks like the authors of those drivers chose to use in_be32() and out_be32(). Personally I like the concept of using pointers, or more usefully pointers to structure overlays for device control. However, the impression I have is that this is inherently more non-portable than using the readl()/writel(), ioread32()/iowrite32(), and now I guess I can add in_be32()/out_be32() to that list. But if you use pointers, thats good enough for me! use in_/out_ accessors, not pointers. Look at other 4xx drivers (i2c, emac) Also, you don't have worry about this code being non-portable, because every chip has it's own GPIO impl anyway. -- Eugene
Yosemite/440EP is there a global interrupt enable mask?
On Wed, Jan 25, 2006 at 10:30:30AM -0800, David Hawkins wrote: Hi Stephan, You seem to have used the wrong IRQ number though. Please see below. You are using the External IRQ 8. This results in IRQ number 19 of the 2nd interrupt controller of the 440ep. So please try (19+32) as the IRQ number upon requesting the interrupt. Yep, that was it! Now while looking at some of the other drivers, I noticed the use of the following syntax: unsigned long flags; local_irq_save(flags); ... mfdcr, mtdcr, etc operations ... local_irq_restore(flags); which is treating the operations on the DCRs as a critical section. I should probably be doing the same when I enable the external IRQs and modify the GPIO registers. You have to use locks if you access GPIO registers, because other bits can be used by other device drivers, although there is no drivers in the official tree which use GPIO (I have tons of them in my private tree and I added global gpio_lock to serialize GPIO access). DCRs are a little different, there are separate DCR for different peripherals, so generally, you don't have to use locks, because those DCR accesses are implicitly bound to particular device anyway and device owns them. -- Eugene
Yosemite/440EP why are readl()/ioread32() setup to read little-endian?
On Wed, Jan 25, 2006 at 11:36:20AM -0800, David Hawkins wrote: [snip] I haven't looked for it yet, but do you know if there is a driver for the Yosemite board I2C temperature sensor already written? I have no idea what temp sensor is used in this board, but it's very likely that lm-sensors project already has a driver for it (look under Drivers/Hardware Monitoring support). -- Eugene
Yosemite/440EP is there a global interrupt enable mask?
On Wed, Jan 25, 2006 at 11:46:41AM -0800, David Hawkins wrote: Hi Eugene, Now while looking at some of the other drivers, I noticed the use of the following syntax: unsigned long flags; local_irq_save(flags); ... mfdcr, mtdcr, etc operations ... local_irq_restore(flags); which is treating the operations on the DCRs as a critical section. I should probably be doing the same when I enable the external IRQs and modify the GPIO registers. You have to use locks if you access GPIO registers, because other bits can be used by other device drivers, although there is no drivers in the official tree which use GPIO (I have tons of them in my private tree and I added global gpio_lock to serialize GPIO access). What kind of global lock; a spinlock? yes, spinlock. What is the advantage of say using the gpio_lock, rather than the irq_save/restore sequence above - which is what is used in the emac and usb code? emac doesn't use GPIO registers :). Also, if there is no IRQ code accesses GPIO registers, you don't need IRQ disabling lock, and spin_lock effectively becomes just a preemption lock. Personally, I use spinlocks just out of habit, I think it's a good style, even if you know your chip doesn't support SMP (but some day might :). DCRs are a little different, there are separate DCR for different peripherals, so generally, you don't have to use locks, because those DCR accesses are implicitly bound to particular device anyway and device owns them. Right, but I was accessing the DCR for the UIC status register, which, I assume, is also used by the Linux IRQ handling subsystem. DO NOT access UIC registers directly. DO NOT. Well, ok perhaps that is not a good example, I have not tested whether the IRQ handler in the example code I posted needs to clear the UIC1_SR bit, or whether the Linux IRQ handling code already takes care of it. I suspect the latter, since the IRQ could be shared, and Linux needs to go through and call all handlers on that IRQ line. But in a debug context of reading those registers, I would expect some form of lock holding would be recommended. Do you happen to know if the Linux IRQ handling code uses a lock? 4xx IRQ code takes care of all this. You don't need to mess with UIC registers. 4xx PIC code doesn't use locks because it's being called from special context (IRQs disabled), 4xx doesn't support SMP and PIC code owns those DCRs. I'm just learning, so feel free to enlighten me. What drivers do you have in your 'private' tree that you might be willing to share? Nothing that can be of interest for a general public. They are board-specific (lots of bit-banging SPI stuff). All other drivers I wrote are already in public tree. -- Eugene
Regarding booting 440 gr board / ibm emac driver
On Fri, Dec 30, 2005 at 06:21:11AM -0500, Kiran Kumar.A wrote: Hello Benjamin, This is kiran here. I'm working on 440GR (Yosemite) board to boot linux-2.6.13.4. Everything works fine execpt for MAC address. I saw the code in arch/ppc/platforms/4xx/yosemite.c; the code to copy the MAC addr from board info structure seems to be in place. I am using IBM emac driver written by you. Linux boots up fine and in the booting messages , I see that the MAC addr is displayed as all zeroes. Also, the ifconfig displays the MAC address as all zeroes. Could you please throw some light on the same. First, check that the code which copies MAC address is actually executed. Second, check _what_ is being copied by this code. Maybe board info structure contains zeros. Do we need to modify the driver for MAC address issue?? No, you don't need to modify EMAC driver. -- Eugene
ibm emac driver update
On Mon, Dec 12, 2005 at 05:26:34PM +, Simon Haynes wrote: I am running a Ebony board with linux-2.6.12-rc1 and I amd having intermittent network problems. Having searched the archives it would seem that the driver for the IBM EMAC is buggy ? I have tried to patch my kernel with http://kernel.ebsname.net/emac/4xx_napi_emac.diff I believe this is almost a total driver re-write. Is this correct ? After having a couple of problems applying the patch, Kconfig and ibm_emac_core.c. I fixed up the original code and applied the patch. On compilation the build fails with missing references to kzalloc, which I guess I could easily fix with kmalloc and memset. However there is also an undefined field, dcr_base, in the ocp_func_mal_data structure. This structure appears to be defined in include/asm/ibm_ocp.h and this file does not appear to be changed by the patch. I guess this patch is for a later kernel. Can anyone point me in the direction of a suitable patch for this kernel ? I'm not sure about 2.6.12-rc1, but you can try GIT tree/patches at http://kernel.ebshome.net. Hint: you can assume that in addition to emac_3-2.6-28.diff, there are also emac_3-2.6-NN.diff (NN 28) on my website which were made for earlier kernel versions :). Alternatively, you can backport all relevant stuff from current 2.6 or you can pay someone to do this for you. -- Eugene
Netpoll controller support for PPC EMAC driver
On Thu, Dec 08, 2005 at 03:34:15PM +0300, Ruslan V. Sushko wrote: This patch adds netpoll controller support for PPC EMAC driver Signed-off-by: Ruslan V. Sushko rsushko at ru.mvista.com NAK. Please see long discussion on netdev couple of months ago about netpoll and how it is horribly broken. In short, to implement netpoll support in EMAC driver requires full locking re-do (all locks must be IRQ disabling). I'm not gonna do this, because it's wrong approach. If you want netpoll support, figure out a way to do this correctly, without penalizing users of EMAC driver by switching to IRQ locks. -- Eugene
Can I operate i2c device in a tasklet?
On Fri, Dec 02, 2005 at 02:20:07PM +0800, Sam Song wrote: Hi all, I found that once I operated i2c bus like read from i2c device in 2.4.31 kernl in a interrupt handler or tasklet, kernel panic would happen. Is there any way to make it in such case? I need to write sth on RTC alarm register with an interrupt event. .. Scheduling in interrupt kernel BUG at sched.c:564! You cannot access i2c layer from non-process context. Please, search mail list archives, this matter was discussed countless number of times. -- Eugene
[PATCH] ppc32: remove jumbo member from ocp_func_emac_data
This patch removes not needed anymore jumbo member from
ocp_func_emac_data. Jumbo frame support is handled by PPC4xx EMAC
driver internally now.
Signed-off-by: Eugene Surovegin ebs at ebshome.net
---
arch/ppc/platforms/4xx/ibm440gx.c |2 --
arch/ppc/platforms/4xx/ibm440sp.c |1 -
include/asm-ppc/ibm_ocp.h |1 -
3 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/arch/ppc/platforms/4xx/ibm440gx.c
b/arch/ppc/platforms/4xx/ibm440gx.c
index 956f45e..d24c09e 100644
--- a/arch/ppc/platforms/4xx/ibm440gx.c
+++ b/arch/ppc/platforms/4xx/ibm440gx.c
@@ -58,7 +58,6 @@ static struct ocp_func_emac_data ibm440g
.wol_irq= 65, /* WOL interrupt number */
.mdio_idx = -1, /* No shared MDIO */
.tah_idx= 0,/* TAH device index */
- .jumbo = 1,/* Jumbo frames supported */
};
static struct ocp_func_emac_data ibm440gx_emac3_def = {
@@ -72,7 +71,6 @@ static struct ocp_func_emac_data ibm440g
.wol_irq= 67, /* WOL interrupt number */
.mdio_idx = -1, /* No shared MDIO */
.tah_idx= 1,/* TAH device index */
- .jumbo = 1,/* Jumbo frames supported */
};
OCP_SYSFS_EMAC_DATA()
diff --git a/arch/ppc/platforms/4xx/ibm440sp.c
b/arch/ppc/platforms/4xx/ibm440sp.c
index feb17e4..71a0117 100644
--- a/arch/ppc/platforms/4xx/ibm440sp.c
+++ b/arch/ppc/platforms/4xx/ibm440sp.c
@@ -31,7 +31,6 @@ static struct ocp_func_emac_data ibm440s
.wol_irq= 61, /* WOL interrupt number */
.mdio_idx = -1, /* No shared MDIO */
.tah_idx= -1, /* No TAH */
- .jumbo = 1,/* Jumbo frames supported */
};
OCP_SYSFS_EMAC_DATA()
diff --git a/include/asm-ppc/ibm_ocp.h b/include/asm-ppc/ibm_ocp.h
index 9c21de1..ddce616 100644
--- a/include/asm-ppc/ibm_ocp.h
+++ b/include/asm-ppc/ibm_ocp.h
@@ -63,7 +63,6 @@ struct ocp_func_emac_data {
int wol_irq;/* WOL interrupt */
int mdio_idx; /* EMAC idx of MDIO master or -1 */
int tah_idx;/* TAH device index or -1 */
- int jumbo; /* Jumbo frames capable flag */
int phy_mode; /* PHY type or configurable mode */
u8 mac_addr[6];/* EMAC mac address */
u32 phy_map;/* EMAC phy map */
[PATCH] ppc32: fix treeboot image entrypoint
Correctly specify treeboot based image entrypoint. Currently makefile uses $(ENTRYPOINT) which isn't defined anywhere. Each board port sets entrypoint-$(CONFIG_BOARD_NAME) instead. Without this patch I cannot boot Ocotea (PPC440GX eval board) anymore. I was getting random OS panic errors from OpenBIOS for a while, but with current kernel I get them all the time (probably because image became bigger). Signed-off-by: Eugene Surovegin ebs at ebshome.net --- diff --git a/arch/ppc/boot/simple/Makefile b/arch/ppc/boot/simple/Makefile index 82df88b..f3e9c53 100644 --- a/arch/ppc/boot/simple/Makefile +++ b/arch/ppc/boot/simple/Makefile @@ -262,11 +262,11 @@ $(images)/zImage.initrd-STRIPELF: $(obj) skip=64 bs=1k $(images)/zImage-TREE: $(obj)/zvmlinux $(MKTREE) - $(MKTREE) $(obj)/zvmlinux $(images)/zImage.$(end-y) $(ENTRYPOINT) + $(MKTREE) $(obj)/zvmlinux $(images)/zImage.$(end-y) $(entrypoint-y) $(images)/zImage.initrd-TREE: $(obj)/zvmlinux.initrd $(MKTREE) $(MKTREE) $(obj)/zvmlinux.initrd $(images)/zImage.initrd.$(end-y) \ - $(ENTRYPOINT) + $(entrypoint-y) $(images)/zImage-PPLUS: $(obj)/zvmlinux $(MKPREP) $(MKBUGBOOT) $(MKPREP) -pbp $(obj)/zvmlinux $(images)/zImage.$(end-y)
[PATCH] ibm_emac: fix graceful stop timeout handling
This patch fixes graceful stop timeout handling in PPC4xx EMAC driver.
Currently, when we stop TX/RX channels we just do some number of loops
without relying on actual spent time. This has finally bitten me on
one of our systems (heavy network traffic during start up, RX channel
is stopped several times to configure multicast list).
Graceful channel stop can take up to 1 frame time, so I've added
device specific timeout counter which depends on current link speed
and calls to udelay() to really wait required amount of time before
giving up.
Signed-off-by: Eugene Surovegin ebs at ebshome.net
---
drivers/net/ibm_emac/ibm_emac_core.c | 38 ++
drivers/net/ibm_emac/ibm_emac_core.h |2 ++
2 files changed, 31 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ibm_emac/ibm_emac_core.c
b/drivers/net/ibm_emac/ibm_emac_core.c
index eb7d694..1da8a66 100644
--- a/drivers/net/ibm_emac/ibm_emac_core.c
+++ b/drivers/net/ibm_emac/ibm_emac_core.c
@@ -65,7 +65,7 @@
*/
#define DRV_NAMEemac
-#define DRV_VERSION 3.53
+#define DRV_VERSION 3.54
#define DRV_DESCPPC 4xx OCP EMAC driver
MODULE_DESCRIPTION(DRV_DESC);
@@ -158,6 +158,14 @@ static inline void emac_report_timeout_e
#define PHY_POLL_LINK_ON HZ
#define PHY_POLL_LINK_OFF (HZ / 5)
+/* Graceful stop timeouts in us.
+ * We should allow up to 1 frame time (full-duplex, ignoring collisions)
+ */
+#define STOP_TIMEOUT_101230
+#define STOP_TIMEOUT_100 124
+#define STOP_TIMEOUT_1000 13
+#define STOP_TIMEOUT_1000_JUMBO73
+
/* Please, keep in sync with struct ibm_emac_stats/ibm_emac_error_stats */
static const char emac_stats_keys[EMAC_ETHTOOL_STATS_COUNT][ETH_GSTRING_LEN] =
{
rx_packets, rx_bytes, tx_packets, tx_bytes, rx_packets_csum,
@@ -222,10 +230,12 @@ static void emac_tx_disable(struct ocp_e
r = in_be32(p-mr0);
if (r EMAC_MR0_TXE) {
- int n = 300;
+ int n = dev-stop_timeout;
out_be32(p-mr0, r ~EMAC_MR0_TXE);
- while (!(in_be32(p-mr0) EMAC_MR0_TXI) n)
+ while (!(in_be32(p-mr0) EMAC_MR0_TXI) n) {
+ udelay(1);
--n;
+ }
if (unlikely(!n))
emac_report_timeout_error(dev, TX disable timeout);
}
@@ -248,9 +258,11 @@ static void emac_rx_enable(struct ocp_en
if (!(r EMAC_MR0_RXE)) {
if (unlikely(!(r EMAC_MR0_RXI))) {
/* Wait if previous async disable is still in progress
*/
- int n = 100;
- while (!(r = in_be32(p-mr0) EMAC_MR0_RXI) n)
+ int n = dev-stop_timeout;
+ while (!(r = in_be32(p-mr0) EMAC_MR0_RXI) n) {
+ udelay(1);
--n;
+ }
if (unlikely(!n))
emac_report_timeout_error(dev,
RX disable timeout);
@@ -273,10 +285,12 @@ static void emac_rx_disable(struct ocp_e
r = in_be32(p-mr0);
if (r EMAC_MR0_RXE) {
- int n = 300;
+ int n = dev-stop_timeout;
out_be32(p-mr0, r ~EMAC_MR0_RXE);
- while (!(in_be32(p-mr0) EMAC_MR0_RXI) n)
+ while (!(in_be32(p-mr0) EMAC_MR0_RXI) n) {
+ udelay(1);
--n;
+ }
if (unlikely(!n))
emac_report_timeout_error(dev, RX disable timeout);
}
@@ -395,6 +409,7 @@ static int emac_configure(struct ocp_ene
r = EMAC_MR1_BASE(emac_opb_mhz()) | EMAC_MR1_VLE | EMAC_MR1_IST;
if (dev-phy.duplex == DUPLEX_FULL)
r |= EMAC_MR1_FDE;
+ dev-stop_timeout = STOP_TIMEOUT_10;
switch (dev-phy.speed) {
case SPEED_1000:
if (emac_phy_gpcs(dev-phy.mode)) {
@@ -409,12 +424,16 @@ static int emac_configure(struct ocp_ene
r |= EMAC_MR1_MF_1000;
r |= EMAC_MR1_RFS_16K;
gige = 1;
-
- if (dev-ndev-mtu ETH_DATA_LEN)
+
+ if (dev-ndev-mtu ETH_DATA_LEN) {
r |= EMAC_MR1_JPSM;
+ dev-stop_timeout = STOP_TIMEOUT_1000_JUMBO;
+ } else
+ dev-stop_timeout = STOP_TIMEOUT_1000;
break;
case SPEED_100:
r |= EMAC_MR1_MF_100;
+ dev-stop_timeout = STOP_TIMEOUT_100;
/* Fall through */
default:
r |= EMAC_MR1_RFS_4K;
@@ -2048,6 +2067,7 @@ static int __init emac_probe(struct ocp_
dev-phy.duplex = DUPLEX_FULL;
dev-phy.autoneg = AUTONEG_DISABLE;
dev
floating point operation of ppc
On Fri, Nov 11, 2005 at 07:51:31AM -0500, Greg Weeks wrote: lily wrote: hi,all: i build an embedded linux on powerpc 405ep,i need execute floating point operation,and i enable math emulate option in kernel, i run a while(1)loop ,in the loop there was floating point expression ,after test ,i found the while (1) exit because of the floating point computation,that is the floating point can't execute on ppc stablely.Is there someone meets the same problems ,please give me some suggestion,thanks!!! The 405ep has some errata on floating point use. Are you sure it was 405ep? There is no floating point errata for this chip due to the simple reason, it doesn't support floating point in hardware at all. You probably confusing it with 440ep. I'm not aware of any 405ep specific toolchain. In fact, all what is needed is simple 4xx specific toolchain with soft-float enabled by default. This is how floating point is usually done for 4xx - just soft emulation in user-space by the compiler without in-kernel emulation, which is slow. -- Eugene
[PATCH 1/3] PPC 44x EMAC driver: add 440SPe support
For some reason, the hardware designers made the polarity of one bit
in the 440SPe's PHY interface register the opposite of all other PPC
440 chips. To handle this, abstract our access to this bit and do the
right thing based on the configured CPU type.
Signed-off-by: Roland Dreier rolandd at cisco.com
Signed-off-by: Eugene Surovegin ebs at ebshome.net
---
drivers/net/ibm_emac/ibm_emac.h | 21 -
drivers/net/ibm_emac/ibm_emac_core.c | 13 +++--
drivers/net/ibm_emac/ibm_emac_mal.h |3 ++-
3 files changed, 29 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ibm_emac/ibm_emac.h b/drivers/net/ibm_emac/ibm_emac.h
index 28c476f..d3166da 100644
--- a/drivers/net/ibm_emac/ibm_emac.h
+++ b/drivers/net/ibm_emac/ibm_emac.h
@@ -26,7 +26,7 @@
/* This is a simple check to prevent use of this driver on non-tested SoCs */
#if !defined(CONFIG_405GP) !defined(CONFIG_405GPR)
!defined(CONFIG_405EP) \
!defined(CONFIG_440GP) !defined(CONFIG_440GX) !defined(CONFIG_440SP)
\
-!defined(CONFIG_440EP) !defined(CONFIG_NP405H)
+!defined(CONFIG_440EP) !defined(CONFIG_NP405H)
!defined(CONFIG_440SPE)
#error Unknown SoC. Please, check chip user manual and make sure EMAC defines
are OK
#endif
@@ -246,6 +246,25 @@ struct emac_regs {
#define EMAC_STACR_PCDA_SHIFT 5
#define EMAC_STACR_PRA_MASK0x1f
+/*
+ * For the 440SPe, AMCC inexplicably changed the polarity of
+ * the operation complete bit in the MII control register.
+ */
+#if defined(CONFIG_440SPE)
+static inline int emac_phy_done(u32 stacr)
+{
+ return !(stacr EMAC_STACR_OC);
+};
+#define EMAC_STACR_START EMAC_STACR_OC
+
+#else /* CONFIG_440SPE */
+static inline int emac_phy_done(u32 stacr)
+{
+ return stacr EMAC_STACR_OC;
+};
+#define EMAC_STACR_START 0
+#endif /* !CONFIG_440SPE */
+
/* EMACx_TRTR */
#if !defined(CONFIG_IBM_EMAC4)
#define EMAC_TRTR_SHIFT27
diff --git a/drivers/net/ibm_emac/ibm_emac_core.c
b/drivers/net/ibm_emac/ibm_emac_core.c
index 943fbd1..48239e1 100644
--- a/drivers/net/ibm_emac/ibm_emac_core.c
+++ b/drivers/net/ibm_emac/ibm_emac_core.c
@@ -546,7 +546,7 @@ static int __emac_mdio_read(struct ocp_e
/* Wait for management interface to become idle */
n = 10;
- while (!(in_be32(p-stacr) EMAC_STACR_OC)) {
+ while (!emac_phy_done(in_be32(p-stacr))) {
udelay(1);
if (!--n)
goto to;
@@ -556,11 +556,12 @@ static int __emac_mdio_read(struct ocp_e
out_be32(p-stacr,
EMAC_STACR_BASE(emac_opb_mhz()) | EMAC_STACR_STAC_READ |
(reg EMAC_STACR_PRA_MASK)
-| ((id EMAC_STACR_PCDA_MASK) EMAC_STACR_PCDA_SHIFT));
+| ((id EMAC_STACR_PCDA_MASK) EMAC_STACR_PCDA_SHIFT)
+| EMAC_STACR_START);
/* Wait for read to complete */
n = 100;
- while (!((r = in_be32(p-stacr)) EMAC_STACR_OC)) {
+ while (!emac_phy_done(r = in_be32(p-stacr))) {
udelay(1);
if (!--n)
goto to;
@@ -594,7 +595,7 @@ static void __emac_mdio_write(struct ocp
/* Wait for management interface to be idle */
n = 10;
- while (!(in_be32(p-stacr) EMAC_STACR_OC)) {
+ while (!emac_phy_done(in_be32(p-stacr))) {
udelay(1);
if (!--n)
goto to;
@@ -605,11 +606,11 @@ static void __emac_mdio_write(struct ocp
EMAC_STACR_BASE(emac_opb_mhz()) | EMAC_STACR_STAC_WRITE |
(reg EMAC_STACR_PRA_MASK) |
((id EMAC_STACR_PCDA_MASK) EMAC_STACR_PCDA_SHIFT) |
-(val EMAC_STACR_PHYD_SHIFT));
+(val EMAC_STACR_PHYD_SHIFT) | EMAC_STACR_START);
/* Wait for write to complete */
n = 100;
- while (!(in_be32(p-stacr) EMAC_STACR_OC)) {
+ while (!emac_phy_done(in_be32(p-stacr))) {
udelay(1);
if (!--n)
goto to;
diff --git a/drivers/net/ibm_emac/ibm_emac_mal.h
b/drivers/net/ibm_emac/ibm_emac_mal.h
index 15b0bda..fb6dfe1 100644
--- a/drivers/net/ibm_emac/ibm_emac_mal.h
+++ b/drivers/net/ibm_emac/ibm_emac_mal.h
@@ -34,7 +34,8 @@
#if defined(CONFIG_405GP) || defined(CONFIG_405GPR) || defined(CONFIG_405EP)
|| \
defined(CONFIG_440EP) || defined(CONFIG_NP405H)
#define MAL_VERSION1
-#elif defined(CONFIG_440GP) || defined(CONFIG_440GX) || defined(CONFIG_440SP)
+#elif defined(CONFIG_440GP) || defined(CONFIG_440GX) || defined(CONFIG_440SP)
|| \
+ defined(CONFIG_440SPE)
#define MAL_VERSION2
#else
#error Unknown SoC, please check chip manual and choose MAL 'version'
[PATCH 2/3] PPC 44x EMAC driver: add 440GR support
Add PowerPC 440GR support Signed-off-by: Stefan Roese sr at denx.de Signed-off-by: Eugene Surovegin ebs at ebshome.net --- drivers/net/Kconfig |2 +- drivers/net/ibm_emac/ibm_emac.h |3 ++- drivers/net/ibm_emac/ibm_emac_core.c |7 --- drivers/net/ibm_emac/ibm_emac_mal.h |2 +- 4 files changed, 8 insertions(+), 6 deletions(-) diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index 6d4f9ce..97760c1 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -1203,7 +1203,7 @@ config IBM_EMAC_RX_SKB_HEADROOM config IBM_EMAC_PHY_RX_CLK_FIX bool PHY Rx clock workaround - depends on IBM_EMAC (405EP || 440GX || 440EP) + depends on IBM_EMAC (405EP || 440GX || 440EP || 440GR) help Enable this if EMAC attached to a PHY which doesn't generate RX clock if there is no link, if this is the case, you will diff --git a/drivers/net/ibm_emac/ibm_emac.h b/drivers/net/ibm_emac/ibm_emac.h index d3166da..644edbf 100644 --- a/drivers/net/ibm_emac/ibm_emac.h +++ b/drivers/net/ibm_emac/ibm_emac.h @@ -26,7 +26,8 @@ /* This is a simple check to prevent use of this driver on non-tested SoCs */ #if !defined(CONFIG_405GP) !defined(CONFIG_405GPR) !defined(CONFIG_405EP) \ !defined(CONFIG_440GP) !defined(CONFIG_440GX) !defined(CONFIG_440SP) \ -!defined(CONFIG_440EP) !defined(CONFIG_NP405H) !defined(CONFIG_440SPE) +!defined(CONFIG_440EP) !defined(CONFIG_NP405H) !defined(CONFIG_440SPE) \ +!defined(CONFIG_440GR) #error Unknown SoC. Please, check chip user manual and make sure EMAC defines are OK #endif diff --git a/drivers/net/ibm_emac/ibm_emac_core.c b/drivers/net/ibm_emac/ibm_emac_core.c index 48239e1..eb7d694 100644 --- a/drivers/net/ibm_emac/ibm_emac_core.c +++ b/drivers/net/ibm_emac/ibm_emac_core.c @@ -87,10 +87,11 @@ MODULE_LICENSE(GPL); */ static u32 busy_phy_map; -#if defined(CONFIG_IBM_EMAC_PHY_RX_CLK_FIX) (defined(CONFIG_405EP) || defined(CONFIG_440EP)) +#if defined(CONFIG_IBM_EMAC_PHY_RX_CLK_FIX) \ +(defined(CONFIG_405EP) || defined(CONFIG_440EP) || defined(CONFIG_440GR)) /* 405EP has EMAC to PHY Control Register (CPC0_EPCTL) which can help us * with PHY RX clock problem. - * 440EP has more sane SDR0_MFR register implementation than 440GX, which + * 440EP/440GR has more sane SDR0_MFR register implementation than 440GX, which * also allows controlling each EMAC clock */ static inline void EMAC_RX_CLK_TX(int idx) @@ -100,7 +101,7 @@ static inline void EMAC_RX_CLK_TX(int id #if defined(CONFIG_405EP) mtdcr(0xf3, mfdcr(0xf3) | (1 idx)); -#else /* CONFIG_440EP */ +#else /* CONFIG_440EP || CONFIG_440GR */ SDR_WRITE(DCRN_SDR_MFR, SDR_READ(DCRN_SDR_MFR) | (0x0800 idx)); #endif diff --git a/drivers/net/ibm_emac/ibm_emac_mal.h b/drivers/net/ibm_emac/ibm_emac_mal.h index fb6dfe1..2a2d3b2 100644 --- a/drivers/net/ibm_emac/ibm_emac_mal.h +++ b/drivers/net/ibm_emac/ibm_emac_mal.h @@ -32,7 +32,7 @@ * reflect the fact that 40x and 44x have slightly different MALs. --ebs */ #if defined(CONFIG_405GP) || defined(CONFIG_405GPR) || defined(CONFIG_405EP) || \ -defined(CONFIG_440EP) || defined(CONFIG_NP405H) +defined(CONFIG_440EP) || defined(CONFIG_440GR) || defined(CONFIG_NP405H) #define MAL_VERSION1 #elif defined(CONFIG_440GP) || defined(CONFIG_440GX) || defined(CONFIG_440SP) || \ defined(CONFIG_440SPE)
[PATCH 3/3] PPC 4xx EMAC driver: fix VSC8201 PHY initialization
* MII registers must override strap pins
* disable echo mode to make 10/HDX work (Franz Sirl)
Signed-off-by: Eugene Surovegin ebs at ebshome.net
---
drivers/net/ibm_emac/ibm_emac_phy.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ibm_emac/ibm_emac_phy.c
b/drivers/net/ibm_emac/ibm_emac_phy.c
index a27e49c..67935dd 100644
--- a/drivers/net/ibm_emac/ibm_emac_phy.c
+++ b/drivers/net/ibm_emac/ibm_emac_phy.c
@@ -236,12 +236,16 @@ static struct mii_phy_def genmii_phy_def
};
/* CIS8201 */
+#define MII_CIS8201_10BTCSR0x16
+#define TENBTCSR_ECHO_DISABLE 0x2000
#define MII_CIS8201_EPCR 0x17
#define EPCR_MODE_MASK0x3000
#define EPCR_GMII_MODE0x
#define EPCR_RGMII_MODE 0x1000
#define EPCR_TBI_MODE 0x2000
#define EPCR_RTBI_MODE0x3000
+#define MII_CIS8201_ACSR 0x1c
+#define ACSR_PIN_PRIO_SELECT 0x0004
static int cis8201_init(struct mii_phy *phy)
{
@@ -269,6 +273,14 @@ static int cis8201_init(struct mii_phy *
}
phy_write(phy, MII_CIS8201_EPCR, epcr);
+
+ /* MII regs override strap pins */
+ phy_write(phy, MII_CIS8201_ACSR,
+ phy_read(phy, MII_CIS8201_ACSR) | ACSR_PIN_PRIO_SELECT);
+
+ /* Disable TX_EN - CRS echo mode, otherwise 10/HDX doesn't work */
+ phy_write(phy, MII_CIS8201_10BTCSR,
+ phy_read(phy, MII_CIS8201_10BTCSR) | TENBTCSR_ECHO_DISABLE);
return 0;
}
PPC 405 MAL0 eth: receive descriptor error
On Wed, Oct 12, 2005 at 07:00:48PM +0200, extabe at bredband.net wrote: We have built a board based on AMCC 440ep and used bamboo as reference board. We are running montavista 2.4.20 kernel and have problems with the network. After a while when using the network linux outputs this: PPC 405 MAL0 eth: receive descriptor error Searching the kernelsource shows that this output comes from static void ppc405_eth_rxde(int irq, void *dev_instance, struct pt_regs *regs) in drivers/net/ibm_ocp/ibm_ocp_enet.c and the comment for this function is: This interrupt should be very rare at best. This occurs when the hardware has a problem with the receive descriptors. The manual states that it occurs when the hardware cannot the receive descriptor empty bit is not set. The recovery mechanism will be to traverse through the descriptors, handle any that are marked to be handled and reinitialize each along the way. At that point the driver will be restarted. Can anybody help me with this problem? After it occurs the system freezes for about 2 minutes. Current EMAC driver (in both 2.4 and 2.6) is buggy. That comment is actually misleading, because this IRQ can happen during normal operation, e.g. under heavy packet load. There is re-write available for both 2.4 and 2.6. You can find more information at http://kernel.ebshome.net/. 2.4 patch is against 2.4.31, so you'll have to back port all required stuff to 2.4.21. -- Eugene
[PATCH 2/3][PPC32] PCI-X support for Yucca
On Mon, Oct 03, 2005 at 12:36:08PM +0400, Ruslan V. Sushko wrote: This patch adds PCIX support for Yucca PPC440SPe board. The patch is implemented for Roland Dreier git tree for Yucca PPC440SPe board. Signed-off-by: Ruslan V. Sushko rsushko at ru.mvista.com [snip] +mtdcr(DCRN_UIC_PR(UIC1), +mfdcr(DCRN_UIC_PR(UIC1)) ~0x4000); /* Set PCI interrupt +(EXT IRQ12) plarity +to Negative */ Don't mess with UIC registers directly. Take a look how this type of setup is done in other 4xx ports (e.g. Ebony) and use the same approach (hint: ppc4xx_uic_ext_irq_cfg). -- Eugene
Available user-level tool for I2C device?
On Thu, Sep 29, 2005 at 08:35:35PM +0800, Sam Song wrote: I have a RTC chip DS1337 on a 8248 target. It can work right in u-boot and linux. If no similar utility, I will switch to change hwclock.c in busybox to make it. Any idea? Right approach would be making standard in-kernel RTC driver for this chip. In fact, such driver was already posted to lm-sensors list some time ago. -- Eugene
[PATCH 3/4] [PPC32] ibm_emac: Add 440SPe support
On Thu, Sep 22, 2005 at 10:25:26PM -0700, Roland Dreier wrote: No problem at all. Here's a patch against your git tree -- only tested on my Yucca board, so you might want to doublecheck that I didn't break all the systems will the opposite polarity. Thanks Roland, I've just pushed your patch with minor style changes to my GIT tree. I changed uint32_t - u32 and moved emac_phy_done() functions to ibm_emac.h. Booted new kernel on Ocotea and everything seems to be OK. -- Eugene
[PATCH 2/4] [PPC32] Add 440SPe support
On Fri, Sep 23, 2005 at 03:44:35PM -0700, Roland Dreier wrote: BTW, Eugene, you might want to do a 'git prune-packed' on your git tree. It's pretty wasteful to clone your tree now, because you have a lot of individual objects that also appear in Linus's packs. Yeah, I did this yesterday, so I guess your next pulls should be OK. You may need to do this on the cloned tree as well. -- Eugene
[PATCH 3/4] [PPC32] ibm_emac: Add 440SPe support
On Thu, Sep 22, 2005 at 08:03:35PM -0700, Roland Dreier wrote: Eugene, I'm not sure what the status of your ibm_emac rewrite is. Is there a tree somewhere that you would like me to merge this change with and then send you a patch, or do you want to take care of merging? Well, new driver was sent to jgarzik and netdev list three weeks ago. So far I haven't heard anything technical from Jeff. I don't know when and even if it will be merged. There is a GIT tree with new driver, for more info look at http://kernel.ebshome.net/emac/index.html I don't know what to recommend now - wait for net driver maintainer (I've heard some people have been waiting for couple months already) or sent this patch upstream ignoring new driver :(. Matt? I'll try to look at merging your patch into my tree, but probably not right now - I'm kinda busy with other stuff and netdev progress doesn't quite motivate me working on this project, frankly. Though, if you can send me a patch against my tree, I'll appreciate it :). -- Eugene
[PATCH 2/4] [PPC32] Add 440SPe support
On Thu, Sep 22, 2005 at 08:03:35PM -0700, Roland Dreier wrote:
Add support for the AMCC PowerPC 440SPe SoC.
[snip]
+static struct ocp_func_mal_data amc440spe_mal0_def = {
+ .num_tx_chans = 1,/* Number of TX channels */
+ .num_rx_chans = 1,/* Number of RX channels */
+ .txeob_irq = 38, /* TX End Of Buffer IRQ */
+ .rxeob_irq = 39, /* RX End Of Buffer IRQ */
+ .txde_irq = 34, /* TX Descriptor Error IRQ */
+ .rxde_irq = 35, /* RX Descriptor Error IRQ */
+ .serr_irq = 33, /* MAL System Error IRQ*/
+};
+OCP_SYSFS_MAL_DATA()
Roland, I recently added new field (.dcr_base) to this structure (as a
preparation step for new EMAC driver), could you do this for 440SPe as
well? It's not needed right now, but as soon as new EMAC driver is in,
440SPe will stop working.
[snip]
+static void __init ppc4xx_pic_impl_init(void)
+{
+ /* Enable cascade interrupts in UIC0 */
+ /* Enable cascade interrupt in UIC0 */
I think you probably missed this part :)
--
Eugene
[PATCH 4/4] [PPC32] Add Yucca (440SPe eval board) platform
On Thu, Sep 22, 2005 at 08:03:35PM -0700, Roland Dreier wrote: Add support for AMCC PowerPC 440SPe Yucca eval board platform. [snip] +/* + * This is a horrible kludge, we eventually need to abstract this + * generic PHY stuff, so the standard phy mode defines can be + * easily used from arch code. + */ +#include ../../../../drivers/net/ibm_emac/ibm_emac_phy.h This is not needed anymore. Please, remove this. -- Eugene
[PATCH] ppc32: cleanup AMCC PPC4xx eval boards to better support U-Boot
On Mon, Sep 19, 2005 at 05:06:23PM +0200, Stefan Roese wrote: Hi Matt, On Monday 19 September 2005 15:59, Matt Porter wrote: On Mon, Sep 19, 2005 at 01:02:14PM +0200, Stefan Roese wrote: Just to be sure: The 44x boot-wrapper approach you mention is boot/simple/pibs.c? Yes, there's both boot/simple/pibs.c and boot/simple/openbios.c that were created so we could have the default firmware and u-boot use the same kernel build. Yes, that's what I thought. But Eugene mentioned, that he boots vmlinux without any boot-wrapper on the OpenBIOS targets (except Ebony probably). Bad phrasing on my part. What I meant was U-Boot is different from OpenBIOS targets already, as with U-Boot we don't use any boot-wrapper like with OpenBIOS. Sorry for confusion :). -- Eugene
[PATCH] ppc32: cleanup AMCC PPC4xx eval boards to better support U-Boot
On Fri, Sep 16, 2005 at 01:06:16PM +0200, Stefan Roese wrote: Add U-Boot support to AMCC PPC405 eval boards (bubinga, sycamore and walnut) and cleanup PPC440 eval boards (bamboo, ebony, luan and ocotea) to better support U-Boot as bootloader. In general, 44x pieces look OK, but 40x aren't. Notice, that we don't have any #ifdef CONFIG_UBOOT in 44x sources. Let's not add them for 40x, try to replicate the same boot-wrapper approach as Matt used for 44x. [snip] diff --git a/arch/ppc/platforms/4xx/Kconfig b/arch/ppc/platforms/4xx/Kconfig --- a/arch/ppc/platforms/4xx/Kconfig +++ b/arch/ppc/platforms/4xx/Kconfig @@ -212,10 +212,18 @@ config EMBEDDEDBOOT depends on EP405 || XILINX_ML300 default y -config IBM_OPENBIOS - bool +choice + prompt Bootloader support depends on ASH || BUBINGA || REDWOOD_5 || REDWOOD_6 || SYCAMORE || WALNUT - default y + default IBM_OPENBIOS + +config IBM_OPENBIOS + bool IBM OpenBIOS + +config UBOOT + bool U-Boot + +endchoice Do we really need this? U-Boot build is different from OpenBIOS already (we just use vmlinux without any boot-wrapper) and is selected by different make target. [snip] --- a/arch/ppc/platforms/4xx/bubinga.c +++ b/arch/ppc/platforms/4xx/bubinga.c @@ -89,7 +89,11 @@ bubinga_early_serial_map(void) * by 16. */ uart_div = (mfdcr(DCRN_CPC0_UCR_BASE) DCRN_CPC0_UCR_U0DIV); +#ifdef CONFIG_UBOOT + uart_clock = __res.bi_procfreq / uart_div; +#else uart_clock = __res.bi_pllouta_freq / uart_div; +#endif Why not just rename this field and skip this ugly ifdefing? -- Eugene
squashfs on ppc
On Fri, Sep 16, 2005 at 04:48:09PM -0500, Tolunay Orkun wrote: Has anyone any positive or negative experience of using squashfs on PowerPC as initrd? Our environment is PowerPC 405GP running 2.4.31 kernel. U-Boot is our bootloader. Any comparison with respect to CramFS? I use squashfs and squashfs2. Both work just fine on PPC. They provide significantly better compression ration than cramfs, although at the expense of some speed (mostly visible during initial startup of big user-space app). -- Eugene
[PATCH 1/2] New PowerPC 4xx on-chip ethernet controller driver
On Wed, Sep 14, 2005 at 08:45:49AM -0400, Jeff Garzik wrote: Eugene Surovegin wrote: Remove old PPC4xx EMAC driver Signed-off-by: Eugene Surovegin ebs at ebshome.net Please post a diff, along with a description of the changes. One huge patch to remove emac driver and another huge patch to add emac driver is quite silly. Jeff, it's not silly. I can post combined patch, but you won't be able to read it (and combined patch is still big). As I said, it's a _complete_ re-write. It's a _new_ driver, not just some changes. Description of what was done was in the first e-mail. I've split it into two parts specifically, so _you_ will be able to read new patch and comment on it. -- Eugene
[PATCH] New PowerPC 4xx on-chip ethernet controller driver
On Wed, Sep 14, 2005 at 08:45:49AM -0400, Jeff Garzik wrote: Eugene Surovegin wrote: Remove old PPC4xx EMAC driver Signed-off-by: Eugene Surovegin ebs at ebshome.net Please post a diff, along with a description of the changes. One huge patch to remove emac driver and another huge patch to add emac driver is quite silly. This patch replaces current PowerPC 4xx EMAC driver with new, re-written version. New driver uses NAPI, it solves stability problems under heavy packet load and low memory, corrects chip register access and fixes numerous small bugs I don't even remember now :). This patch has been tested on all supported in 2.6 PPC 4xx boards. It's been used in production for almost a year now on custom 4xx hardware. PPC32 specific parts are already upstream. Patch was acked by the current EMAC driver maintainer (Matt Porter). I will be maintaining this new version. Signed-off-by: Eugene Surovegin ebs at ebshome.net -- Kconfig | 72 ibm_emac/Makefile | 13 ibm_emac/ibm_emac.h | 418 +++-- ibm_emac/ibm_emac_core.c | 3391 -- ibm_emac/ibm_emac_core.h | 313 ++-- ibm_emac/ibm_emac_debug.c | 377 ++--- ibm_emac/ibm_emac_debug.h | 63 ibm_emac/ibm_emac_mal.c | 671 + ibm_emac/ibm_emac_mal.h | 336 +++- ibm_emac/ibm_emac_phy.c | 335 ++-- ibm_emac/ibm_emac_phy.h | 105 - ibm_emac/ibm_emac_rgmii.c | 202 ++ ibm_emac/ibm_emac_rgmii.h | 68 ibm_emac/ibm_emac_tah.c | 111 + ibm_emac/ibm_emac_tah.h | 96 - ibm_emac/ibm_emac_zmii.c | 256 +++ ibm_emac/ibm_emac_zmii.h | 114 - 17 files changed, 4119 insertions(+), 2822 deletions(-) Patch is quite big (~234K) because there is virtualy 0% of common code between old and new version. It can be found at http://kernel.ebshome.net/emac/4xx_napi_emac.diff
-dev and -embedded cross-posting
Guys, let's not cross-post -dev posts here. In general, -embedded isn't a totally separate list, it just covers embedded specific stuff, which is not interesting to several loud -dev readers :). Things which aren't embedded specific should go -dev. I think, everybody *interested* in general PPC32 development issues here, are also subscribed to -dev list. Thanks. -- Eugene
BDI2000 with PPC405EP
On Thu, Sep 08, 2005 at 11:33:53AM +0530, Albert David wrote: Friends, I have been trying to find a solution to fix PPC: timeout while waiting for freeze for my custom board. BDI2000 keeps resetting the system with the following message... TARGET: processing user reset request TARGET: resetting target passed TARGET: processing target startup *** TARGET: core #0 startup failed # PPC: timeout while waiting for freeze TARGET: target will be restarted in 10 sec I tried all the possible solutions provided at http://www.ultsol.com/faq-P206.htm for this perticular behaviour but the problem remains same! I have ensured that my Board's JTAG interface is properly working by boundary scanning the pins of PPC405EP using UniversalScan software with Altera-ByteBlaster MV. for your information: twice i could succeed connecting BDI2000 with my target! somehow it happen to work while i was trying to execute low level JTAG commands such as 'rir' rdr' and then after exiting(JTAG command shell of BDI) it worked, but there is no consistency! looks like my cpu core is not halting after asserting HALT line. has anyone faced similar problem?? In _all_ cases I saw this problem it was a hw bug. Ask your hw engineers to help you. Start with the usual suspects: power, clocks, strapping, etc. I don't think working boundary scan is an indication that hw design is OK. -- Eugene
[PATCH] ppc32: fix ocp_device_suspend to use pm_message_t instead of u32
Recent u32 - pm_message_t change triggered hidden bug in
ocp_device_suspend. Fix it to correctly use pm_message_t instead of
u32.
Signed-off-by: Eugene Surovegin ebs at ebshome.net
diff --git a/arch/ppc/syslib/ocp.c b/arch/ppc/syslib/ocp.c
--- a/arch/ppc/syslib/ocp.c
+++ b/arch/ppc/syslib/ocp.c
@@ -165,7 +165,7 @@ ocp_device_remove(struct device *dev)
}
static int
-ocp_device_suspend(struct device *dev, u32 state)
+ocp_device_suspend(struct device *dev, pm_message_t state)
{
struct ocp_device *ocp_dev = to_ocp_dev(dev);
struct ocp_driver *ocp_drv = to_ocp_drv(dev-driver);
[PATCH] ppc32: add missing sysfs node for ocp_func_emac_data.phy_feat_exc
Add sysfs node for ocp_func_emac_data.phy_feat_exc field.
Signed-off-by: Eugene Surovegin ebs at ebshome.net
---
include/asm-ppc/ibm_ocp.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/asm-ppc/ibm_ocp.h b/include/asm-ppc/ibm_ocp.h
--- a/include/asm-ppc/ibm_ocp.h
+++ b/include/asm-ppc/ibm_ocp.h
@@ -84,6 +84,7 @@ OCP_SYSFS_ADDTL(struct ocp_func_emac_dat
OCP_SYSFS_ADDTL(struct ocp_func_emac_data, %d\n, emac, tah_idx) \
OCP_SYSFS_ADDTL(struct ocp_func_emac_data, %d\n, emac, phy_mode) \
OCP_SYSFS_ADDTL(struct ocp_func_emac_data, 0x%08x\n, emac, phy_map) \
+OCP_SYSFS_ADDTL(struct ocp_func_emac_data, 0x%08x\n, emac, phy_feat_exc)\
\
void ocp_show_emac_data(struct device *dev)\
{ \
@@ -99,6 +100,7 @@ void ocp_show_emac_data(struct device *d
device_create_file(dev, dev_attr_emac_tah_idx);\
device_create_file(dev, dev_attr_emac_phy_mode); \
device_create_file(dev, dev_attr_emac_phy_map);\
+ device_create_file(dev, dev_attr_emac_phy_feat_exc); \
}
/*
[PATCH] ppc32: move 4xx PHY_MODE_XXX defines to ibm_ocp.h
Move 4xx PHY_MODE_XXX defines to asm-ppc/ibm_ocp.h. This is a preparation step for the new EMAC driver. Signed-off-by: Eugene Surovegin ebs at ebshome.net --- arch/ppc/platforms/4xx/bamboo.c |7 --- arch/ppc/platforms/4xx/ebony.c |7 --- arch/ppc/platforms/4xx/luan.c |7 --- arch/ppc/platforms/4xx/ocotea.c |7 --- include/asm-ppc/ibm_ocp.h | 13 + 5 files changed, 13 insertions(+), 28 deletions(-) diff --git a/arch/ppc/platforms/4xx/bamboo.c b/arch/ppc/platforms/4xx/bamboo.c --- a/arch/ppc/platforms/4xx/bamboo.c +++ b/arch/ppc/platforms/4xx/bamboo.c @@ -52,13 +52,6 @@ #include syslib/gen550.h #include syslib/ibm440gx_common.h -/* - * This is a horrible kludge, we eventually need to abstract this - * generic PHY stuff, so the standard phy mode defines can be - * easily used from arch code. - */ -#include ../../../../drivers/net/ibm_emac/ibm_emac_phy.h - bd_t __res; static struct ibm44x_clocks clocks __initdata; diff --git a/arch/ppc/platforms/4xx/ebony.c b/arch/ppc/platforms/4xx/ebony.c --- a/arch/ppc/platforms/4xx/ebony.c +++ b/arch/ppc/platforms/4xx/ebony.c @@ -55,13 +55,6 @@ #include syslib/gen550.h #include syslib/ibm440gp_common.h -/* - * This is a horrible kludge, we eventually need to abstract this - * generic PHY stuff, so the standard phy mode defines can be - * easily used from arch code. - */ -#include ../../../../drivers/net/ibm_emac/ibm_emac_phy.h - bd_t __res; static struct ibm44x_clocks clocks __initdata; diff --git a/arch/ppc/platforms/4xx/luan.c b/arch/ppc/platforms/4xx/luan.c --- a/arch/ppc/platforms/4xx/luan.c +++ b/arch/ppc/platforms/4xx/luan.c @@ -53,13 +53,6 @@ #include syslib/ibm440gx_common.h #include syslib/ibm440sp_common.h -/* - * This is a horrible kludge, we eventually need to abstract this - * generic PHY stuff, so the standard phy mode defines can be - * easily used from arch code. - */ -#include ../../../../drivers/net/ibm_emac/ibm_emac_phy.h - bd_t __res; static struct ibm44x_clocks clocks __initdata; diff --git a/arch/ppc/platforms/4xx/ocotea.c b/arch/ppc/platforms/4xx/ocotea.c --- a/arch/ppc/platforms/4xx/ocotea.c +++ b/arch/ppc/platforms/4xx/ocotea.c @@ -53,13 +53,6 @@ #include syslib/gen550.h #include syslib/ibm440gx_common.h -/* - * This is a horrible kludge, we eventually need to abstract this - * generic PHY stuff, so the standard phy mode defines can be - * easily used from arch code. - */ -#include ../../../../drivers/net/ibm_emac/ibm_emac_phy.h - bd_t __res; static struct ibm44x_clocks clocks __initdata; diff --git a/include/asm-ppc/ibm_ocp.h b/include/asm-ppc/ibm_ocp.h --- a/include/asm-ppc/ibm_ocp.h +++ b/include/asm-ppc/ibm_ocp.h @@ -100,6 +100,19 @@ void ocp_show_emac_data(struct device *d device_create_file(dev, dev_attr_emac_phy_map);\ } +/* + * PHY mode settings (EMAC - ZMII/RGMII bridge - PHY) + */ +#define PHY_MODE_NA0 +#define PHY_MODE_MII 1 +#define PHY_MODE_RMII 2 +#define PHY_MODE_SMII 3 +#define PHY_MODE_RGMII 4 +#define PHY_MODE_TBI 5 +#define PHY_MODE_GMII 6 +#define PHY_MODE_RTBI 7 +#define PHY_MODE_SGMII 8 + #ifdef CONFIG_40x /* * Helper function to copy MAC addresses from the bd_t to OCP EMAC
[PATCH] ppc32: add dcr_base field to ocp_func_mal_data
Add dcr_base field to ocp_func_mal_data. This is preparation step for the new EMAC driver. Signed-off-by: Eugene Surovegin ebs at ebshome.net --- arch/ppc/platforms/4xx/ibm405ep.c |1 + arch/ppc/platforms/4xx/ibm405gp.c |1 + arch/ppc/platforms/4xx/ibm405gpr.c |1 + arch/ppc/platforms/4xx/ibm440ep.c |1 + arch/ppc/platforms/4xx/ibm440gp.c |1 + arch/ppc/platforms/4xx/ibm440gx.c |1 + arch/ppc/platforms/4xx/ibm440sp.c |1 + arch/ppc/platforms/4xx/ibmnp405h.c |1 + include/asm-ppc/ibm_ocp.h |3 +++ 9 files changed, 11 insertions(+), 0 deletions(-) diff --git a/arch/ppc/platforms/4xx/ibm405ep.c b/arch/ppc/platforms/4xx/ibm405ep.c --- a/arch/ppc/platforms/4xx/ibm405ep.c +++ b/arch/ppc/platforms/4xx/ibm405ep.c @@ -33,6 +33,7 @@ static struct ocp_func_mal_data ibm405ep .txde_irq = 13, /* TX Descriptor Error IRQ */ .rxde_irq = 14, /* RX Descriptor Error IRQ */ .serr_irq = 10, /* MAL System Error IRQ*/ + .dcr_base = DCRN_MAL_BASE /* MAL0_CFG DCR number */ }; OCP_SYSFS_MAL_DATA() diff --git a/arch/ppc/platforms/4xx/ibm405gp.c b/arch/ppc/platforms/4xx/ibm405gp.c --- a/arch/ppc/platforms/4xx/ibm405gp.c +++ b/arch/ppc/platforms/4xx/ibm405gp.c @@ -46,6 +46,7 @@ static struct ocp_func_mal_data ibm405gp .txde_irq = 13, /* TX Descriptor Error IRQ */ .rxde_irq = 14, /* RX Descriptor Error IRQ */ .serr_irq = 10, /* MAL System Error IRQ*/ + .dcr_base = DCRN_MAL_BASE /* MAL0_CFG DCR number */ }; OCP_SYSFS_MAL_DATA() diff --git a/arch/ppc/platforms/4xx/ibm405gpr.c b/arch/ppc/platforms/4xx/ibm405gpr.c --- a/arch/ppc/platforms/4xx/ibm405gpr.c +++ b/arch/ppc/platforms/4xx/ibm405gpr.c @@ -42,6 +42,7 @@ static struct ocp_func_mal_data ibm405gp .txde_irq = 13, /* TX Descriptor Error IRQ */ .rxde_irq = 14, /* RX Descriptor Error IRQ */ .serr_irq = 10, /* MAL System Error IRQ*/ + .dcr_base = DCRN_MAL_BASE /* MAL0_CFG DCR number */ }; OCP_SYSFS_MAL_DATA() diff --git a/arch/ppc/platforms/4xx/ibm440ep.c b/arch/ppc/platforms/4xx/ibm440ep.c --- a/arch/ppc/platforms/4xx/ibm440ep.c +++ b/arch/ppc/platforms/4xx/ibm440ep.c @@ -53,6 +53,7 @@ static struct ocp_func_mal_data ibm440ep .txde_irq = 33, /* TX Descriptor Error IRQ */ .rxde_irq = 34, /* RX Descriptor Error IRQ */ .serr_irq = 32, /* MAL System Error IRQ*/ + .dcr_base = DCRN_MAL_BASE /* MAL0_CFG DCR number */ }; OCP_SYSFS_MAL_DATA() diff --git a/arch/ppc/platforms/4xx/ibm440gp.c b/arch/ppc/platforms/4xx/ibm440gp.c --- a/arch/ppc/platforms/4xx/ibm440gp.c +++ b/arch/ppc/platforms/4xx/ibm440gp.c @@ -56,6 +56,7 @@ static struct ocp_func_mal_data ibm440gp .txde_irq = 33, /* TX Descriptor Error IRQ */ .rxde_irq = 34, /* RX Descriptor Error IRQ */ .serr_irq = 32, /* MAL System Error IRQ*/ + .dcr_base = DCRN_MAL_BASE /* MAL0_CFG DCR number */ }; OCP_SYSFS_MAL_DATA() diff --git a/arch/ppc/platforms/4xx/ibm440gx.c b/arch/ppc/platforms/4xx/ibm440gx.c --- a/arch/ppc/platforms/4xx/ibm440gx.c +++ b/arch/ppc/platforms/4xx/ibm440gx.c @@ -84,6 +84,7 @@ static struct ocp_func_mal_data ibm440gx .txde_irq = 33, /* TX Descriptor Error IRQ */ .rxde_irq = 34, /* RX Descriptor Error IRQ */ .serr_irq = 32, /* MAL System Error IRQ*/ + .dcr_base = DCRN_MAL_BASE /* MAL0_CFG DCR number */ }; OCP_SYSFS_MAL_DATA() diff --git a/arch/ppc/platforms/4xx/ibm440sp.c b/arch/ppc/platforms/4xx/ibm440sp.c --- a/arch/ppc/platforms/4xx/ibm440sp.c +++ b/arch/ppc/platforms/4xx/ibm440sp.c @@ -43,6 +43,7 @@ static struct ocp_func_mal_data ibm440sp .txde_irq = 34, /* TX Descriptor Error IRQ */ .rxde_irq = 35, /* RX Descriptor Error IRQ */ .serr_irq = 33, /* MAL System Error IRQ*/ + .dcr_base = DCRN_MAL_BASE /* MAL0_CFG DCR number */ }; OCP_SYSFS_MAL_DATA() diff --git a/arch/ppc/platforms/4xx/ibmnp405h.c b/arch/ppc/platforms/4xx/ibmnp405h.c --- a/arch/ppc/platforms/4xx/ibmnp405h.c +++ b/arch/ppc/platforms/4xx/ibmnp405h.c @@ -73,6 +73,7 @@ static struct ocp_func_mal_data ibmnp405 .txde_irq = 46, /* TX Descriptor Error IRQ */ .rxde_irq = 47, /* RX Descriptor Error IRQ */ .serr_irq = 45, /* MAL System Error IRQ*/ + .dcr_base = DCRN_MAL_BASE /* MAL0_CFG DCR number */ }; OCP_SYSFS_MAL_DATA() diff --git a/include/asm-ppc/ibm_ocp.h b/include/asm-ppc/ibm_ocp.h --- a/include/asm-ppc/ibm_ocp.h +++ b/include/asm-ppc/ibm_ocp.h @@ -146,6 +146,7 @@ struct
[PATCH 0/2] New PowerPC 4xx on-chip ethernet controller driver
Jeff, the following patches replace current PowerPC 4xx EMAC driver with new, re-written version. New driver uses NAPI, it solves problems under heavy packet load and low memory, corrects chip register access and fixes numerous small bugs I don't even remember now :). This patch has been tested on all supported in 2.6 PPC 4xx boards. It's been used in production for almost a year now on custom 4xx hardware. PPC32 specific parts were just posted to linuxppc-dev and linuxppc-embedded mail lists. Patch was acked by the current EMAC driver maintainer (Matt Porter). I will be maintaining this new version. Signed-off-by: Eugene Surovegin ebs at ebshome.net
[PATCH 1/2] New PowerPC 4xx on-chip ethernet controller driver
Remove old PPC4xx EMAC driver Signed-off-by: Eugene Surovegin ebs at ebshome.net --- drivers/net/Kconfig | 34 - drivers/net/ibm_emac/Makefile | 12 drivers/net/ibm_emac/ibm_emac.h | 267 drivers/net/ibm_emac/ibm_emac_core.c | 2011 - drivers/net/ibm_emac/ibm_emac_core.h | 146 -- drivers/net/ibm_emac/ibm_emac_debug.c | 224 drivers/net/ibm_emac/ibm_emac_mal.c | 463 drivers/net/ibm_emac/ibm_emac_mal.h | 131 -- drivers/net/ibm_emac/ibm_emac_phy.c | 298 - drivers/net/ibm_emac/ibm_emac_phy.h | 137 -- drivers/net/ibm_emac/ibm_emac_rgmii.h | 65 - drivers/net/ibm_emac/ibm_emac_tah.h | 48 - drivers/net/ibm_emac/ibm_emac_zmii.h | 93 -- 13 files changed, 0 insertions(+), 3929 deletions(-) Patch is quite big (110K) and not interesting, it can be found at http://kernel.ebshome.net/emac/05-remove_old_ibm_emac.diff
[PATCH 2/2] New PowerPC 4xx on-chip ethernet controller driver
Add new PPC 4xx NAPI EMAC driver Signed-off-by: Eugene Surovegin ebs at ebshome.net --- drivers/net/Kconfig | 70 + drivers/net/ibm_emac/Makefile | 11 drivers/net/ibm_emac/ibm_emac.h | 309 + drivers/net/ibm_emac/ibm_emac_core.c | 2248 + drivers/net/ibm_emac/ibm_emac_core.h | 221 +++ drivers/net/ibm_emac/ibm_emac_debug.c | 213 +++ drivers/net/ibm_emac/ibm_emac_debug.h | 63 + drivers/net/ibm_emac/ibm_emac_mal.c | 584 + drivers/net/ibm_emac/ibm_emac_mal.h | 267 drivers/net/ibm_emac/ibm_emac_phy.c | 355 + drivers/net/ibm_emac/ibm_emac_phy.h | 80 + drivers/net/ibm_emac/ibm_emac_rgmii.c | 202 +++ drivers/net/ibm_emac/ibm_emac_rgmii.h | 65 + drivers/net/ibm_emac/ibm_emac_tah.c | 111 ++ drivers/net/ibm_emac/ibm_emac_tah.h | 88 + drivers/net/ibm_emac/ibm_emac_zmii.c | 256 drivers/net/ibm_emac/ibm_emac_zmii.h | 83 + 17 files changed, 5226 insertions(+), 0 deletions(-) Patch is quite big (146K) and can be found at http://kernel.ebshome.net/emac/06-add_napi_ibm_emac.diff I can post it to the mail list for discussion, just let me know.
[PATCH] ppc32: disable IBM405_ERR77 and IBM405_ERR51 workarounds for 405EP
Disable IBM405_ERR77 and IBM405_ERR51 errata workarounds for 405EP. This chip has these problems fixed. Signed-off-by: Eugene Surovegin ebs at ebshome.net diff --git a/arch/ppc/platforms/4xx/Kconfig b/arch/ppc/platforms/4xx/Kconfig --- a/arch/ppc/platforms/4xx/Kconfig +++ b/arch/ppc/platforms/4xx/Kconfig @@ -152,13 +152,13 @@ config IBM440EP_ERR42 # All 405-based cores up until the 405GPR and 405EP have this errata. config IBM405_ERR77 bool - depends on 40x !403GCX !405GPR + depends on 40x !403GCX !405GPR !405EP default y # All 40x-based cores, up until the 405GPR and 405EP have this errata. config IBM405_ERR51 bool - depends on 40x !405GPR + depends on 40x !405GPR !405EP default y config BOOKE
[PATCH] ppc32: fix Bamboo and Luan build warnings
Fix STD_UART_OP definitions in Bamboo and Luan board ports which
were causing initialization makes pointer from integer without a
cast warnings.
Signed-off-by: Eugene Surovegin ebs at ebshome.net
diff --git a/arch/ppc/platforms/4xx/bamboo.h b/arch/ppc/platforms/4xx/bamboo.h
--- a/arch/ppc/platforms/4xx/bamboo.h
+++ b/arch/ppc/platforms/4xx/bamboo.h
@@ -88,7 +88,7 @@
#define STD_UART_OP(num) \
{ 0, BASE_BAUD, 0, UART##num##_INT, \
(ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST),\
- iomem_base: UART##num##_IO_BASE,\
+ iomem_base: (void*)UART##num##_IO_BASE, \
io_type: SERIAL_IO_MEM},
#define SERIAL_PORT_DFNS \
diff --git a/arch/ppc/platforms/4xx/luan.h b/arch/ppc/platforms/4xx/luan.h
--- a/arch/ppc/platforms/4xx/luan.h
+++ b/arch/ppc/platforms/4xx/luan.h
@@ -55,7 +55,7 @@
#define STD_UART_OP(num) \
{ 0, BASE_BAUD, 0, UART##num##_INT, \
(ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST),\
- iomem_base: UART##num##_IO_BASE,\
+ iomem_base: (void*)UART##num##_IO_BASE, \
io_type: SERIAL_IO_MEM},
#define SERIAL_PORT_DFNS \
[PATCH] ppc32: fix EMAC Tx channel assignments for NPe405H
Fix PowerPC NPe405H EMAC Tx channel assignments. EMAC unit in this chip uses common for 4xx two Tx / one Rx configuration. Signed-off-by: Eugene Surovegin ebs at ebshome.net diff --git a/arch/ppc/platforms/4xx/ibmnp405h.c b/arch/ppc/platforms/4xx/ibmnp405h.c --- a/arch/ppc/platforms/4xx/ibmnp405h.c +++ b/arch/ppc/platforms/4xx/ibmnp405h.c @@ -34,7 +34,7 @@ static struct ocp_func_emac_data ibmnp40 .zmii_mux = 1,/* ZMII input of this EMAC */ .mal_idx= 0,/* MAL device index */ .mal_rx_chan= 1,/* MAL rx channel number */ - .mal_tx_chan= 1,/* MAL tx channel number */ + .mal_tx_chan= 2,/* MAL tx channel number */ .wol_irq= 41, /* WOL interrupt number */ .mdio_idx = -1, /* No shared MDIO */ .tah_idx= -1, /* No TAH */ @@ -46,7 +46,7 @@ static struct ocp_func_emac_data ibmnp40 .zmii_mux = 2,/* ZMII input of this EMAC */ .mal_idx= 0,/* MAL device index */ .mal_rx_chan= 2,/* MAL rx channel number */ - .mal_tx_chan= 2,/* MAL tx channel number */ + .mal_tx_chan= 4,/* MAL tx channel number */ .wol_irq= 41, /* WOL interrupt number */ .mdio_idx = -1, /* No shared MDIO */ .tah_idx= -1, /* No TAH */ @@ -58,7 +58,7 @@ static struct ocp_func_emac_data ibmnp40 .zmii_mux = 3,/* ZMII input of this EMAC */ .mal_idx= 0,/* MAL device index */ .mal_rx_chan= 3,/* MAL rx channel number */ - .mal_tx_chan= 3,/* MAL tx channel number */ + .mal_tx_chan= 6,/* MAL tx channel number */ .wol_irq= 41, /* WOL interrupt number */ .mdio_idx = -1, /* No shared MDIO */ .tah_idx= -1, /* No TAH */
[PATCH] ppc32: add 440GX rev.F cputable entry
Add PowerPC 440GX rev.F cputable entry.
Signed-off-by: Eugene Surovegin ebs at ebshome.net
diff --git a/arch/ppc/kernel/cputable.c b/arch/ppc/kernel/cputable.c
--- a/arch/ppc/kernel/cputable.c
+++ b/arch/ppc/kernel/cputable.c
@@ -922,6 +922,16 @@ struct cpu_speccpu_specs[] = {
.icache_bsize = 32,
.dcache_bsize = 32,
},
+ { /* 440GX Rev. F */
+ .pvr_mask = 0xffff,
+ .pvr_value = 0x5894,
+ .cpu_name = 440GX Rev. F,
+ .cpu_features = CPU_FTR_SPLIT_ID_CACHE |
+ CPU_FTR_USE_TB,
+ .cpu_user_features = PPC_FEATURE_32 | PPC_FEATURE_HAS_MMU,
+ .icache_bsize = 32,
+ .dcache_bsize = 32,
+ },
#endif /* CONFIG_44x */
#ifdef CONFIG_FSL_BOOKE
{ /* e200z5 */
[PATCH] add field to struct ocp_func_emac_data for platform-specific unsupported PHY features
On Thu, Aug 11, 2005 at 01:42:07PM -0700, Wade Farnsworth wrote:
[snip]
diff -upr linux-2.6/include/asm-ppc/ibm_ocp.h
linux-2.6-dev/include/asm-ppc/ibm_ocp.h
--- linux-2.6/include/asm-ppc/ibm_ocp.h 2005-08-11 13:30:02.0
-0700
+++ linux-2.6-dev/include/asm-ppc/ibm_ocp.h 2005-08-11 13:12:34.0
-0700
@@ -67,6 +67,7 @@ struct ocp_func_emac_data {
int phy_mode; /* PHY type or configurable mode */
u8 mac_addr[6];/* EMAC mac address */
u32 phy_map;/* EMAC phy map */
+ u32 phy_feat_exc; /* Excluded PHY features */
};
/* Sysfs support */
Please, update OCP_SYSFS_EMAC_DATA() macro as well.
--
Eugene
