TDA4VM: Running CPSW Loopback Test

Hi,

Can you check output on other UART ports?

The USB to serial interface enumerated four serial ports. The u-boot and kernel logs come on the first COM port, could you check if you see any output on other COM ports?

Regards,
Vishal

It would most likely be the third instance that of COM port.

Hi Vishal,

Thank you for the reply.

I tried the other three COM ports, but there is no output there either.

I even tried the two COM port for MCU UART, only some hex output on the first one.

Below is the result of ls -l /lib/firmware/

root@j7-evm:/lib/firmware# ls -l
-rwxrwxrwx 1 root root    2046 Feb 17 2020 LICENCE.iwlwifi_firmware
-rwxrwxrwx 1 root root  735916 Feb 17 2020 app_remoteswitchcfg_server_pdk_mem_map_strip.xer5f
drwxrwxrwx 2 root root    4096 Feb 17 2020 cadence
-rwxrwxrwx 1 root root 4582268 Feb 17 2020 cpsw_loopback_testapp_mcu2_0_release.xer5f
-rwxrwxrwx 1 root root  918268 Feb 17 2020 iwlwifi-3160-17.ucode
-rwxrwxrwx 1 root root 1745176 Feb 17 2020 iwlwifi-8000C-13.ucode
-rwxrwxrwx 1 root root 2351636 Feb 17 2020 iwlwifi-8000C-16.ucode
-rwxrwxrwx 1 root root 2394060 Feb 17 2020 iwlwifi-8000C-21.ucode
-rwxrwxrwx 1 root root 2120860 Feb 17 2020 iwlwifi-8000C-22.ucode
-rwxrwxrwx 1 root root 2227284 Feb 17 2020 iwlwifi-8000C-27.ucode
-rwxrwxrwx 1 root root 2310116 Feb 17 2020 iwlwifi-8000C-31.ucode
-rwxrwxrwx 1 root root 2448976 Feb 17 2020 iwlwifi-8000C-34.ucode
-rwxrwxrwx 1 root root 2486572 Feb 17 2020 iwlwifi-8000C-36.ucode
-rwxrwxrwx 1 root root 2389968 Feb 17 2020 iwlwifi-8265-21.ucode
-rwxrwxrwx 1 root root 1811984 Feb 17 2020 iwlwifi-8265-22.ucode
-rwxrwxrwx 1 root root 2234528 Feb 17 2020 iwlwifi-8265-27.ucode
-rwxrwxrwx 1 root root 2307104 Feb 17 2020 iwlwifi-8265-31.ucode
-rwxrwxrwx 1 root root 2440780 Feb 17 2020 iwlwifi-8265-34.ucode
-rwxrwxrwx 1 root root 2498044 Feb 17 2020 iwlwifi-8265-36.ucode
lrwxrwxrwx 1 root root      64 Apr  9 2020 j7-c66_0-fw -> /lib/firmware/pdk-ipc/ipc_echo_test_c66xdsp_1_release.strip.xe66
-rw-r--r-- 1 1000 1000 1448016 Mar 25 2020 j7-c66_0-fw.bak
lrwxrwxrwx 1 root root      64 Apr  9 2020 j7-c66_1-fw -> /lib/firmware/pdk-ipc/ipc_echo_test_c66xdsp_2_release.strip.xe66
-rw-r--r-- 1 1000 1000 1448016 Mar 25 2020 j7-c66_1-fw.bak
lrwxrwxrwx 1 root root      60 Apr  9 2020 j7-c71_0-fw -> /lib/firmware/pdk-ipc/ipc_echo_test_c7x_1_release.strip.xe71
-rw-r--r-- 1 1000 1000 6954352 Mar 25 2020 j7-c71_0-fw.bak
lrwxrwxrwx 1 root root      56 Feb 17 2020 j7-main-r5f0_0-fw -> /lib/firmware/cpsw_loopback_testapp_mcu2_0_release.xer5f
-rw-r--r-- 1 1000 1000  128832 Mar 25 2020 j7-main-r5f0_0-fw.bak
lrwxrwxrwx 1 root root      64 Apr  9 2020 j7-main-r5f0_0-fw~ -> /lib/firmware/app_remoteswitchcfg_server_pdk_mem_map_strip.xer5f
lrwxrwxrwx 1 root root      62 Apr  9 2020 j7-main-r5f0_1-fw -> /lib/firmware/pdk-ipc/ipc_echo_test_mcu2_1_release.strip.xer5f
-rw-r--r-- 1 1000 1000 3811288 Mar 25 2020 j7-main-r5f0_1-fw.bak
lrwxrwxrwx 1 root root      62 Apr  9 2020 j7-main-r5f1_0-fw -> /lib/firmware/pdk-ipc/ipc_echo_test_mcu3_0_release.strip.xer5f
lrwxrwxrwx 1 root root      62 Apr  9 2020 j7-main-r5f1_1-fw -> /lib/firmware/pdk-ipc/ipc_echo_test_mcu3_1_release.strip.xer5f
lrwxrwxrwx 1 root root      63 Apr  9 2020 j7-mcu-r5f0_0-fw -> /lib/firmware/pdk-ipc/ipc_echo_testb_mcu1_0_release.strip.xer5f
lrwxrwxrwx 1 root root      62 Apr  9 2020 j7-mcu-r5f0_1-fw -> /lib/firmware/pdk-ipc/ipc_echo_test_mcu1_1_release.strip.xer5f
-rwxrwxrwx 1 root root  108552 Feb 17 2020 jailhouse.bin
drwxrwxrwx 2 root root    4096 Feb 17 2020 pdk-ipc
drwxrwxrwx 2 root root    4096 Feb 17 2020 pru
-rwxrwxrwx 1 root root  247469 Feb 17 2020 pvdec_full_bin.fw
-rwxrwxrwx 1 root root    4196 Feb 17 2020 regulatory.db
-rwxrwxrwx 1 root root    1182 Feb 17 2020 regulatory.db.p7s
-rwxrwxrwx 1 root root 1400832 Feb 17 2020 rgx.fw.22.104.208.318
-rwxrwxrwx 1 root root 1400832 Feb 17 2020 rgx.fw.22.104.208.318.vz
drwxrwxrwx 2 root root    4096 Feb 17 2020 ti-connectivity
-rwxrwxrwx 1 root root 2179860 Feb 17 2020 ti-display-sharing-j721e.bin

