LS1020A eTSEC3 not receiving packets

[laurawhitmire]

I'm bringing up software on a board that is based on the TWR-LS1021A-PB.  My board has a LS1020A, but the SDRAM and NOR Flash are the same.  I'm using eTSEC3 connected to PHY0.

In U-Boot, eTSEC3 works: I can run ping, dhcp, and tftp -- but only if eTSEC1 is enabled.  In VxWorks, I can't get eTSEC3 to work.  Currently I have eTSEC1 and eTSEC2 disabled, but it doesn't work with them enabled, either.  The software is identical to what I'm running on the TWR-LS1021A-PB (which works); only the device tree and hardware are different.

On my board, I never get any eTSEC interrupts.  I also notice that eTSEC3_RDRP (receive drop counter) increments at about the same rate I would expect to receive packets.  Are these symptoms related?

Any pointers on where to look?

[ufedor]

You wrote:

> In U-Boot, eTSEC3 works

This means that there is no hardware issue - i.e. processor connection and RCW are correct.

Please apply to the Wind River support service and ask them for assistance in VxWorks configuring.

[laurawhitmire]

Why would the same code work on the TWR-LS1021A-PB but not on my board?  What does it mean exactly when eTSEC3_RDRP increments?  Is it possible to use eTSEC3 without eTSEC1 being active?

[ufedor]

You wrote:

> Why would the same code work on the TWR-LS1021A-PB but not on my board?

What are the differences between the boards?

> What does it mean exactly when eTSEC3_RDRP increments?

Frames are dropped due to lack of system resources:

1) Rx FIFO Overrun. RxBD[OV], RxBD[L] & IEVENTG[RXF] are set.

2) No RxBDs ready. IEVENTG[BSY] & RSTAT[QHLTn] are set.

3) eTSEC DMA bus error. IEVENTG[EBERR] & RSTAT[QHTLn] are set.     

[laurawhitmire]

Thanks for your quick response.

Differences between boards:

- Mine is a brand new, untested board

- My board uses LS1020A, TWR uses LS1021A

- My board disables eTSEC1 and eTSEC2, TWR enables both eTSECs for SGMII

- My board uses eTSEC3 with PHY 0 in RGMII mode, TWR uses eTSEC3 with PHY 1 in RGMII mode

- My board uses a slightly different device tree to handle the above differences

- My board has a slightly different RCW than the TWR's

Similarities between boards: Same SDRAM, same NOR Flash, same VxWorks code (device tree is used to handle hardware differences)

IEVENTG is 0x00000000.  RSTAT is 0x00000000.  RBASE is set to a valid physical address.  On my board all RxBDs have the E bit set to 0 and DATA LENGTH set to 0, which I think probably means the receive was aborted due to error.  I suspect some sort of DMA error, but I don't know how to prove it.

[swanandpurankar]

As you are using different board, Have you checked your connections for ECx_GTXCLK_125 pin? On tower board, Clock is connected to EC3_GTXCLK_125 pin. In your case, if it is connected to different pin then you have to enable it via SCFG_ETSECCMCR register.

Also, As per datasheet, PHY address 0 is reserved and you should not use it.

[laurawhitmire]

My board also uses EC3_GTXCLK_125, and my SCFG_ETSECCMCR register matches the TWR's.

Can you point me to exactly where in the data sheet it talks about PHY 0?

[swanandpurankar]

In reference manual, it is mentioned at two places:

1. Section 20.5.11 TBI PHY address register (eTSECx_TBIPA)

2. Section 20.7.6 MII management address register (eTSECx1_MDIO_MIIMADD)

In both sections, where it describes about PHY addresses, it is mentioned that "0 is reserved"

[laurawhitmire]

Thanks for your reply.  I didn't think section 20.5.11 applied in my case, since I'm not using the TBI.  I'm using RGMII with an external Marvell PHY.  I guess section 20.7.6 applies.

At any rate, the hardware guy changed the PHY address to 1, like on the TWR board, but I still have the same problem: no interrupts either on transmit or receive.

[laurawhitmire · Accepted solution]

The problem turned out to be SCFG_ETSECDMAMCR. This register is set in U-Boot and never touched by VxWorks. In the U-Boot that came with the TWR-LS1021A-PB, 2015.01+ls1+g3281947 (Jul 30 2015 - 20:01:52), ETSEC_BD was set (little endian buffer descriptors). In the U-Boot I downloaded for my board, 2016.07, ETSEC_BD was was cleared (big endian BDs), and the eTSEC driver (drivers/net/tsec.c) expected that. However, my VxWorks eTSEC driver expected little endian BDs. Since VxWorks never touches any SCFG register -- it never maps them in -- I updated my U-Boot to enable little endian BDs right before it loads VxWorks.

[ufedor]

> Why would the same code work on the TWR-LS1021A-PB

Have you tried the same code, same device tree and RCW on your board?

Is eTSEC3 operational in this configuration?

[laurawhitmire]

I’m using the same code, but the device trees are different due to PHY numbering. I did try using the TWR device tree on my board, but it did not change the problem. The RCWs are different due to differences between the boards and it’s too risky to try the TWR RCW on my board.

If there were a problem with DMA on my board, how would I prove it?

[ufedor]

I could recommend to create a Technical Case to investigate the issue - please refer the following link:

https://community.freescale.com/thread/381898