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.

AM6442: AM6442: sbl_ospi_linux fast boot breaks R5F0_0 EtherCAT discovery when Linux/A53 boot code is enabled

Part Number: AM6442
Other Parts Discussed in Thread: SYSCONFIG

Dear TI Team,

We are encountering a critical issue where the real-time networking peripherals stop functioning whenever the A53/Linux boot flow is enabled within the SBL.

Scenario A – Standalone RTOS Boot (Working)

When we comment out the Linux image processing logic inside the SBL (App_loadLinuxImages() and App_runLinuxCpu()), both R5F0_0 and R5F1_0 boot successfully from OSPI flash.

In this configuration:

  • Ethernet PHYs achieve proper physical link-up.

  • The PLC is able to successfully discover the EtherCAT subdevice.

  • EtherCAT communication functions as expected.

Scenario B – Linux Boot Enabled (Failure)

When the Linux parsing/jump logic is enabled in the SBL, U-Boot and Linux boot completely successfully on the A53.

However:

  • EtherCAT discovery fails entirely from the PLC side.

  • R5F1_0 application still appears to boot and run.

  • Physical Ethernet link behavior is inconsistent/non-functional from the EtherCAT perspective.


Root Cause Investigation Already Performed

To isolate the issue, we have already verified and ruled out the following common conflict scenarios:

1. Linux/Kernel Hardware Resource Conflict (Ruled Out)

We booted Linux in an isolated configuration where the k3-r5-rproc driver is completely disabled.

Verification:

  • /sys/class/remoteproc/ is completely empty.

  • Live DT status checks confirm Linux does not own or access the relevant peripherals:

bus@f4000/i2c@20000000/status     -> disabled
bus@f4000/icssg@30080000/status   -> disabled

This confirms Linux is fully passive with respect to:

  • ICSSG1

  • I2C0

  • Related EtherCAT peripherals

Despite this, EtherCAT discovery still fails whenever the Linux boot flow is enabled in SBL.

2. UART Console/Register Conflict (Ruled Out)

To avoid UART0 register conflicts with the A53/Linux console:

  • UART logging has been completely disabled in SysConfig for both the R5F0_0 and R5F1_0 applications.

Could you please suggest what additional areas we should investigate or whether there are known dependencies when combining EtherCAT RTOS cores with A53/Linux boot through SBL?

We would appreciate any guidance or debugging recommendations.

Best regards,
Sonu Kumar

  • Hi Sonu,

    Could you please suggest what additional areas we should investigate or whether there are known dependencies when combining EtherCAT RTOS cores with A53/Linux boot through SBL?

    It looks like resource allocation issue for ICSSG channel, as it is accessible via RTOS SBL but not when booting via Linux SBL. 

    Please let us know which version of SDK are you using?

    Regards,

    Tushar

  • Hi Tushar,

    We are using ICSSG1 for R5F0_0, and ICSSG1 is disabled from the Linux side.

    I would also like to share the sdk versions currently being used:

    • SBL OSPI Linux and SBL UART: MCU+ SDK 11.02.00.24

    • R5F0_0: Industrial Communications SDK ind_comms_sdk_am64x_2025_00_00_08

    • Linux appimage and U-Boot: Processor SDK 11.01.05.03

    Could you please confirm whether this combination of SDK versions is compatible to avoid possible resource allocation or initialization conflicts?

    Any guidance on this would be greatly appreciated.

    Thank you.

  • Hi Sonu,

    I can see the version of MCU+SDK you are using is not tested with the Indus comms or processor SDK used. As the MCU+SDK 11.02 was released in Dec 2025 while Indus Comm SDK was released in Nov 2025.

    The version of MCU+SDK v11.01 is tested with above specified version of Indus comm SDK.

    Regards,

    Tushar