Is there anything wrong with the links?

Does EVM board have to connect to ethernet for loopback test?

Best regards,

Eric Chen

Hi Eric,

Your links are OK, as R5 SPL was able to load mcu2_0 firmware. The R5 SPL log "Remoteproc 2 started successfully" shows that.

U-Boot SPL 2019.01-g350f3927b8 (Feb 17 2020 - 09:46:23 +0000)
SYSFW ABI: 2.9 (firmware rev 0x0013 '19.12.1-v2019.12a (Terrific Lla')
Trying to boot from MMC2
Loading Environment from MMC... *** Warning - No MMC card found, using default environment

Remoteproc 2 started successfully
Starting ATF on ARM64 core...

Let me check with team and get back.

Regards,
Vishal

Hi Vishal,

Thank you for the quick reply.

I'll check other settings too.

Best regards,

Eric Chen

Hi Vishal,

It does not seem to be the COM port problem.

If I use this link j7-main-r5f0_0-fw -> /lib/firmware/app_remoteswitchcfg_server_pdk_mem_map_strip.xer5f, the third COM port shows

Enabling clocks for CPSW_9G!
=======================================================
           CPSW Ethernet Firmware Demo
=======================================================
ETHFW Version: 0. 1. 1
ETHFW Build Date (YYYY/MMM/DD):2020/Feb/10
ETHFW Commit SHA:ETHFW PermissionFlag:0x1ffffff, UART Connected:true,UART Id:2CpswAppBoardUtils_getMacAddrList Failed - GESI/ENET board not present
IPC_echo_test (core : mcu2_0) .....
Assertion @ Line: 691 in V1/cpsw_appboardutils_j721e_evm.c: false : failed !!!

Since we do not have GESI board on our EVM, it failed. (instead, we have J7x QUAD PORT ENET EXP board on our EVM)

Is there any dependency of the cpsw_loopback_testapp_mcu2_0_release.xer5f?

Could you please provide your cpsw_loopback_testapp_mcu2_0_release.xer5f for me to test?

Thank you!

Best regards,

Eric Chen

Hi Eric,

(Q)SGMII is not enabled in the Ethernet Firmware image built for Linux in Processor SDK 6.2 release, due to a SERDES resource utilization conflict between PCIe and (Q)SGMII. In your last logs, the firmware fails to find a GESI board attached to the EVM and since (Q)SGMII is not enabled, it doesn't even try to detect the QUAD Eth board.

Back to the CPSW loopback example - it's not originally meant to coexist with Linux, we typically test it loading the binary via CCS. The main reason is that the loopback example does a blanket configuration of pinmux, clocks, etc. which causes conflict with Linux. That being said, it should be possible to enable that example code for Linux.

Let's try these:

1. In <pdk>/packages/ti/drv/cpsw/examples/cpsw_loopback_test/main_tirtos.c - replace CpswAppBoardUtils_init() with CpswAppBoardUtils_initEthFw()
2. Make sure SDK_6_2_CORE_SDK_IMAGE is undefined in CPSW LLD's cpsw_component.mk. This will enable SGMII/QSGMII related board initialization
3. Disable PCIe in your devicetree configuration in Linux. Try disabling the top level pcie node.

Regards,

-Misa

Hi Misa,

Thank you for the explanation.

Here is my comprehension:

  1. In PSDKLA 6.2 release, it is not possible to use PCIE and SGMII at the same time.

  2. QUAD Eth board works only if GESI board is attached to the EVM.

Am I understanding these correctly?

And I have one more question here.

To test SGMII, I should try the three steps to run CPSW loopback test and CPSW nimu example, right?

Many thanks!

Best regards,

Eric Chen

Hi Eric,

-1- Yes, it's not possible to have PCIe and SGMII at the same time.

-2- Quad Eth should work without GESI board. In my previous reply, I meant to say that (a) GESI board was not detected at runtime in your EVM, and (b) Quad Eth board is not enabled at compile-time in the SDK 6.2 Ethernet firmware image. But (a) and (b) are not directly related, they are just two observations from your Ethernet firmware logs.

Regarding the test with the QSGMII ports in the Quad Eth board - yes, the 3 steps that I suggested would be necessary to avoid pinmux conflicts between Linux and CPSW example's board initialization. The memory map in the CPSW examples may also need to be changed to coexist with Linux. I'll have to double check that.

Hi Misa,

Thank you for the further explanation.

I'll try the three steps and run CPSW loopback test first.

If there is any update, I'll reply down below too.

Best regards,

Eric Chen

Hi Misa,

A quick question here:

Will the SERDES resource utilization conflict between PCIe and SGMII be resolved in the future release of PSDKLA?

Best regards,

Eric Chen

Yes, it's a known limitation in PSDK 6.2 and is going to be fixed in future release (don't know yet what version will have the fix though).

Regarding the CPSW example test - in order to get the CPSW example loaded and running in Linux, you'd have to use the linker command file used by the EthFw application, located at <ethfw>/apps/app_remoteswitchcfg_server/mcu_2_0/linker*.cmd. The linker command file used to build the CPSW example is not compatible with Linux.

Another alternative is to enable the Quad Eth board in your EVM. For that you'd need the following steps:

1. Make sure SDK_6_2_CORE_SDK_IMAGE is undefined in CPSW LLD's cpsw_component.mk. This will enable SGMII/QSGMII related board initialization
2. Recompile CPSW driver library
3. Rebuild EthFw image
4. Disable PCIe in your devicetree configuration in Linux, disabling the top level pcie node.

Thank you for the reply.

I'll try to enable the Quad Eth board first.

Regarding the cpsw_component.mk, to undefined SDK_6_2_CORE_SDK_IMAGE, should I just leave that line comment?

#CPSW_CFLAGS += -DSDK_6_2_CORE_SDK_IMAGE

Best regards,

Eric Chen

Yes, leave that line commented out in cpsw_component.mk.

Hi Misa,

It's been a while.

I have tried the steps you suggested, but there is still no out put from the third COM Port.

Here is what I did: 

1. I make sure this line is commented out in the cpsw_component.mk.

#CPSW_CFLAGS += -DSDK_6_2_CORE_SDK_IMAGE

2. I replaced CpswAppBoardUtils_init() with CpswAppBoardUtils_initEthFw() in <pdk>/packages/ti/drv/cpsw/examples/cpsw_loopback_test/main_tirtos.c.

