LS1028A ENETC TX BDR does not send packet

[mathuzalem]

Hi experts,

I’m working on two boards LS1028ARDB and our custom LS1028A based board developing a bare-metal driver for ENETC. The issue is the same on both boards so lets focus on RDB.

TX BDR consumer seems not to be triggered.  I can see in debugger that producer index increments correctely but consumer doesn’t process any descriptor (consumer index = 0) till TX ring gets full.

Basically the driver is an adaptation of fsl_enetc.c from LSDK u-boot.

PCIe ECAM is working. I’m able to read/write external devices connected through MDIO on both boards. On RDB I can poll link up on 1G MAC0 interface by Reading PHY registers.

BDR are statically allocated in RAM with __attribute__((aligned(128)))

I tried several approaches with no success (cache enabled / cache disabled) with SICAR0 set accordingly but I don’t really trust SICAR0 value when cache is disabled.

1/ With cache enabled I used SDK setup :

/* write cache cfg: snoop, no allocate, data & BD coherent */

#define  ENETC_SICAR_WR_CFG 0x6767

/* read cache cfg: coherent copy, look up, don't alloc in cache */

#define  ENETC_SICAR_RD_CFG 0x27270000

2/ With cache disabled I tried two configs :

#ifdef NOCACHE_DEV

/* Non-cacheable noncoherent/register space access */

#define  ENETC_SICAR_WR_CFG 0x3030

/* Non-cacheable noncoherent/register space access */

#define  ENETC_SICAR_RD_CFG 0x30300000

#elif (defined(NONCOH_MEM))

/* Non-coherent write of cacheable memory, look up in downstream cache, allocate on miss */

#define  ENETC_SICAR_WR_CFG 0x0303

/* Non-coherent copy of cacheable memory, do not look up or allocate in downstream cache*/

#define  ENETC_SICAR_RD_CFG 0x03030000

Any Idea to force TX ring to transmit packets at least for hardware testing would be welcome.

RX path doesn’t work better…

Best regards

[mathuzalem]

Now checking the RX path, I can see with my debugger that RB0DCR (Rx BDR 0 Drop Count Register) increments when I send packets from my PC with an in-house tool.

Device Ref. Manual says: "This is the receive BDR drop count register, it counts the number of frames dropped due to lack of receive buffer descriptors available"

So ENETC doesn't see descriptors I provided. I have been thinking about a PCIe mapping or cache misconfiguration but lot of things are working well including this Drop Counter!

It should be the same issue on TX path.

[mathuzalem]

Gotcha: was wrong DDR parameters for LS1028ARDB +  Apparently ENETC cannot access On-Chip RAM. 

1/ Any reason that prevent ENETC from accessing OCRAM?

2/ Can ENETC work with MMU & Cache disabled? (just for reference)

[yipingwang]

For our LS1028ARDB board, is ENETC working well in uboot in your case?

if it's working well, I suggest you can dump ENETC related registers value, and compare them with yours.

Thanks

[mathuzalem]

Thanks for your reply.

1/ Yes, I built SDK images and run them from SD card. No problem so far on LS1028ARDB. My bare metal driver (fsl_enetc.c adaptation) works as well on that board. 

2/ I just managed the bare metal driver to work on my custom board but I had to change our RCW (SRDS_PRTCL_
S1_L0) to SGMII-1G-T. If I set SGMII-2.5G-T I cannot access internal PCS PHY (Reading ID regs return 0x0) and ENETC does not send packets.

Thanks.

[yipingwang]

Whether the bare metal driver works well on your custom board when setting RCW (SRDS_PRTCL_S1_L0) to SGMII-1G-T?



1.
Refer to LS1028ARDBGSG.pdf(LS1028A Reference Design Board Getting Started Guide),
eno0(ENETC port0) is 1GbE from ENETC SGMII MAC interface in default.



if want to use 2.5G speed, should config Serdes options in RCW, you can refer to "29.1.2 SerDes options" in LS1028ARM.pdf,
should config SGMII 2.5G-T correctly.



2.
Have the PHY in the custom board been verified from hardward perspective? it's working well, right?

[mathuzalem]

Hi,

Thanks for your reply. indeed I modified our RCW accordingly. As a matter of fact Enetc Port0 is connected to an external Ethernet switch chip on our board and that chip seems to work. Will get back to 2.5G test later as we need to validate hardware for the moment, at least with SGMII-1G-T configuration.

Best Regards.