This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DRA829J: DRA829J: How "serdes_ln_ctrl" effect MCU2_0 boot of vision_apps demo in SDK Version:10.01?

Part Number: DRA829J


Hi,

    Based on the SDK version 10.01, I successfully ran the vision_apps demo.

    However, I have 3 questions:

    1. If I modify the "serdes_ln_ctrl" in k3-j721e-evm-ethfw.dtso, after run the command "source ./vision_apps_init.sh", MCU2_0 failed to start successfully. I found some logs missed compared to before modify.

 

Modify as below:

&serdes_ln_ctrl {
    idle-states = <J721E_SERDES0_LANE0_QSGMII_LANE1>, <J721E_SERDES0_LANE1_QSGMII_LANE2>,
             // <J721E_SERDES0_LANE0_PCIE0_LANE0>, <J721E_SERDES0_LANE1_QSGMII_LANE2>,
              <J721E_SERDES1_LANE0_USB3_1_SWAP>, <J721E_SERDES1_LANE1_USB3_1>,
              <J721E_SERDES2_LANE0_PCIE2_LANE0>, <J721E_SERDES2_LANE1_PCIE2_LANE1>,
              <J721E_SERDES3_LANE0_IP1_UNUSED>, <J721E_SERDES3_LANE1_USB3_0>,
              <J721E_SERDES4_LANE0_QSGMII_LANE5>, <J721E_SERDES4_LANE1_QSGMII_LANE6>,
              <J721E_SERDES4_LANE2_QSGMII_LANE7>, <J721E_SERDES4_LANE3_QSGMII_LANE8>;
}; 

Logs missing after modify:

[MCU2_0]    962.577611 s: DSS: Init ... Done !!!
[MCU2_0]    962.577685 s: VHWA: VPAC Init ... !!!
[MCU2_0]    962.577716 s: SCICLIENT: Sciclient_pmSetModuleState module=290 state=2
[MCU2_0]    962.577915 s: SCICLIENT: Sciclient_pmSetModuleState success
[MCU2_0]    962.577966 s: VHWA: LDC Init ... !!!
[MCU2_0]    962.581047 s: VHWA: LDC Init ... Done !!!
[MCU2_0]    962.581110 s: VHWA: MSC Init ... !!!
[MCU2_0]    962.591008 s: VHWA: MSC Init ... Done !!!
[MCU2_0]    962.591065 s: VHWA: NF Init ... !!!
[MCU2_0]    962.592619 s: VHWA: NF Init ... Done !!!
[MCU2_0]    962.592677 s: VHWA: VISS Init ... !!!
[MCU2_0]    962.602290 s: VHWA: VISS Init ... Done !!!
[MCU2_0]    962.602360 s: VHWA: VPAC Init ... Done !!!
[MCU2_0]    962.602406 s:  VX_ZONE_INFO: Globally Enabled VX_ZONE_ERROR
[MCU2_0]    962.602446 s:  VX_ZONE_INFO: Globally Enabled VX_ZONE_WARNING
[MCU2_0]    962.602479 s:  VX_ZONE_INFO: Globally Enabled VX_ZONE_INFO
[MCU2_0]    962.603761 s:  VX_ZONE_INFO: [ownAddTargetKernelInternal:162] registered kernel com.ti.capture.scalar_sink on target MCU2-0
........
[MCU2_0]    962.631949 s: IPC: Echo status: mpu1_0[x] mcu2_0[s] mcu2_1[.] C66X_1[P] C66X_2[.] C7X_1[.] 
[MCU2_0]    962.632050 s: IPC: Echo status: mpu1_0[x] mcu2_0[s] mcu2_1[.] C66X_1[P] C66X_2[P] C7X_1[.] 
[MCU2_0]    962.632124 s: IPC: Echo status: mpu1_0[x] mcu2_0[s] mcu2_1[.] C66X_1[P] C66X_2[P] C7X_1[P] 
[MCU2_0]    962.632196 s: IPC: Echo status: mpu1_0[x] mcu2_0[s] mcu2_1[P] C66X_1[P] C66X_2[P] C7X_1[P]

 

    2. If I modify some value in k3-j721e-rtos-memory-map.dtsi, remote cores also cannot boot successfully.