3. I recompiled CPSW driver.

cd <psdkra>/pdk/packages/ti/build/
make -s all BOARD=j721e_evm CORE=mcu2_0

4. I rebuilt EthFw image.

cd <psdkra>/ethfw/
make ethfw_all

5. I disabled every PCIe node in <psdkla>/board-support/linux-4.19.94+gitAUTOINC+5a23bc00e0-g5a23bc00e0/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts and rebuilt dtb.

cd <psdkla>/
make linux-dtbs

I am not sure if I did something wrong.

Best regards,

Eric Chen

Eric,

Are you saying that no even below messages are coming in the COM port?

Enabling clocks for CPSW_9G!
=======================================================
           CPSW Ethernet Firmware Demo
=======================================================

Was Linux able to boot without problems?

As suggested in a previous reply, we wanted to try first enabling QSGMII from QUAD_ETH board using EthFw, hence step #2 is not needed as we won't be testing the loopback example app.

What binary is /lib/firmware/j7-main-r5f0_0-fw soft-link pointing to? Just want to make sure that it's pointing to the app_remoteswitchcfg_server.xer5f that you recently compiled and not to loopback example binary.

Regards,

-Misa

Hi Misa,

Sorry, I thought enabling QUAD_ETH board means loopback test is good to go, so I pointed the link /lib/firmware/j7-main-r5f0_0-fw to /lib/firmware/cpsw_loopback_testapp_mcu2_0_release.xer5f.

Now I pointed the link to /lib/firmware/app_remoteswitchcfg_server.xer5f and below is the output from the third COM port.

Enabling clocks for CPSW_9G!
=======================================================
           CPSW Ethernet Firmware Demo
=======================================================
ETHFW Version: 0. 1. 1
ETHFW Build Date (YYYY/MMM/DD):2020/Apr/23
ETHFW Commit SHA:ETHFW PermissionFlag:0x1ffffff, UART Connected:true,UART Id:2IPC_echo_test (core : mcu2_0) .....
CPSW_9G Test on MAIN NAVSS
Remote demo device (core : mcu2_0) .....
PHY 16 is alive
PHY 17 is alive
PHY 18 is alive
PHY 19 is alive
Host MAC address: 70:ff:76:1d:91:cd
[NIMU_NDK] CPSW has been started successfully
REMOTE_SERVICE: Init ... !!!
REMOTE_SERVICE: Init ... Done !!!
Function:CpswProxyServer_attachExtHandlerCb,HostId:0,CpswType:1
Function:CpswProxyServer_registerMacHandlerCb,HostId:0,Handle:a2cee4f4,CoreKey:38acb7e6, MacAddress:70:ff:76:1d:91:cc, FlowIdx:172, FlowIdxOffset:0
Cpsw_ioctlInternal: CPSW: Registered MAC address.ALE entry:10, Policer Entry:0

Does this mean I can try to assign IP address to it and test SGMII between SoC and PC using iperf?

Best regards,

Eric Chen

Yes, please also make sure that the QSGMII ports are enabled in gCpswMainAppMacPorts array (apps/app_remoteswitchcfg_server/mcu_2_0/main_tirtos.c).

You may require to remove the RGMII MAC ports from the gCpswMainAppMacPorts array.

static const Cpsw_MacPort gCpswMainAppMacPorts[] =
{
    CPSW_MAC_PORT_1, /* QSGMII main */
    CPSW_MAC_PORT_4, /* QSGMII sub */
    CPSW_MAC_PORT_5, /* QSGMII sub */
    CPSW_MAC_PORT_6, /* QSGMII sub */
};

Connect QSGMII port 0 to a device running DHCP server (i.e. router or Linux PC running dhcp server). In the terminal you should see a message like this:

CPSW NIMU application, IP address I/F 1: 192.168.1.203

Then try enabling the virtual MAC interface in Linux using following or equivalent instructions:

modprobe rpmsg_kdrv_switch
ifconfig eth1 192.168.1.205 netmask 255.255.255.0 up

Hi Misa,

I commented out the RGMII MAC port in gCpswMainAppMacPorts array and rebuilt the EthFw.

static const Cpsw_MacPort gCpswMainAppMacPorts[] =
{
//    CPSW_MAC_PORT_0,
//#if defined(SOC_J721E)
    /* On J721E EVM to use all 8 ports simultaneously, we use below configuration
       RGMII Ports - 1,3,4,8. QSGMII ports - 2,5,6,7 */
//    CPSW_MAC_PORT_2, /* RGMII */
//    CPSW_MAC_PORT_3, /* RGMII */
//    CPSW_MAC_PORT_7, /* RGMII */
//#if defined(ENABLE_QSGMII_PORTS) //kept it disabled for 6.2
    CPSW_MAC_PORT_1, /* QSGMII main */
    CPSW_MAC_PORT_4, /* QSGMII sub */
    CPSW_MAC_PORT_5, /* QSGMII sub */
    CPSW_MAC_PORT_6, /* QSGMII sub */
//#endif
//#endif
};

Then, I connected the port to a router that has DHCP server enabled, but the EthFw got stuck here: 

Enabling clocks for CPSW_9G!
=======================================================
           CPSW Ethernet Firmware Demo
=======================================================
ETHFW Version: 0. 1. 1
ETHFW Build Date (YYYY/MMM/DD):2020/Apr/28
ETHFW Commit SHA:ETHFW PermissionFlag:0x1ffffff, UART Connected:true,UART Id:2IPC_echo_test (core : mcu2_0) .....
CPSW_9G Test on MAIN NAVSS
Remote demo device (core : mcu2_0) .....
CpswPhy_bindDriver: PHY 16: OUI:0001c1 Model:27 Ver:00 <-> 'vsc8514' : OK
CpswPhy_bindDriver: PHY 17: OUI:0001c1 Model:27 Ver:00 <-> 'vsc8514' : OK
CpswPhy_bindDriver: PHY 18: OUI:0001c1 Model:27 Ver:00 <-> 'vsc8514' : OK
CpswPhy_bindDriver: PHY 19: OUI:0001c1 Model:27 Ver:00 <-> 'vsc8514' : OK
PHY 16 is alive
PHY 17 is alive
PHY 18 is alive
PHY 19 is alive
Host MAC address: 70:ff:76:1d:91:cd
[NIMU_NDK] CPSW has been started successfully

