RE: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)
-Original Message- From: Phillips Kim Sent: Tuesday, November 06, 2007 2:16 AM To: Li Yang-r58472; Kumar Gala; [EMAIL PROTECTED]; linuxppc-dev@ozlabs.org Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing) Hello all, the following patches fix RGMII timing for rev. 2.1 of the mpc8360, according to erratum #2 (erratum text included below). Basically the most intrusive part is the addition of two new RGMII Internal Delay modes; one for TX delay only, and the other for RX delay only (i.e, not both at the same time). Please review, and since this affects both netdev and powerpc trees, one maintainer should ack them for the other to push upstream (i.e, Kumar acks them, and Leo picks them up to go through netdev or the other way around; either way is fine with me). I'm hoping they're trivial enough to go in 2.6.24. Depending on how the review goes, a follow-on patch to u-boot will be sent out that fixes up the phy-connection-type in the device tree (from rgmii-id to rgmii-rxid iff on mpc8360rev2.1). 2-4 Acked-by: Li Yang [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)
On Mon, 5 Nov 2007 12:15:30 -0600 Kim Phillips [EMAIL PROTECTED] wrote: Hello all, the following patches fix RGMII timing for rev. 2.1 of the mpc8360, according to erratum #2 (erratum text included below). Basically the most intrusive part is the addition of two new RGMII Internal Delay modes; one for TX delay only, and the other for RX delay only (i.e, not both at the same time). Please review, and since this affects both netdev and powerpc trees, one maintainer should ack them for the other to push upstream (i.e, Kumar acks them, and Leo picks them up to go through netdev or the other way around; either way is fine with me). I'm hoping they're trivial enough to go in 2.6.24. Kumar, Leo, re-ping due to (a) it's been 2 weeks and (b) Anton Vorontsov has since issued his Tested-by. Might I suggest Kumar ack the powerpc patches, and Leo/Jeff apply 5/5 to go through netdev? Kim ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)
Kim Phillips wrote: On Mon, 5 Nov 2007 12:15:30 -0600 Kim Phillips [EMAIL PROTECTED] wrote: Hello all, the following patches fix RGMII timing for rev. 2.1 of the mpc8360, according to erratum #2 (erratum text included below). Basically the most intrusive part is the addition of two new RGMII Internal Delay modes; one for TX delay only, and the other for RX delay only (i.e, not both at the same time). Please review, and since this affects both netdev and powerpc trees, one maintainer should ack them for the other to push upstream (i.e, Kumar acks them, and Leo picks them up to go through netdev or the other way around; either way is fine with me). I'm hoping they're trivial enough to go in 2.6.24. Kumar, Leo, re-ping due to (a) it's been 2 weeks and (b) Anton Vorontsov has since issued his Tested-by. Might I suggest Kumar ack the powerpc patches, and Leo/Jeff apply 5/5 to go through netdev? FWIW I just got back from vacation... I'm grabbing what DaveM has collected into davem/netdev-2.6.git, and then going from there... Jeff ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)
On Thu, Nov 08, 2007 at 01:11:35PM -0600, Kim Phillips wrote: [...] right, but whether it does or not doesn't affect your failure outcome either I'm assuming. If it's something like 0x03, the u-boot patch will probably look like: if ((bcsr[12] == 0x10) (immr-sysconf.spridr == SPR_8360_REV21 || immr-sysconf.spridr == SPR_8360E_REV21)) /* if phy-connection-type is rgmii-id, set it to rgmii-rxid */ ... but these linux patches would remain the same (the clk and data delay settings for the UCC's are still valid; it's just the PHY config that is triggering your problem from what I can tell). Yup, most likely this is not UCC specific, but PHY. For some reason delays making harm here... And today I was unable to reproduce yesterday's behaviour. Your patches works fine, with sixth patch and without it. With -rxid and with just -id. Though, after few resets I hit on that: - - - - U-Boot 1.3.0-rc3-g281df457-dirty (Nov 6 2007 - 18:19:35) MPC83XX Reset Status: External/Internal Soft, External/Internal Hard CPU: e300c1, MPC8360E, Rev: 21 at 528 MHz, CSB: 264 MHz Board: Freescale MPC8360EMDS I2C: ready DRAM: 256 MB (DDR2, 64-bit, ECC on) SDRAM: 64 MB (local bus) FLASH: 32 MB In:serial Out: serial Err: serial Net: UEC: PHY is Marvell 88E11x1 (1410cc2) FSL UEC0: Full Duplex switching to rgmii 100 FSL UEC0: Speed 100BT FSL UEC0: Link is up read wrong value : mii_id 1,mii_reg 2, base e0103120 read wrong value : mii_id 1,mii_reg 3, base e0103120 UEC: PHY is Generic MII () read wrong value : mii_id 1,mii_reg 1, base e0103120 read wrong value : mii_id 1,mii_reg 1, base e0103120 read wrong value : mii_id 1,mii_reg 5, base e0103120 FSL UEC1: Full Duplex switching to rgmii 100 FSL UEC1: Speed 100BT FSL UEC1: Link is up FSL UEC0, FSL UEC1 - - - - And UCC1 does not work at all. After another reset that message disappears and it does work again. So, I think hardware is tricking me in various ways, not your patches fault. :-( -- Anton Vorontsov email: [EMAIL PROTECTED] backup email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)
On Mon, Nov 05, 2007 at 12:15:30PM -0600, Kim Phillips wrote: Hello all, the following patches fix RGMII timing for rev. 2.1 of the mpc8360, according to erratum #2 (erratum text included below). Basically the most intrusive part is the addition of two new RGMII Internal Delay modes; one for TX delay only, and the other for RX delay only (i.e, not both at the same time). Please review, and since this affects both netdev and powerpc trees, one maintainer should ack them for the other to push upstream (i.e, Kumar acks them, and Leo picks them up to go through netdev or the other way around; either way is fine with me). I'm hoping they're trivial enough to go in 2.6.24. All five patches are Tested-by: Anton Vorontsov [EMAIL PROTECTED] Let's hope they'll hit 2.6.24. Thanks, -- Anton Vorontsov email: [EMAIL PROTECTED] backup email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)
On Fri, 9 Nov 2007 16:25:07 +0300 Anton Vorontsov [EMAIL PROTECTED] wrote: On Thu, Nov 08, 2007 at 01:11:35PM -0600, Kim Phillips wrote: [...] right, but whether it does or not doesn't affect your failure outcome either I'm assuming. If it's something like 0x03, the u-boot patch will probably look like: if ((bcsr[12] == 0x10) (immr-sysconf.spridr == SPR_8360_REV21 || immr-sysconf.spridr == SPR_8360E_REV21)) /* if phy-connection-type is rgmii-id, set it to rgmii-rxid */ ... but these linux patches would remain the same (the clk and data delay settings for the UCC's are still valid; it's just the PHY config that is triggering your problem from what I can tell). Yup, most likely this is not UCC specific, but PHY. For some reason delays making harm here... And today I was unable to reproduce yesterday's behaviour. Your patches works fine, with sixth patch and without it. With -rxid and with just -id. excellent. btw, you should be paying a 50% packet loss price by not going with the -rxid. ping your board with '-q -s 1400 -i 0.01 -c 100' to notice the difference. Though, after few resets I hit on that: - - - - U-Boot 1.3.0-rc3-g281df457-dirty (Nov 6 2007 - 18:19:35) MPC83XX Reset Status: External/Internal Soft, External/Internal Hard CPU: e300c1, MPC8360E, Rev: 21 at 528 MHz, CSB: 264 MHz Board: Freescale MPC8360EMDS I2C: ready DRAM: 256 MB (DDR2, 64-bit, ECC on) SDRAM: 64 MB (local bus) FLASH: 32 MB In:serial Out: serial Err: serial Net: UEC: PHY is Marvell 88E11x1 (1410cc2) FSL UEC0: Full Duplex switching to rgmii 100 FSL UEC0: Speed 100BT FSL UEC0: Link is up read wrong value : mii_id 1,mii_reg 2, base e0103120 read wrong value : mii_id 1,mii_reg 3, base e0103120 UEC: PHY is Generic MII () read wrong value : mii_id 1,mii_reg 1, base e0103120 read wrong value : mii_id 1,mii_reg 1, base e0103120 read wrong value : mii_id 1,mii_reg 5, base e0103120 FSL UEC1: Full Duplex switching to rgmii 100 FSL UEC1: Speed 100BT FSL UEC1: Link is up FSL UEC0, FSL UEC1 - - - - And UCC1 does not work at all. After another reset that message disappears and it does work again. the RGMII bcsr settings survive soft-resets, which confuse u-boot since it uses GMII mode. Kim ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)
On Mon, Nov 05, 2007 at 12:15:30PM -0600, Kim Phillips wrote: Hello all, the following patches fix RGMII timing for rev. 2.1 of the mpc8360, according to erratum #2 (erratum text included below). Basically the most intrusive part is the addition of two new RGMII Internal Delay modes; one for TX delay only, and the other for RX delay only (i.e, not both at the same time). Please review, and since this affects both netdev and powerpc trees, one maintainer should ack them for the other to push upstream (i.e, Kumar acks them, and Leo picks them up to go through netdev or the other way around; either way is fine with me). I'm hoping they're trivial enough to go in 2.6.24. Depending on how the review goes, a follow-on patch to u-boot will be sent out that fixes up the phy-connection-type in the device tree (from rgmii-id to rgmii-rxid iff on mpc8360rev2.1). I've upgraded CPU to rev2.1, board rev0.3. Applied 5/5 patches onto paulus/powerpc.git at e403149c92a. Here is the results: If I use -rxid, then geth not able to transmit anything. With -txid geth not able to receive anything. With just -id everything works fine though... Maybe there should be another condition, in addition to cpu rev2.1? Thanks, Kim mpc8360 rev 2.1 erratum #2: --- Recommended AC timings for chip 8360Rev2.1 UCC ETH RGMII when working with Rev Pilot MDS for proper RGMII operation: IMMR_BASE + 0x14A8[4:5] = 11 (clk delay for UCC 2) IMMR_BASE + 0x14A8[18:19] = 11 (clk delay for UCC 1) IMMR_BASE + 0x14AC[20:27] = 10101010 (data delay for both UCC's) The Phy (Marvell 88e) should be configured NOT to work with RGMII delay for TxD. Thanks, -- Anton Vorontsov email: [EMAIL PROTECTED] backup email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)
On Thu, 8 Nov 2007 17:16:11 +0300 Anton Vorontsov [EMAIL PROTECTED] wrote: On Mon, Nov 05, 2007 at 12:15:30PM -0600, Kim Phillips wrote: Hello all, the following patches fix RGMII timing for rev. 2.1 of the mpc8360, according to erratum #2 (erratum text included below). Basically the most intrusive part is the addition of two new RGMII Internal Delay modes; one for TX delay only, and the other for RX delay only (i.e, not both at the same time). Please review, and since this affects both netdev and powerpc trees, one maintainer should ack them for the other to push upstream (i.e, Kumar acks them, and Leo picks them up to go through netdev or the other way around; either way is fine with me). I'm hoping they're trivial enough to go in 2.6.24. Depending on how the review goes, a follow-on patch to u-boot will be sent out that fixes up the phy-connection-type in the device tree (from rgmii-id to rgmii-rxid iff on mpc8360rev2.1). I've upgraded CPU to rev2.1, board rev0.3. thanks for testing this. I tested these patches on a pilot assy 0.3. Applied 5/5 patches onto paulus/powerpc.git at e403149c92a. Here is the results: If I use -rxid, then geth not able to transmit anything. With -txid geth not able to receive anything. With just -id everything works fine though... Maybe there should be another condition, in addition to cpu rev2.1? the errata simply states 'pilot boards', but we can probably modify u-boot to look at the cpu rev and the board rev (BCSR 12). My bcsr12 looks like: = md.b f80c 1 f80c: 10. what is yours? If it's something like 0x03, the u-boot patch will probably look like: if ((bcsr[12] == 0x10) (immr-sysconf.spridr == SPR_8360_REV21 || immr-sysconf.spridr == SPR_8360E_REV21)) /* if phy-connection-type is rgmii-id, set it to rgmii-rxid */ ... but these linux patches would remain the same (the clk and data delay settings for the UCC's are still valid; it's just the PHY config that is triggering your problem from what I can tell). Thanks, Kim mpc8360 rev 2.1 erratum #2: --- Recommended AC timings for chip 8360Rev2.1 UCC ETH RGMII when working with Rev Pilot MDS for proper RGMII operation: IMMR_BASE + 0x14A8[4:5] = 11 (clk delay for UCC 2) IMMR_BASE + 0x14A8[18:19] = 11 (clk delay for UCC 1) IMMR_BASE + 0x14AC[20:27] = 10101010 (data delay for both UCC's) The Phy (Marvell 88e) should be configured NOT to work with RGMII delay for TxD. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)
On Thu, Nov 08, 2007 at 12:15:08PM -0600, Kim Phillips wrote:
On Thu, 8 Nov 2007 17:16:11 +0300
Anton Vorontsov [EMAIL PROTECTED] wrote:
On Mon, Nov 05, 2007 at 12:15:30PM -0600, Kim Phillips wrote:
Hello all,
the following patches fix RGMII timing for rev. 2.1 of the mpc8360,
according to erratum #2 (erratum text included below). Basically the
most intrusive part is the addition of two new RGMII Internal Delay
modes; one for TX delay only, and the other for RX delay only (i.e, not
both at the same time).
Please review, and since this affects both netdev and powerpc trees,
one maintainer should ack them for the other to push upstream (i.e,
Kumar acks them, and Leo picks them up to go through netdev or the
other way around; either way is fine with me). I'm hoping they're
trivial enough to go in 2.6.24.
Depending on how the review goes, a follow-on patch to u-boot will be
sent out that fixes up the phy-connection-type in the device tree (from
rgmii-id to rgmii-rxid iff on mpc8360rev2.1).
I've upgraded CPU to rev2.1, board rev0.3.
thanks for testing this. I tested these patches on a pilot assy 0.3.
Same here.
Applied 5/5 patches onto paulus/powerpc.git at e403149c92a. Here is
the results:
If I use -rxid, then geth not able to transmit anything.
With -txid geth not able to receive anything.
With just -id everything works fine though...
Maybe there should be another condition, in addition to cpu rev2.1?
the errata simply states 'pilot boards', but we can probably modify
u-boot to look at the cpu rev and the board rev (BCSR 12).
My bcsr12 looks like:
= md.b f80c 1
f80c: 10.
what is yours?
= md.b f80c 1
f80c: 10.
:-/
U-Boot 1.3.0-rc3-g281df457-dirty (Nov 6 2007 - 18:19:35) MPC83XX
CPU: e300c1, MPC8360E, Rev: 21 at 528 MHz, CSB: 264 MHz
[EMAIL PROTECTED]:~# cat /proc/cpuinfo
processor : 0
cpu : e300c1
clock : 528.00MHz
revision: 3.1 (pvr 8083 0031)
bogomips: 131.58
timebase: 6600
platform: MPC836x MDS
+ /* handle mpc8360ea rev.2.1 erratum 2: RGMII Timing */
+ svid = mfspr(SPRN_SVR);
+ if (svid == 0x80480021) {
^^ that branch executes on the board I'm testing.
If it's something like 0x03, the u-boot patch will probably look like:
if ((bcsr[12] == 0x10)
(immr-sysconf.spridr == SPR_8360_REV21 ||
immr-sysconf.spridr == SPR_8360E_REV21))
/* if phy-connection-type is rgmii-id, set it to rgmii-rxid */
...
but these linux patches would remain the same (the clk and data delay
settings for the UCC's are still valid; it's just the PHY config
that is triggering your problem from what I can tell).
Yup, most likely this is not UCC specific, but PHY. For some reason
delays making harm here...
Thanks,
--
Anton Vorontsov
email: [EMAIL PROTECTED]
backup email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)
On Thu, 8 Nov 2007 21:39:52 +0300
Anton Vorontsov [EMAIL PROTECTED] wrote:
On Thu, Nov 08, 2007 at 12:15:08PM -0600, Kim Phillips wrote:
On Thu, 8 Nov 2007 17:16:11 +0300
Anton Vorontsov [EMAIL PROTECTED] wrote:
On Mon, Nov 05, 2007 at 12:15:30PM -0600, Kim Phillips wrote:
Hello all,
the following patches fix RGMII timing for rev. 2.1 of the mpc8360,
according to erratum #2 (erratum text included below). Basically the
most intrusive part is the addition of two new RGMII Internal Delay
modes; one for TX delay only, and the other for RX delay only (i.e, not
both at the same time).
Please review, and since this affects both netdev and powerpc trees,
one maintainer should ack them for the other to push upstream (i.e,
Kumar acks them, and Leo picks them up to go through netdev or the
other way around; either way is fine with me). I'm hoping they're
trivial enough to go in 2.6.24.
Depending on how the review goes, a follow-on patch to u-boot will be
sent out that fixes up the phy-connection-type in the device tree (from
rgmii-id to rgmii-rxid iff on mpc8360rev2.1).
I've upgraded CPU to rev2.1, board rev0.3.
thanks for testing this. I tested these patches on a pilot assy 0.3.
Same here.
Applied 5/5 patches onto paulus/powerpc.git at e403149c92a. Here is
the results:
If I use -rxid, then geth not able to transmit anything.
With -txid geth not able to receive anything.
With just -id everything works fine though...
Maybe there should be another condition, in addition to cpu rev2.1?
the errata simply states 'pilot boards', but we can probably modify
u-boot to look at the cpu rev and the board rev (BCSR 12).
My bcsr12 looks like:
= md.b f80c 1
f80c: 10.
what is yours?
= md.b f80c 1
f80c: 10.
:-/
U-Boot 1.3.0-rc3-g281df457-dirty (Nov 6 2007 - 18:19:35) MPC83XX
CPU: e300c1, MPC8360E, Rev: 21 at 528 MHz, CSB: 264 MHz
[EMAIL PROTECTED]:~# cat /proc/cpuinfo
processor : 0
cpu : e300c1
clock : 528.00MHz
revision: 3.1 (pvr 8083 0031)
bogomips: 131.58
timebase: 6600
platform: MPC836x MDS
check. :/
+ /* handle mpc8360ea rev.2.1 erratum 2: RGMII Timing */
+ svid = mfspr(SPRN_SVR);
+ if (svid == 0x80480021) {
^^ that branch executes on the board I'm testing.
right, but whether it does or not doesn't affect your failure outcome
either I'm assuming.
If it's something like 0x03, the u-boot patch will probably look like:
if ((bcsr[12] == 0x10)
(immr-sysconf.spridr == SPR_8360_REV21 ||
immr-sysconf.spridr == SPR_8360E_REV21))
/* if phy-connection-type is rgmii-id, set it to rgmii-rxid */
...
but these linux patches would remain the same (the clk and data delay
settings for the UCC's are still valid; it's just the PHY config
that is triggering your problem from what I can tell).
Yup, most likely this is not UCC specific, but PHY. For some reason
delays making harm here...
hmm..
Net: UEC: PHY is Marvell 88E11x1 (1410cc2)
I have jumper JP1 set to 3.3V.
can you send me your:
= md.b f800 15
f800: 04 04 00 c6 94 60 00 00 ac 2f 00 b8 10 3f 30 02.`.../...?0.
f810: 05 07 05 15 11.
and maybe try the following on top of these 5 patches (to specify rgmii
mode in the bcsr's):
diff --git a/arch/powerpc/platforms/83xx/mpc836x_mds.c
b/arch/powerpc/platforms/83xx/mpc836x_mds.c
index 0a72260..753071e 100644
--- a/arch/powerpc/platforms/83xx/mpc836x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc836x_mds.c
@@ -98,6 +98,11 @@ static void __init mpc836x_mds_setup_arch(void)
!= NULL){
uint svid;
+ /* configure RGMII mode for both GETH ports */
+#define BCSR8_TSECXM_RGMII 0xf0
+ clrbits8(bcsr_regs[8], BCSR8_TSECXM_RGMII);
+
+
/* Reset the Ethernet PHY */
#define BCSR9_GETHRST 0x20
clrbits8(bcsr_regs[9], BCSR9_GETHRST);
Thanks,
Kim
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