Modify as below:

vision_apps_main_r5fss0_core0_memory_region: vision-apps-r5f-memory@a2100000 {
        compatible = "shared-dma-pool";
        reg = <0x00 0xa2100000 0x00 0x00f00000>;   // from 0x01f00000 to 0x00f00000
        no-map;
    };
    vision_apps_main_r5fss0_core1_dma_memory_region: vision-apps-r5f-dma-memory@a3000000 {
        compatible = "shared-dma-pool";
        reg = <0x00 0xa3000000 0x00 0x00100000>; // from 0xa5000000 to 0xa4000000
        no-map;
    };

Logs as below:

root@j721e-evm:/opt/vision_apps# dmesg | grep rpmsg
[   10.115424] virtio_rpmsg_bus virtio0: rpmsg host is online
[   10.136403] virtio_rpmsg_bus virtio1: rpmsg host is online
[   10.139560] virtio_rpmsg_bus virtio0: creating channel ti.ipc4.ping-pong addr 0xd
[   10.153146] virtio_rpmsg_bus virtio0: creating channel rpmsg_chrdev addr 0xe
[   10.167563] virtio_rpmsg_bus virtio1: creating channel rpmsg_chrdev addr 0xd
[   10.254022] virtio_rpmsg_bus virtio2: rpmsg host is online
[   10.257672] virtio_rpmsg_bus virtio2: creating channel rpmsg_chrdev addr 0xd
[   10.482381] virtio_rpmsg_bus virtio3: rpmsg host is online
[   10.484429] virtio_rpmsg_bus virtio3: creating channel rpmsg_chrdev addr 0xd
[   10.592909] virtio_rpmsg_bus virtio4: rpmsg host is online
[   10.602358] virtio_rpmsg_bus virtio4: creating channel rpmsg_chrdev addr 0xd

 

    3. I know that ETHFW can be disabled in vision_apps, but I would like to ask if it is possible to completely remove the ETHFW-related configurations and code, other than just disabling it?

 

Looking forward to your reply, Thanks!

  • Hi,

    We have received your post and the investigation will take some time. Thank you for your patience.

  •   1. If I modify the "serdes_ln_ctrl" in k3-j721e-evm-ethfw.dtso, after run the command "source ./vision_apps_init.sh", MCU2_0 failed to start successfully. I found some logs missed compared to before modify.

    This overlay is related to ethfw so any changes in this file might conflict with the ethfw running in muc2_0. Can you disable ethfw in mcu2_0 and check everything is fine.
    Any specific reason for why this change is required ?

    2. If I modify some value in k3-j721e-rtos-memory-map.dtsi, remote cores also cannot boot successfully.

    You are changing the mcu2_0's firmware size and location in ddr, which has to changed in the mcu2_0's linker file as well in order to work with the modified memory location.
    And it has to be adjusted with other core's memory map,
    the default memory map for all the cores can be found in $(psdkra)/vision_apps/platform/j721e/rtos/app_mem_map.h 
    https://software-dl.ti.com/jacinto7/esd/processor-sdk-rtos-jacinto7/latest/exports/docs/psdk_rtos/docs/user_guide/developer_notes_memory_map.html

    3. I know that ETHFW can be disabled in vision_apps, but I would like to ask if it is possible to completely remove the ETHFW-related configurations and code, other than just disabling it?

    Disabling ETHFW is a macro based and no code or related libraries are used in the final firmware when this macros is disabled.
    when BUILD_ENABLE_ETHFW?=no, ethfw related codes will not get compiled. But linux changes has to be done manually as this macro doesn't affect any linux dtb/overlay changes.

  • Hi, Taylor,

        Thanks for your reply.

        I modified serdes_ln_ctrl because we used SERDES4 for ETH not DP. And I found that if I modify DP to ETH, I must delete DSS INIT in app_init function. So issue can be resolved.