not even showing the DHCP client timeout message.

Is there anything wrong?

Best regards,

Eric Chen

Hi Misa,

After commenting out the RGMII MAC port, I found that the eth1 interface does not exist in linux anymore.

The top left port is connected to a router with DHCP server running, and the LED is orange and yellow.

The bottom left port is connected to my PC, and the LED is green and yellow.

Is there anything else need to be changed?

Best regards,

Eric Chen

Eric,

Do you see similar logs in EthFw serial port?

[NIMU_NDK] CPSW has been started successfully
Cpsw_handleLinkUp: port 2: Link up: 1-Gbps Full-Duplex
REMOTE_SERVICE: Init ... !!!
REMOTE_SERVICE: Init ... Done !!!

Port number will be different in your case, but you should see a log message indicating that the link is up for whichever ports you have connected to PC or router.

Hi Misa,

The logs in EthFw serial port just stuck at this line: 

[NIMU_NDK] CPSW has been started successfully

Here are some of my situation: 

  1. I can enter linux, but the eth1 interface is missing.

  2. ifconfig eth1 up shows: no such device

  3. I cannot ping to my PC, and modprobe rpmsg_kdrv_switch does not work either.

  4. My DHCP server did not receive any request from 70:FF:76:1D:91:CC.

Best regards,

Eric Chen

Eric,

The QSGMII PHY is not getting link up.

Please enable debug trace logs in the CPSW LLD, let's take a closer look at what's happening with the PHY state machine that is preventing the PHYs from reaching LINKED state. In pdk/packages/ti/drv/cpsw/cpsw_component.mk, please set the following:

CPSW_CFLAGS += -DCPSW_TRACE_CFG_TRACE_LEVEL=4

It's currently set to that level for debug build, but it's set to level 3 (INFO level) for release build profile.

-Misa

Hi Misa,

CPSW_CFLAGS += -DCPSW_TRACE_CFG_TRACE_LEVEL=4

I set this line in pdk/packages/ti/drv/cpsw/cpsw_component.mk and recompiled cpsw driver and EthFw, but the output seems to be the same.

Enabling clocks for CPSW_9G!
=======================================================
           CPSW Ethernet Firmware Demo
=======================================================
ETHFW Version: 0. 1. 1
ETHFW Build Date (YYYY/MMM/DD):2020/May/ 4
ETHFW Commit SHA:ETHFW PermissionFlag:0x1ffffff, UART Connected:true,UART Id:2IPC_echo_test (core : mcu2_0) .....
CPSW_9G Test on MAIN NAVSS
Remote demo device (core : mcu2_0) .....
CpswPhy_bindDriver: PHY 16: OUI:0001c1 Model:27 Ver:00 <-> 'vsc8514' : OK
CpswPhy_bindDriver: PHY 17: OUI:0001c1 Model:27 Ver:00 <-> 'vsc8514' : OK
CpswPhy_bindDriver: PHY 18: OUI:0001c1 Model:27 Ver:00 <-> 'vsc8514' : OK
CpswPhy_bindDriver: PHY 19: OUI:0001c1 Model:27 Ver:00 <-> 'vsc8514' : OK
PHY 16 is alive
PHY 17 is alive
PHY 18 is alive
PHY 19 is alive
Host MAC address: 70:ff:76:1d:91:cd
[NIMU_NDK] CPSW has been started successfully

Best regards,

Eric Chen

Eric,

I was expecting to see more debug prints. Could you please check if CpswTrace_runtimeLevel is set to CPSW_TRACE_DEBUG? If not, please set it in

pdk/packages/ti/drv/cpsw/src/cpsw_trace.c.

-Misa

Hi Misa,

Thank you for the notification.

I changed the CpswTrace_runtimeLevel from CPSW_TRACE_INFO to CPSW_TRACE_DEBUG, and here is the output now.

Enabling clocks for CPSW_9G!
=======================================================
           CPSW Ethernet Firmware Demo             
