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,
Quoted 20 lines · Andr? Schwarz
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:
PHY0x10: OUI =0x01C1, Model =0x02, Rev =0x01, 10baseT, HDX ->TSEC1 plugged into GigE Network.
PHY0x11: OUI =0x01C1, Model =0x02, Rev =0x01, 100baseT, FDX PHY0x1F: OUI =0x0000, Model =0x00, Rev =0x00, 10baseT, HDX
Quoted 8 lines
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,
Quoted 5 lines
Quoted 2 lines
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?
Quoted 2 lines
Felix.
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Hans-Joachim Reich
Quoted 10 lines · On Mon, 21 Jun 2010 13:04:40 +0200 Andr? Schwarz…
Felix,
Quoted 3 lines
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 ?
Quoted 5 lines
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]
Quoted 5 lines
you can try applying commit
71bd860cce4493c5def07804723661e75271052b"mpc83xx: don't shift pre-shifted ACR, SPCR, SCCR bitfield masks incpu_init." but I don't think that's the problem, since it doesn't affect the p2020.
This is already present in current master.
Quoted 2 lines
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
Quoted 1 line · On Tue, 22 Jun 2010 11:29:30 +0200 Andre Schwarz…
are you using TOT of mpc83xx or master ?
Wolfgang's master.
Quoted 5 lines
Quoted 5 lines
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
Quoted 8 lines
[snip]
Quoted 5 lines
you can try applying commit
71bd860cce4493c5def07804723661e75271052b"mpc83xx: don't shift pre-shifted ACR, SPCR, SCCR bitfield masks incpu_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.
Quoted 5 lines
Quoted 2 lines
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,
Quoted 1 line
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
....
Quoted 8 lines
[snip]
Quoted 2 lines
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.
Quoted 3 lines
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.
Quoted 11 lines
Quoted 6 lines
Quoted 3 lines
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