TDA4VMXEVM: Is "QUAD-PORT ETHERNET EXPANSION BOARD" supported on Linux?

Hello Rado,

Please find my replies below - 

Radoslav Rodopski said:

1. Could you please let us know if it is supported or if there are any plans to support it?

QSGMII is supported in PSDKRA6.2 release in standalone mode but not with default PSDKLA configuration. QSGMII + EthFw is not supported due to SERDES sharing not supported in 6.2. 

QSGMII is only supported in standalone mode in 6.2. Refer to https://e2e.ti.com/support/processors/f/791/t/884595 for running standlone test for QSGMII.

Radoslav Rodopski said:

2. Is there any (easy) way we can modify the demo FW on the R5F to support a custom extension board with RGMI/SGMII PHYs?

Can you please refer to below developer notes which details about adding custom PHY/interface. 

psdk_rtos_auto_j7_06_01_01_06/psdk_rtos_auto/docs/user_guide/developer_notes_ethfw.html

Hi Prasad,

We aren't interested in QSGMII mode, we want to use RGMII or SGMII.

Thanks for the info regarding adding support for a new PHY - I already read that and I found even more detailed information in the linked documentation at [pdk/packages/ti/drv/cpsw/docs/doxygen/html/cpsw_phy_guide_top.html]

I see that both "virtio_rpmsg_bus" and "rpmsg_kdrv_switch" drivers are loaded, and the R5F firmware is loaded as well (I think that's where the EthFw resides, right?) but I only see the ethernet interface from the 2-port switch (eth0) when I run "ifconfig -a".

I don't have the GESI board, so I guess there might be some detection done by the EthFw in order for the virtual interface from CPSW9G (eth1) to appear in Linux. Could you please let me know what conditions need to be met in order for that interface to appear in Linux?  Does the EthFw need to detect some supported PHYs and report that via RPC/IPC mechanism to the Linux driver, or does the Linux driver just create the virtual interface?

Best regards,
Rado

Hello Rado,

You are right. The EthFw will check for GESI board detection and wait on links on the ports on GESI board. Now in your case as there is no GESI board, the EthFw will be stuck in wait for link mode forever. Due to this Linux virtual mac driver won't be able to communicate with the EthFw.

Any chance you can get GESI board for your tests?

Hi Prasad,

We're not interested in the GESI board at this time.

I'd like to know if we can somehow force the EthFw to detect our custom board. Maybe I need to define our custom board somewhere? Could you let me know what is the mechanism for detecting a board (i.e how the EthFw detects the GESI BOARD) ?

Also, I see that the EthFw uses UART2 for printing debug messages and for interacting with the user to run some tests. Can we change that to some other UART? What are the options there?

Best regards,
Rado

Hi Prasad,

Thank you, that was very helpful. I'll try to experiment with that and let you know if I have more questions about the UART configuration.

About the custom board - we want to connect another PHY to the 9-port switch and the extension connector seems like a quick way to go and experiment with. I want to be able to extend the EthFw with support for a custom addon board. If you have any pointers, please do let me know. I've already looked around the source and I saw that you read an I2C EEPROM to identify which addon board is connected. I'd just skip that step and modify the code to always treat our custom board as "connected".
I'd like then to have Linux detect it and provide the virtual ethernet interface and exchange some packets.

Best regards,
Rado

Hello Rado,

Thanks for details about custom board. We should be able to get this working with EthFw. 

EthFw calls function "CpswAppBoardUtils_initEthFw" to get board configured. Please refer to this function so you can understand the flow.

You need to plug your custom board in this function. It should be OK that you don't do board detect check and assume it is always connected.

Also remember you would need to change function "CpswAppUtils_setPhyConfig" to match PHY on your custom board.

Hi Prasad,

I tried the following modification to no avail:

In CpswAppBoardUtils_initEthFw:

//initParams.uartInst = CPSW_UTILS_MCU2_0_UART_INSTANCE;
//initParams.uartSocDomain = BOARD_SOC_DOMAIN_MAIN;
initParams.uartInst = 0;
initParams.uartSocDomain = BOARD_SOC_DOMAIN_WKUP;

(the commented out code is the original, replaced with the following two lines)

I suppose the above should replace MAIN_UART2 with WKUP_UART0, right? But I don't see any output on WKUP_UART0.
Could you please let me know if I missed anything?

Also, in Board_detectBoard, I added one additional line to make the EthFw believe the GESI board is always connected:

if(boardID <= BOARD_ID_SOM)
{
        if (boardID == BOARD_ID_GESI) return TRUE;  // This is the line I added right in the beginning of the if-statement.

I expected that the eth1 interface would now show up in Linux but "ifconfig -a" shows only eth0 as usual.

Any idea why that isn't working?

Is anything else necessary for the EthFw to expose the virtual interface under Linux?

Best regards,
Rado

Hello Rado,

 1. About UART

You need to use instance _MCU for using UART0.

initParams.uartInst = 0;
initParams.uartSocDomain = BOARD_SOC_DOMAIN_MCU;
Board_setInitParams(&initParams);
status = Board_init(BOARD_INIT_UART_STDIO);
if(status != BOARD_SOK)
{
return -1;
}

Also EthFw doesn't configure MCU pinmux by default. You need to add below in CpswAppBoardUtils_configEthFwPinmux function to enable UART pinmux.

Board_pinmuxUpdate(gMcu_uartPinCfg,
BOARD_SOC_DOMAIN_MCU);

2. Bypassing board detect is not only change, you need to do for adding support for your custom board. You need to

1. Program ENET CTRL MMR as per need

2. Configure SERDES if SGMII mode is used.

3 Add PHY driver for your PHY if not there already in existing supported PHYs

4. Update function CpswAppBoardUtils_setPhyConfig to add your required Port configuration 

    - PHY Address

    - Connection speed etc.

    - interface layer type

You need to first make sure you get an IP address on EthFw before checking the virtual driver on Linux.

Getting Ethfw up is must for getting virtual mac up.

Hello Rado,

Just to complete the thread. hope you run below to load virtual mac driver on Linux.

root@j7-evm:~# modprobe rpmsg_kdrv_switch
[ 21.892507] rpmsg-kdrv-eth-switch rpmsg-kdrv-2-mpu_1_0_ethswitch-device-0: Device info: permissions: 01FFFFFF uart_id: 2
[ 21.903381] rpmsg-kdrv-eth-switch rpmsg-kdrv-2-mpu_1_0_ethswitch-device-0: FW ver 0.1 (rev 1) 25/Mar/2020 SHA:ad12522e
root@j7-evm:~# [ 21.983519] j721e-cpsw-virt-mac main_r5fss_cpsw9g_virt_mac0: virt_cpsw_nuss mac loaded
[ 21.998604] j721e-cpsw-virt-mac main_r5fss_cpsw9g_virt_mac0: rdev_features:00000003 rdev_mtu:1522 flow_id:172 tx_psil_dst_id:4A00
[ 22.023393] j721e-cpsw-virt-mac main_r5fss_cpsw9g_virt_mac0: local_mac_addr:00:00:00:00:00:00 rdev_mac_addr:70:ff:76:1d:92:c1
[ 22.271501] j721e-cpsw-virt-mac main_r5fss_cpsw9g_virt_mac0: virt_cpsw_nuss mac started