=======================================================
ETHFW Version: 0. 1. 1
ETHFW Build Date (YYYY/MMM/DD):2020/May/ 5
ETHFW Commit SHA:ETHFW PermissionFlag:0x1ffffff, UART Connected:true,UART Id:2IPC_echo_test (core : mcu2_0) .....
CPSW_9G Test on MAIN NAVSS
Remote demo device (core : mcu2_0) .....
CpswPhy_setNextState: PHY 16: INIT -> FINDING (20 ticks)
CpswPhy_setNextState: PHY 16: FINDING -> FOUND (0 ticks)
CpswPhy_bindDriver: PHY 16: OUI:0001c1 Model:27 Ver:00 <-> 'vsc8514' : OK
CpswPhy_open: PHY 16: open
CpswPhy_setNextState: PHY 17: INIT -> FINDING (20 ticks)
CpswPhy_setNextState: PHY 17: FINDING -> FOUND (0 ticks)
CpswPhy_bindDriver: PHY 17: OUI:0001c1 Model:27 Ver:00 <-> 'vsc8514' : OK
CpswPhy_open: PHY 17: open
CpswPhy_setNextState: PHY 18: INIT -> FINDING (20 ticks)
CpswPhy_setNextState: PHY 18: FINDING -> FOUND (0 ticks)
CpswPhy_bindDriver: PHY 18: OUI:0001c1 Model:27 Ver:00 <-> 'vsc8514' : OK
CpswPhy_open: PHY 18: open
CpswPhy_setNextState: PHY 19: INIT -> FINDING (20 ticks)
CpswPhy_setNextState: PHY 19: FINDING -> FOUND (0 ticks)
CpswPhy_bindDriver: PHY 19: OUI:0001c1 Model:27 Ver:00 <-> 'vsc8514' : OK
CpswPhy_open: PHY 19: open
PHY 16 is alive
PHY 17 is alive
PHY 18 is alive
PHY 19 is alive
Host MAC address: 70:ff:76:1d:91:cd
[NIMU_NDK] CPSW has been started successfully
GenericPhy_reset: PHY 16: reset
CpswPhy_setNextState: PHY 16: FOUND -> RESET_WAIT (10 ticks)
GenericPhy_reset: PHY 17: reset
CpswPhy_setNextState: PHY 17: FOUND -> RESET_WAIT (10 ticks)
GenericPhy_reset: PHY 18: reset
CpswPhy_setNextState: PHY 18: FOUND -> RESET_WAIT (10 ticks)
GenericPhy_reset: PHY 19: reset
CpswPhy_setNextState: PHY 19: FOUND -> RESET_WAIT (10 ticks)
GenericPhy_isResetComplete: PHY 16: reset is complete
CpswPhy_setNextState: PHY 16: RESET_WAIT -> ENABLE (0 ticks)
GenericPhy_isResetComplete: PHY 17: reset is complete
CpswPhy_setNextState: PHY 17: RESET_WAIT -> ENABLE (0 ticks)
GenericPhy_isResetComplete: PHY 18: reset is complete
CpswPhy_setNextState: PHY 18: RESET_WAIT -> ENABLE (0 ticks)
GenericPhy_isResetComplete: PHY 19: reset is complete
CpswPhy_setNextState: PHY 19: RESET_WAIT -> ENABLE (0 ticks)
CpswPhy_enableState: PHY 16: enable
GenericPhy_reset: PHY 16: reset
GenericPhy_isResetComplete: PHY 16: reset is complete
CpswPhy_enableState: PHY 16: req caps: FD1000 HD1000 FD100 HD100 FD10 HD10 
CpswPhy_enableState: PHY 16: PHY caps: FD1000 HD1000 FD100 HD100 FD10 HD10 
CpswPhy_enableState: PHY 16: MAC 1 caps: FD1000 FD100 HD100 FD10 HD10 
CpswPhy_enableState: PHY 16: refined caps: FD1000 FD100 HD100 FD10 HD10 
CpswPhy_enableState: PHY 16: PHY is NWAY-capable
CpswPhy_enableState: PHY 16: setup NWAY
CpswPhy_setupNway: PHY 16: NWAY advertising: FD1000 FD100 HD100 FD10 HD10 
CpswPhy_setupNway: PHY 16: config is needed
CpswPhy_setupNway: PHY 16: restart autonegotiation
CpswPhy_setNextState: PHY 16: ENABLE -> NWAY_START (50 ticks)
CpswPhy_enableState: PHY 17: enable
GenericPhy_reset: PHY 17: reset
GenericPhy_isResetComplete: PHY 17: reset is complete
CpswPhy_enableState: PHY 17: req caps: FD1000 HD1000 FD100 HD100 FD10 HD10 
CpswPhy_enableState: PHY 17: PHY caps: FD1000 HD1000 FD100 HD100 FD10 HD10 
CpswPhy_enableState: PHY 17: MAC 4 caps: FD1000 FD100 HD100 FD10 HD10 
CpswPhy_enableState: PHY 17: refined caps: FD1000 FD100 HD100 FD10 HD10 
CpswPhy_enableState: PHY 17: PHY is NWAY-capable
CpswPhy_enableState: PHY 17: setup NWAY
CpswPhy_setupNway: PHY 17: NWAY advertising: FD1000 FD100 HD100 FD10 HD10 
CpswPhy_setupNway: PHY 17: config is needed
CpswPhy_setupNway: PHY 17: restart autonegotiation
CpswPhy_setNextState: PHY 17: ENABLE -> NWAY_START (50 ticks)
CpswPhy_enableState: PHY 18: enable
GenericPhy_reset: PHY 18: reset
GenericPhy_isResetComplete: PHY 18: reset is complete
CpswPhy_enableState: PHY 18: req caps: FD1000 HD1000 FD100 HD100 FD10 HD10 
CpswPhy_enableState: PHY 18: PHY caps: FD1000 HD1000 FD100 HD100 FD10 HD10 
CpswPhy_enableState: PHY 18: MAC 5 caps: FD1000 FD100 HD100 FD10 HD10 
CpswPhy_enableState: PHY 18: refined caps: FD1000 FD100 HD100 FD10 HD10 
CpswPhy_enableState: PHY 18: PHY is NWAY-capable
CpswPhy_enableState: PHY 18: setup NWAY
CpswPhy_setupNway: PHY 18: NWAY advertising: FD1000 FD100 HD100 FD10 HD10 
CpswPhy_setupNway: PHY 18: config is needed
CpswPhy_setupNway: PHY 18: restart autonegotiation
CpswPhy_setNextState: PHY 18: ENABLE -> NWAY_START (50 ticks)
CpswPhy_enableState: PHY 19: enable
GenericPhy_reset: PHY 19: reset
GenericPhy_isResetComplete: PHY 19: reset is complete
CpswPhy_enableState: PHY 19: req caps: FD1000 HD1000 FD100 HD100 FD10 HD10 
CpswPhy_enableState: PHY 19: PHY caps: FD1000 HD1000 FD100 HD100 FD10 HD10 
CpswPhy_enableState: PHY 19: MAC 6 caps: FD1000 FD100 HD100 FD10 HD10 
CpswPhy_enableState: PHY 19: refined caps: FD1000 FD100 HD100 FD10 HD10 
CpswPhy_enableState: PHY 19: PHY is NWAY-capable
CpswPhy_enableState: PHY 19: setup NWAY
CpswPhy_setupNway: PHY 19: NWAY advertising: FD1000 FD100 HD100 FD10 HD10 
CpswPhy_setupNway: PHY 19: config is needed
CpswPhy_setupNway: PHY 19: restart autonegotiation
CpswPhy_setNextState: PHY 19: ENABLE -> NWAY_START (50 ticks)
CpswPhy_setNextState: PHY 16: NWAY_START -> NWAY_WAIT (80 ticks)
CpswPhy_setNextState: PHY 17: NWAY_START -> NWAY_WAIT (80 ticks)
CpswPhy_setNextState: PHY 18: NWAY_START -> NWAY_WAIT (80 ticks)
CpswPhy_setNextState: PHY 19: NWAY_START -> NWAY_WAIT (80 ticks)
CpswPhy_findCommonCaps: PHY 16: local caps: FD100 HD100 FD10 HD10 
CpswPhy_findCommonCaps: PHY 16: partner caps: FD100 HD100 FD10 HD10 
CpswPhy_findCommonCaps: PHY 16: common caps: FD100 HD100 FD10 HD10 
CpswPhy_findCommon1000Caps: PHY 16: local caps: FD1000 
CpswPhy_findCommon1000Caps: PHY 16: partner caps: None
CpswPhy_findCommon1000Caps: PHY 16: common caps: None
CpswPhy_findCommonNwayCaps: PHY 16: common caps: FD100 HD100 FD10 HD10 
CpswPhy_nwayWaitState: PHY 16: negotiated mode: 100 Mbps full-duplex
CpswPhy_setNextState: PHY 16: NWAY_WAIT -> LINKED (0 ticks)

