RGMII ethernet is not able to ping in T2081 processor

[Vimalprasad]

Hi all,

I'm working on T2081 custom board and using the RGMII interface where it is connected with the FM1@DTSEC3 of EC1(ethernet connection 1). RCW is selected for EC1 as MAC3.

Im  flashing the fman microcode 106.4.18 in 0xEFC00000.

In uboot I can able to access the phy registers using mii commands from uboot.

Im using the phy address as 0x1C.

But the ping test is failed..

If we connect with PC , the status of ethernet link speed is detecting as 100Mbps but the speed should come as 1Gbps.

Please find the log for your reference,

Uboot> mdio list
FSL_MDIO0:
FM_TGEC_MDIO:
T2081QDS_MDIO_RGMII1:
28 - Microsemi VSC8572 <--> FM1@DTSEC3
T2081QDS_MDIO_RGMII2:
T2081QDS_MDIO_SLOT1:
T2081QDS_MDIO_SLOT2:
T2081QDS_MDIO_SLOT3:
T2081QDS_MDIO_SLOT5:
T2081QDS_MDIO_SLOT6:
T2081QDS_MDIO_SLOT7:
T2081QDS_MDIO_10GC:
Uboot> pri
baudrate=115200
bdev=sda3
bootargs=root=/dev/ram rw console=ttyS0,115200
bootcmd=setenv bootargs root=/dev/ram rw console=$consoledev,$baudrate $othbootargs;setenv ramdiskaddr 0x02000000;setenv fdtaddr 0x00c00000;setenv loadaddr 0x1000000;bootm $loadaddr $ramdiskaddr $fdtaddr
bootdelay=10
bootfile=uImage
consoledev=ttyS0
eth1addr=00:e0:0c:00:a9:02
ethact=FM1@DTSEC3
ethaddr=00:e0:0c:00:a9:01
ethprime=FM1@DTSEC10
fdtaddr=0x00c00000
fdtfile=t2080qds/t2080qds.dtb
fman_addr=0xEFC00000
fman_eaddr=0xEFC07BB8
fman_size=0x7bb8
fman_ucode=efc00000
gatewayip=172.16.1.0
hwconfig=fsl_ddr:ctlr_intlv=cacheline,bank_intlv=auto;usb1:dr_mode=host,phy_type=utmi
initrd_high=0xffffffff
ipaddr=172.16.1.10
loadaddr=0x1000000
netdev=eth0
netmask=255.255.0.0
nfsboot=setenv bootargs root=/dev/nfs rw nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:off console=$consoledev,$baudrate $othbootargs;tftp $loadaddr $bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr - $fdtaddr
ramboot=setenv bootargs root=/dev/ram rw console=$consoledev,$baudrate $othbootargs;tftp $ramdiskaddr $ramdiskfile;tftp $loadaddr $bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr $ramdiskaddr $fdtaddr
ramdiskaddr=0x02000000
ramdiskfile=t2080qds/ramdisk.uboot
rootpath=/opt/nfsroot
serverip=172.16.1.100
stderr=serial
stdin=serial
stdout=serial
tftpflash=tftpboot $loadaddr $uboot && protect off $ubootaddr +$filesize && erase $ubootaddr +$filesize && cp.b $loadaddr $ubootaddr $filesize && protect on $ubootaddr +$filesize && cmp.b $loadaddr $ubootaddr $filesize
uboot="u-boot.bin"
ubootaddr=0xeff40000

Environment size: 1670/8188 bytes
Uboot> ping 172.16.1.100
MMDC : @genphy_update_link
Using FM1@DTSEC3 device

ARP Retry count exceeded; starting again
ping failed; host 172.16.1.100 is not alive
Uboot>
MMDC : @genphy_update_link
Using FM1@DTSEC3 device
FM1@DTSEC3: Tx error, txbd->status = 0x8800
FM1@DTSEC3: Tx buffer not ready, txbd->status = 0x8800
FM1@DTSEC3: Tx buffer not ready, txbd->status = 0x8800
FM1@DTSEC3: Tx buffer not ready, txbd->status = 0x8800

ARP Retry count exceeded; starting again
ping failed; host 172.16.1.100 is not alive

Can please tell me the solution to make the ethernet to ping?

[yipingwang]

FMAN ucode should be deployed at 0xEFF00000.

[noufalp90]

Hi @yipingwang Thank you for your reply.

We have flashed at 0xEFF00000 and still facing issue. 

Other than configuring RCW for clock and MAC3 configuration, do we have to take care anyting on the u-boot for clock?? WIth 100Mbps, auto neg is happening properly but still the ping is reporting error as 

"""

Using FM1@DTSEC3 device
FM1@DTSEC3: Tx error, txbd->status = 0x8800
FM1@DTSEC3: Tx buffer not ready, txbd->status = 0x8800
FM1@DTSEC3: Tx buffer not ready, txbd->status = 0x8800
FM1@DTSEC3: Tx buffer not ready, txbd->status = 0x8800

ARP Retry count exceeded; starting again
Iteration: 0 => ping failed; host 172.16.1.101 is not alive

"""

Thanks,

Noufal P

Project Lead

CoreEL Technologies

[yipingwang]

For this reason, only a few generic recommendations can be given:

1. Make sure u-Boot properly detects and initializes the main system

memory. Test the memory for stability.

2. Diff your u-Boot against the SDK one, analyse the difference in the

network initialization. Keep in mind that we do not verify every u-Boot

release with our processors.

3. Roll back any changes unless you clearly understand why they are

   introduced and what they do.

4. Basically, failure to update BDs means either:

    (a) The microcode was not loaded;

    (b) FMAN controller is unable to locate it's memory structures;

    (c) There is no clock on the interface.

5. Putting into account the reasons stated in pt.4, use a debugger to

   ensure:

    (a) The microcode load routine assesses the correct locations

    to load and activate the microcode;

    (b) Verify that FMAN IM memory structures meet the description

    given in T1024DPAARM, Section 5.13.15, don't overlap each other

    and are not corrupt by other software components or DMA-enabled peripherals.

6. Use a scope to ensure that  EC1_GTX_CLK125 input receives a signal

   of a waveform that fully meets the requirements of the processor

   Hardware Specification.

[noufalp90]

Hi @yipingwang 

We are using same version of u-boot mentioned in the SDK (2016.09). We have probed EC1_GTX_CLK125 line, and we didn't see any clock on this line. 

Thanks,

Noufal P

[yipingwang]

Ethernet reference clock (125MHz) should be connected to one of ECn_GTX_CLK125, typically to EC1_GTX_CLK125.

Please refer to T2080RDB reference design.

[noufalp90]

Hi @yipingwang 

In our design we are using VSC8572 PHY where RCVRDCLK1 in the PHY is used as input to EC1_GTX_CLK125.

Thanks

Noufal P

Project Lead

CoreEL Technologies

[yipingwang]

Please refer to https://www.nxp.com.cn/docs/en/application-note/AN4804.pdf

and T2080RDB reference design.