[U-Boot] mpc8343: TSEC1 @ RGMII stopped working

[U-Boot] mpc8343: TSEC1 @ RGMII stopped working

[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:
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

[U-Boot] mpc8343: TSEC1 @ RGMII stopped working

[Felix Radensky]

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.

[U-Boot] mpc8343: TSEC1 @ RGMII stopped working

[André Schwarz]

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

[U-Boot] mpc8343: TSEC1 @ RGMII stopped working

[Kim Phillips]

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

[U-Boot] mpc8343: TSEC1 @ RGMII stopped working

[Andre Schwarz]

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

[U-Boot] mpc8343: TSEC1 @ RGMII stopped working

[Kim Phillips]

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

[U-Boot] mpc8343: TSEC1 @ RGMII stopped working

[André Schwarz]

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