Best regards,

Eric Chen

Eric,

OK - you're getting link up, that's good news. You should see the following messages after link up:

CpswMacPort_checkSgmiiStatus: MAC 1: SGMII Link Parter Config port: Link Up: 1-Gbps Full-Duplex
Cpsw_handleLinkUp: port 1: Link up: 1-Gbps Full-Duplex
MAC Port 1: link up

I'm not sure why you don't see those. It seems it may be getting stuck somewhere in Cpsw_handleLinkUp(). The driver doesn't have debug prints in that function but it does have error messages, none of which you observe. Could you please add few debug traces in Cpsw_handleLinkUp()?

Hi Misa,

Thank you for the tip.

After looking into Cpsw_handleLinkUp() and printing some trace message, I found that the process stuck in the first while loop in CpswMacPort_checkSgmiiAutoNegStatus() to wait for SGMII Autonegotiation to complete without error.

After looping for a while, there is a REMOTE_SERVICE: Init ... Done !!! and a DHCP client timeout message too.

Here is part of the message I print out: 

...
CpswPhy_findCommon1000Caps: PHY 16: local caps: FD1000 
CpswPhy_findCommon1000Caps: PHY 16: partner caps: None
CpswPhy_findCommon1000Caps: PHY 16: common caps: None
CpswPhy_findCommonNwayCaps: PHY 16: common caps: FD100 HD100 FD10 HD10 
CpswPhy_nwayWaitState: PHY 16: negotiated mode: 100 Mbps full-duplex
CpswPhy_setNextState: PHY 16: NWAY_WAIT -> LINKED (0 ticks)
Cpsw_handleLinkUp: Checking port status
Cpsw_isPortLinkUp: Cpsw_isPortLinkUp
Cpsw_isPortLinkUp: Checking SGMII link status
CpswMacPort_ioctl: CPSW_MACPORT_IOCTL_GET_SGMII_AN_LINK_STATUS
CpswMacPort_ioctl: Checking SGMII AN Status
CpswMacPort_checkSgmiiAutoNegStatus: Wait for SGMII AN to complete
CpswMacPort_checkSgmiiAutoNegStatus: Wait for SGMII AN to complete
...
CpswMacPort_checkSgmiiAutoNegStatus: Wait for SGMII AN to complete
REMOTE_SERVICE: Init ... !!!
CpswMacPort_checkSgmiiAutoNegStatus: Wait for SGMII AN to complete
Function:CpswProxyServer_attachExtHandlerCb,HostId:0,CpswType:1
REMOTE_SERVICE: Init ... Done !!!
CpswMacPort_checkSgmiiAutoNegStatus: Wait for SGMII AN to complete
CpswMacPort_checkSgmiiAutoNegStatus: Wait for SGMII AN to complete
...
CpswMacPort_checkSgmiiAutoNegStatus: Wait for SGMII AN to complete
DHCP client timed out. Retrying..... 
CpswMacPort_checkSgmiiAutoNegStatus: Wait for SGMII AN to complete
CpswMacPort_checkSgmiiAutoNegStatus: Wait for SGMII AN to complete
...

Best regards,

Eric Chen

Eric,

Could you try below change and see if it helps SGMII auto-negotiation to complete?

