[U-Boot] mpc8343: TSEC1 @ RGMII stopped working
Kim,
the 2nd TSEC has stopped working on both U-Boot and Linux on our MPC8343 based system (MVBLM7). Actually I stumbled over this by accident...
TSEC0+1 are using an VSC8601 connected via RGMII.
Since both Bootloader (U-Boot 2010.3) and OS (Linux 2.6.26.27) are affected I suspect a configuration problem.
The PHY is working fine according to LED signalling.
mvBL-M7> mii info ->TSEC0 unplugged: PHY 0x10: OUI = 0x01C1, Model = 0x02, Rev = 0x01, 10baseT, HDX ->TSEC1 plugged into GigE Network. PHY 0x11: OUI = 0x01C1, Model = 0x02, Rev = 0x01, 100baseT, FDX PHY 0x1F: OUI = 0x0000, Model = 0x00, Rev = 0x00, 10baseT, HDX
mvBL-M7> set ethact TSEC1 mvBL-M7> bootp Speed: 1000, full duplex Random delay: 603 ms... BOOTP broadcast 1 ....
Any hints where to look ? Have I missed some changes lately ?
Regards, André
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Hans-Joachim Reich
Hi Andre,
André Schwarz wrote:
Kim,
the 2nd TSEC has stopped working on both U-Boot and Linux on our MPC8343 based system (MVBLM7). Actually I stumbled over this by accident...
TSEC0+1 are using an VSC8601 connected via RGMII.
Since both Bootloader (U-Boot 2010.3) and OS (Linux 2.6.26.27) are affected I suspect a configuration problem.
The PHY is working fine according to LED signalling.
mvBL-M7> mii info ->TSEC0 unplugged: PHY 0x10: OUI = 0x01C1, Model = 0x02, Rev = 0x01, 10baseT, HDX ->TSEC1 plugged into GigE Network. PHY 0x11: OUI = 0x01C1, Model = 0x02, Rev = 0x01, 100baseT, FDX PHY 0x1F: OUI = 0x0000, Model = 0x00, Rev = 0x00, 10baseT, HDX
mvBL-M7> set ethact TSEC1 mvBL-M7> bootp Speed: 1000, full duplex Random delay: 603 ms... BOOTP broadcast 1 ....
I have the same problem on P2020RDB (VSC7385 with RGMII) with TOT u-boot. The last working version seems to be u-boot-2009.11. Didn't have time to git-bisect that yet.
Felix.
Felix,
I have the same problem on P2020RDB (VSC7385 with RGMII) with TOT u-boot. The last working version seems to be u-boot-2009.11. Didn't have time to git-bisect that yet.
huh - this is good news :-) Thought we have a production issue...
Hopefully I find some time next week to dig into this. Nevertheless I'm waiting for Kim's comment.
Regards, André
Felix.
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Hans-Joachim Reich
On Mon, 21 Jun 2010 13:04:40 +0200 André Schwarz andre.schwarz@matrix-vision.de wrote:
Felix,
I have the same problem on P2020RDB (VSC7385 with RGMII) with TOT u-boot. The last working version seems to be u-boot-2009.11. Didn't have time to git-bisect that yet.
huh - this is good news :-) Thought we have a production issue...
Hopefully I find some time next week to dig into this. Nevertheless I'm waiting for Kim's comment.
ToT seems to be working fine for me (using different PHYs though):
U-Boot 2010.06-rc2-00035-g1f24126 (Jun 21 2010 - 11:16:54) MPC83XX
Reset Status: Software Hard, External/Internal Soft, External/Internal Hard
CPU: e300c1, MPC8349EA, Rev: 3.0 at 528 MHz, CSB: 264 MHz Board: Freescale MPC8349EMDS I2C: ready SPI: ready DRAM: 256 MiB (DDR2, 64-bit, ECC on, 264 MHz) FLASH: 32 MiB In: serial Out: serial Err: serial Net: TSEC0, TSEC1
Type "run flash_nfs" to mount root filesystem over NFS
Hit any key to stop autoboot: 0 => tftp Speed: 1000, full duplex Using TSEC0 device TFTP from server 192.168.1.1; our IP address is 192.168.1.183 Filename 'kimphill/uImage-83xx'. Load address: 0x800000 Loading: ################################################################# ################################################################# ######### done Bytes transferred = 2028499 (1ef3d3 hex) => setenv ethact TSEC1 => tftp Speed: 1000, full duplex Using TSEC1 device TFTP from server 192.168.1.1; our IP address is 192.168.1.183 Filename 'kimphill/uImage-83xx'. Load address: 0x800000 Loading: ################################################################# ################################################################# ######### done Bytes transferred = 2028499 (1ef3d3 hex) =>
you can try applying commit 71bd860cce4493c5def07804723661e75271052b "mpc83xx: don't shift pre-shifted ACR, SPCR, SCCR bitfield masks in cpu_init." but I don't think that's the problem, since it doesn't affect the p2020.
Upgrade to ToT? Start a git bisect? on drivers/net/tsec.c?
Kim
Kim,
are you using TOT of mpc83xx or master ?
ToT seems to be working fine for me (using different PHYs though):
U-Boot 2010.06-rc2-00035-g1f24126 (Jun 21 2010 - 11:16:54) MPC83XX
[snip]
you can try applying commit 71bd860cce4493c5def07804723661e75271052b "mpc83xx: don't shift pre-shifted ACR, SPCR, SCCR bitfield masks in cpu_init." but I don't think that's the problem, since it doesn't affect the p2020.
This is already present in current master.
Upgrade to ToT? Start a git bisect? on drivers/net/tsec.c?
I'm on ToT of current master. Tried starting a bisect, but couldn't find a working version ... went back until v2009.1 ... very strange.
Checking both PHY's with "mii read" clearly showed both PHYs are up and running and are configured the same way (besides adress of course).
Checking RGMII I/F with the scope shows that Rx from both PHYs is working fine, but TSEC2_TXD[0:3] are dead, i.e. no output at all. TSEC2_GTX_CLK is active (125MHz) as soon as a Tx should happen.
Will double check the settings.
Felix - is there any chance that you can check your Tx lines of the 2nd MAC ?
Regards, André
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Hans-Joachim Reich
On Tue, 22 Jun 2010 11:29:30 +0200 Andre Schwarz andre.schwarz@matrix-vision.de wrote:
are you using TOT of mpc83xx or master ?
Wolfgang's master.
ToT seems to be working fine for me (using different PHYs though):
U-Boot 2010.06-rc2-00035-g1f24126 (Jun 21 2010 - 11:16:54) MPC83XX
[snip]
you can try applying commit 71bd860cce4493c5def07804723661e75271052b "mpc83xx: don't shift pre-shifted ACR, SPCR, SCCR bitfield masks in cpu_init." but I don't think that's the problem, since it doesn't affect the p2020.
This is already present in current master.
right, but both of you didn't give enough version data in your initial postings for me to know whether it was included - you mentioned you were on 2010.3, whereas this commit is v2010.03-334-g71bd860, i.e. 334 commmits after the 2010.3 release.
btw, the u-boot banner gives the sha on which it is based - e.g., mine above is based on commit 1f24126.
Upgrade to ToT? Start a git bisect? on drivers/net/tsec.c?
I'm on ToT of current master. Tried starting a bisect, but couldn't find a working version ... went back until v2009.1 ... very strange.
some register settings, esp. in the case of the commit above, survive a soft-reset, so bisecting may not help unless the board is completely power-cycled between each iteration.
Kim
Kim,
Wolfgang's master.
ok - so do I :
U-Boot 2010.06-rc2-00039-g29cf267-dirty (Jun 23 2010 - 07:49:01) MPC83XX
Reset Status:
CPU: e300c1, MPC8343A, Rev: 3.0 at 400 MHz, CSB: 266.667 MHz ....
[snip]
This is already present in current master.
right, but both of you didn't give enough version data in your initial postings for me to know whether it was included - you mentioned you were on 2010.3, whereas this commit is v2010.03-334-g71bd860, i.e. 334 commmits after the 2010.3 release.
ok - sorry for that.
btw, the u-boot banner gives the sha on which it is based - e.g., mine above is based on commit 1f24126.
ahh ... I see.
Upgrade to ToT? Start a git bisect? on drivers/net/tsec.c?
I'm on ToT of current master. Tried starting a bisect, but couldn't find a working version ... went back until v2009.1 ... very strange.
some register settings, esp. in the case of the commit above, survive a soft-reset, so bisecting may not help unless the board is completely power-cycled between each iteration.
Even power-cycling didn't help.
What I can clearly see on the scope is :
- RGMII is working fine on TSEC0 - RGMII Tx @ TSEC1 is dead (except 125MHz GTXClk), i.e. TxD[0:3] and TxEn are always low. - RGMII Rx from PHY works fine.
Adding some debug info to tsec.c shows that both MACs are configured the same way, e.g. ecntrl regs are both set to RGMII.
I know this smells like a hardware issue - although I have 4 boards behaving the same way ... and I *know* that both TSECs have been working fine.
Can you think of any settings leading to this behaviour ? Any help would be truly appreciated.
Regards, André
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Hans-Joachim Reich
participants (4)
-
Andre Schwarz -
André Schwarz
-
Felix Radensky -
Kim Phillips