diff --git a/src/cpsw_macport.c b/src/cpsw_macport.c
--- a/src/cpsw_macport.c
+++ b/src/cpsw_macport.c
@@ -1740,9 +1740,10 @@ static int32_t CpswMacPort_enablePort(CpswMacPort_Handle hPort,
                         if (cfg->speed == CPSW_SPEED_1GBIT)
                         {
                             CSL_FINS(macControl, XGE_CPSW_PN_MAC_CONTROL_REG_GIG, 1U);
-                            CSL_FINS(macControl, XGE_CPSW_PN_MAC_CONTROL_REG_GMII_EN, 1U);
                         }

+                        CSL_FINS(macControl, XGE_CPSW_PN_MAC_CONTROL_REG_GMII_EN, 1U);
+
                         if (1U == CSL_SGMII_isAutoNegotiationEnabled(hPort->sgmiiRegs, hPort->portNum))
                         {
                             status = CpswMacPort_checkSgmiiAutoNegStatus(hPort);

Misa,

The output seems to be the same and I print the sgmiiStatus too.

...
CpswMacPort_checkSgmiiAutoNegStatus: sgmiiStatus.bIsLinkUp:          0
CpswMacPort_checkSgmiiAutoNegStatus: sgmiiStatus.bIsAutoNegError:    0
CpswMacPort_checkSgmiiAutoNegStatus: sgmiiStatus.bIsAutoNegComplete: 0
CpswMacPort_checkSgmiiAutoNegStatus: sgmiiStatus.bIsLocked:          1
CpswMacPort_checkSgmiiAutoNegStatus: Wait for SGMII AN to complete
...

Could it be the problem of device tree? I am not sure if I disabled any node that supposed to be enabled.

Or if we are already here, then we are good about device tree?

Best regards,

Eric Chen

Could you share the *.diff file with changes you made in device tree?

Here are the k3-j721e-common-proc-board.dts.diff and k3-j721e-main.dtsi.diff.

--- k3-j721e-common-proc-board.dts.bak	2020-05-07 10:28:44.660349198 +0800
+++ k3-j721e-common-proc-board.dts	2020-05-07 10:43:39.503581642 +0800
@@ -674,6 +674,7 @@
 		      <SERDES2_LANE0_PCIE2_LANE0>, <SERDES2_LANE1_PCIE2_LANE1>,
 		      <SERDES3_LANE0_USB3_0_SWAP>, <SERDES3_LANE1_USB3_0>,
 		      <SERDES4_LANE0_EDP_LANE0>, <SERDES4_LANE1_EDP_LANE1>, <SERDES4_LANE2_EDP_LANE2>, <SERDES4_LANE3_EDP_LANE3>;
+	status = "disabled";
 };
 
 &serdes_wiz3 {
@@ -741,6 +742,7 @@
 &serdes_wiz0 {
 	lane0-mode = <PHY_TYPE_PCIE>;
 	lane1-mode = <PHY_TYPE_PCIE>;
+	status = "disabled";
 };
 
 &serdes0 {
@@ -750,12 +752,14 @@
 		#phy-cells = <0>;
 		cdns,phy-type = <PHY_TYPE_PCIE>;
 		resets = <&serdes_wiz0 1>;
+		status = "disabled";
 	};
 };
 
 &serdes_wiz1 {
 	lane0-mode = <PHY_TYPE_PCIE>;
 	lane1-mode = <PHY_TYPE_PCIE>;
+	status = "disabled";
 };
 
 &serdes1 {
@@ -765,12 +769,14 @@
 		#phy-cells = <0>;
 		cdns,phy-type = <PHY_TYPE_PCIE>;
 		resets = <&serdes_wiz1 1>, <&serdes_wiz1 2>;
+		status = "disabled";
 	};
 };
 
 &serdes_wiz2 {
 	lane0-mode = <PHY_TYPE_PCIE>;
 	lane1-mode = <PHY_TYPE_PCIE>;
+	status = "disabled";
 };
 
 &serdes2 {
@@ -780,40 +786,47 @@
 		#phy-cells = <0>;
 		cdns,phy-type = <PHY_TYPE_PCIE>;
 		resets = <&serdes_wiz2 1>, <&serdes_wiz2 2>;
+		status = "disabled";
 	};
 };
 
 &pcie0 {
 	pci-mode = <PCI_MODE_RC>;
 	num-lanes = <1>;
+	status = "disabled";
 };
 
 &pcie1 {
 	pci-mode = <PCI_MODE_RC>;
 	num-lanes = <2>;
+	status = "disabled";
 };
 
 &pcie2 {
 	pci-mode = <PCI_MODE_RC>;
 	num-lanes = <2>;
+	status = "disabled";
 };
 
 &pcie0_rc {
 	reset-gpios = <&exp1 6 GPIO_ACTIVE_HIGH>;
 	phys = <&serdes0_pcie_link>;
 	phy-names = "pcie_phy";
+	status = "disabled";
 };
 
 &pcie1_rc {
 	reset-gpios = <&exp1 2 GPIO_ACTIVE_HIGH>;
 	phys = <&serdes1_pcie_link>;
 	phy-names = "pcie_phy";
+	status = "disabled";
 };
 
 &pcie2_rc {
 	reset-gpios = <&exp2 20 GPIO_ACTIVE_HIGH>;
 	phys = <&serdes2_pcie_link>;
 	phy-names = "pcie_phy";
+	status = "disabled";
 };
 
 &tscadc0 {
@@ -836,14 +849,17 @@
 &pcie0_ep {
 	phys = <&serdes0_pcie_link>;
 	phy-names = "pcie_phy";
+	status = "disabled";
 };
 
 &pcie1_ep {
 	phys = <&serdes1_pcie_link>;
 	phy-names = "pcie_phy";
+	status = "disabled";
 };
 
 &pcie2_ep {
 	phys = <&serdes2_pcie_link>;
 	phy-names = "pcie_phy";
+	status = "disabled";
 };

--- k3-j721e-main.dtsi.bak	2020-05-07 10:45:46.491048538 +0800
+++ k3-j721e-main.dtsi	2020-05-07 10:49:10.472996378 +0800
@@ -31,16 +31,19 @@
 		pcie0_ctrl: pcie-ctrl@4070 {
 			compatible = "syscon";
 			reg = <0x00004070 0x4>;
+			status = "disabled";
 		};
 
 		pcie1_ctrl: pcie-ctrl@4074 {
 			compatible = "syscon";
 			reg = <0x00004074 0x4>;
+			status = "disabled";
 		};
 
 		pcie2_ctrl: pcie-ctrl@4078 {
 			compatible = "syscon";
 			reg = <0x00004078 0x4>;
+			status = "disabled";
 		};
 
 		serdes_ln_ctrl: serdes_ln_ctrl@4080 {
@@ -986,6 +989,7 @@
 		power-domains = <&k3_pds 239 TI_SCI_PD_EXCLUSIVE>;
 		clocks = <&k3_clks 239 1>;
 		clock-names = "fck";
+		status = "disabled";
 
 		pcie0_rc: pcie@d000000 {
 			compatible = "ti,j721e-cdns-pcie-host";
@@ -1004,6 +1008,7 @@
 			dma-coherent;
 			ranges = <0x01000000 0x0 0x10001000  0x00 0x10001000  0x0 0x0010000>,
 				 <0x02000000 0x0 0x00000000  0x40 0x00000000  0x0 0x80000000>;
+			status = "disabled";
 		};
 
 		pcie0_ep: pcie-ep@d000000 {
@@ -1015,6 +1020,7 @@
 			max-functions = /bits/ 8 <6>;
 			max-virtual-functions = /bits/ 8 <0x4 0x4 0x4 0x4 0x0 0x0>;
 			dma-coherent;
+			status = "disabled";
 		};
 	};
 
@@ -1033,6 +1039,7 @@
 		power-domains = <&k3_pds 240 TI_SCI_PD_EXCLUSIVE>;
 		clocks = <&k3_clks 240 1>;
 		clock-names = "fck";
+		status = "disabled";
 
 		pcie1_rc: pcie@d800000 {
 			compatible = "ti,j721e-cdns-pcie-host";
@@ -1051,6 +1058,7 @@
 			dma-coherent;
 			ranges = <0x01000000 0x0 0x18001000  0x00 0x18001000  0x0 0x0010000>,
 				 <0x02000000 0x0 0x00000000  0x41 0x00000000  0x0 0x80000000>;
+			status = "disabled";
 		};
 
 		pcie1_ep: pcie-ep@d800000 {
@@ -1062,6 +1070,7 @@
 			max-functions = /bits/ 8 <6>;
 			max-virtual-functions = /bits/ 8 <0x4 0x4 0x4 0x4 0x0 0x0>;
 			dma-coherent;
+			status = "disabled";
 		};
 	};
 
@@ -1080,6 +1089,7 @@
 		power-domains = <&k3_pds 241 TI_SCI_PD_EXCLUSIVE>;
 		clocks = <&k3_clks 241 1>;
 		clock-names = "fck";
+		status = "disabled";
 
 		pcie2_rc: pcie@e000000 {
 			compatible = "ti,j721e-cdns-pcie-host";
@@ -1098,6 +1108,7 @@
 			dma-coherent;
 			ranges = <0x01000000 0x00 0x00001000  0x44 0x00001000  0x0 0x0010000>,
 				 <0x02000000 0x00 0x00011000  0x44 0x00011000  0x0 0x7fef000>;
+			status = "disabled";
 		};
 
 		pcie2_ep: pcie-ep@e000000 {
@@ -1109,6 +1120,7 @@
 			max-functions = /bits/ 8 <6>;
 			max-virtual-functions = /bits/ 8 <0x4 0x4 0x4 0x4 0x0 0x0>;
 			dma-coherent;
+			status = "disabled";
 		};
 	};
 

Hi Misa,

I found a fresh thread https://e2e.ti.com/support/processors/f/791/t/900935, and follow the step which is similar to what you suggested.

Now, the SGMII on QUAD ENET board is working!!

Thank you so much for all the support!!

It makes me understand EthFw more, and I believe it will be very useful in the future.

Enabling clocks for CPSW_9G!
=======================================================
           CPSW Ethernet Firmware Demo
=======================================================
ETHFW Version: 0. 1. 1
ETHFW Build Date (YYYY/MMM/DD):2020/May/ 7
ETHFW Commit SHA:ETHFW PermissionFlag:0x1ffffff, UART Connected:true,UART Id:2IPC_echo_test (core : mcu2_0) .....
CPSW_9G Test on MAIN NAVSS
Remote demo device (core : mcu2_0) .....
CpswPhy_bindDriver: PHY 16: OUI:0001c1 Model:27 Ver:00 <-> 'vsc8514' : OK
CpswPhy_bindDriver: PHY 17: OUI:0001c1 Model:27 Ver:00 <-> 'vsc8514' : OK
CpswPhy_bindDriver: PHY 18: OUI:0001c1 Model:27 Ver:00 <-> 'vsc8514' : OK
CpswPhy_bindDriver: PHY 19: OUI:0001c1 Model:27 Ver:00 <-> 'vsc8514' : OK
PHY 16 is alive
PHY 17 is alive
PHY 18 is alive
PHY 19 is alive
Host MAC address: 70:ff:76:1d:91:cd
[NIMU_NDK] CPSW has been started successfully
CpswMacPort_ioctl: *outArgs = true
CpswMacPort_enablePort: SGMII Link Parter Config port 1: Link Up: 100-Mbps Full-Duplex
Cpsw_handleLinkUp: port 1: Link up: 100-Mbps Full-Duplex

CPSW NIMU application, IP address I/F 1: 192.168.1.100

Rx Flow for Software Inter-VLAN Routing is up
CpswMacPort_ioctl: *outArgs = true
CpswMacPort_enablePort: SGMII Link Parter Config port 4: Link Up: 1-Gbps Full-Duplex
Cpsw_handleLinkUp: port 4: Link up: 1-Gbps Full-Duplex
REMOTE_SERVICE: Init ... !!!
REMOTE_SERVICE: Init ... Done !!!
Function:CpswProxyServer_attachExtHandlerCb,HostId:0,CpswType:1
Function:CpswProxyServer_registerMacHandlerCb,HostId:0,Handle:a2cef8f4,CoreKey:38acb7e6, MacAddress:70:ff:76:1d:91:cc, FlowIdx:172, FlowIdxOffset:0
Cpsw_ioctlInternal: CPSW: Registered MAC address.ALE entry:12, Policer Entry:0Function:CpswProxyServer_registerIpv4MacHandlerCb,HostId:0,Handle:a2cef8f4,CoreKey:38acb7e6, MacAddress:70:ff:76:1d:91:cc IPv4Addr:192.168.1.101

================LLI Table entries===========

Number of Static ARP Entries: 1

SNo.      IP Address         MAC Address
------    -------------      ---------------
1         192.168.1.101      70:FF:76:1D:91:CC

However, it is kind of unstable.

Sometime I can ping to my PC, sometime I cannot.

Sometime the bitrate of iperf3 drop to around 600 or even 0 Mbits/sec.

root@j7-evm:~# iperf3 -s
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 192.168.1.102, port 50300
[  5] local 192.168.1.101 port 5201 connected to 192.168.1.102 port 50301
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec  73.8 MBytes   619 Mbits/sec
[  5]   1.00-2.00   sec   113 MBytes   947 Mbits/sec
[  5]   2.00-3.00   sec   112 MBytes   943 Mbits/sec
[  5]   3.00-4.00   sec   113 MBytes   949 Mbits/sec
[  5]   4.00-5.00   sec   113 MBytes   949 Mbits/sec
[  5]   5.00-6.00   sec   113 MBytes   949 Mbits/sec
[  5]   6.00-7.00   sec   113 MBytes   949 Mbits/sec
[  5]   7.00-8.00   sec   113 MBytes   948 Mbits/sec
[  5]   8.00-9.00   sec  78.5 MBytes   659 Mbits/sec
[  5]   9.00-10.00  sec   113 MBytes   949 Mbits/sec
[  5]  10.00-10.04  sec  4.61 MBytes   947 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.04  sec  1.04 GBytes   886 Mbits/sec                  receiver

root@j7-evm:~# iperf3 -s
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 192.168.1.102, port 61632
[  5] local 192.168.1.101 port 5201 connected to 192.168.1.102 port 61633
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec   108 MBytes   909 Mbits/sec
[  5]   1.00-2.00   sec   113 MBytes   949 Mbits/sec
[  5]   2.00-3.00   sec   113 MBytes   949 Mbits/sec
[  5]   3.00-4.00   sec   110 MBytes   921 Mbits/sec
[  5]   4.00-5.00   sec   112 MBytes   939 Mbits/sec
[  5]   5.00-6.00   sec   112 MBytes   938 Mbits/sec
[  5]   6.00-7.00   sec  24.7 MBytes   207 Mbits/sec
[  5]   7.00-8.00   sec  0.00 Bytes  0.00 bits/sec
[  5]   8.00-9.00   sec  0.00 Bytes  0.00 bits/sec
[  5]   9.00-10.00  sec  0.00 Bytes  0.00 bits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.04  sec   693 MBytes   579 Mbits/sec                  receiver

What could possibly caused this unstable throughput?

Is there something else that should be modified?

Best regards,

Eric Chen

Hi Prasad,

Yes, it's fine, and thank you for the reply.

Best regards,

Eric Chen