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.

PROCESSOR-SDK-AM64X: AM64x MCU use cases and CPSW based Ethernet

Part Number: PROCESSOR-SDK-AM64X
Other Parts Discussed in Thread: AM6442

Tool/software:

Hi,

I am new to the AM64x software development and had the following basic questions:

1. I know AM64x includes different processor cores: A53 cores are suitable for computation and typically run in Linux; R5F cores are for control and run in RTOS or no RTOS. However, it is a bit unclear to envision the potential applications I can utilize all these processor cores. Take AM64x EVM (AM6442) as the example, can I get some examples of what applications can be implemented in A53, then passing data from A53 to R5F cores, then maybe passing the results back to A53?

2. AM64x EVM has 4 R5F cores, what are the default MCU applications run on these cores?

3. Does one of the R5F cores implement CPSW based ethernet firmware? For example, if I ran TSN PTP application in Linux, are the TSN PTP, frame preemption, EST features done in one of the R5F cores?

Thank you!

  • Hi Matt,

    1. As you said, you can have control applications running on R5F cores, like TSN, motor control, etc which need fast response times. You can also use these to run nodes on a loop which controls various points in a robotic system, or industrial work floor. You can use A53 core where you run process and resource intensive tasks, analytics, graphics, etc, which have support from linux. You can use IPC to exchange data between the  R5F cores, and A53 cores. 
    2. The MCU+ SDK documentation: Examples has details on all the available examples, and most of the examples apart from SBL examples are supported on MCU R5FSS_0-0 core. The support for the rest of the cores from driver perspective is available, and can be enabled with simple resource reallocation, if required.
    3. Ethernet Firmware as in a device driver for controlling a peripheral doesn't run on R5F core when Linux is owning the CPSW peripheral. Based on which TSN stack you are using on Linux, all of the TSN PTP frame handling would be done by Linux. But Pre-emption and EST are supported by CPSW hardware, and can be configured to be offloaded to hardware. Any given peripheral can be owned and controlled by only one core at a given time.

    I hope I answered your questions clearly. If you have any further queries, please respond back on this thread.

    Regards,
    Teja.

  • Hi Teja,

    Thank you for the prompt response. Yes, your answers are clear. I just have a follow-up question regarding #3: Your answer suggested either A53 (Linux) or the MCU R5FSS_0-0 core can own and control the CPSW peripheral, but only one core at a given time. That means I can refer to the MCU document for the same signals on CPSW. For example, on a AM64x EVM, I can monitor PPS on Pin B8 on J2 when I run PTP on Linux, as stated in this page: https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/latest/exports/docs/api_guide_am64x/EXAMPLES_ENET_CPSW_TSN_GPTP_TR.html

    Is this correct?

    Thank you.

  • Hi Matt,

    Yes, the signals will be same in both cases. You can use the same pin for monitoring PPS independent of the environment that you are running.

    Regards,
    Teja.

  • Thank you for the answer!

  • Hi Teja,

    Sorry, I have some more questions regarding #3:

    a. If one of the R5F cores (MCU) controls the CPSW, I guess the CPSW needs to be disabled from the Linux device tree in order for the Linux to run, correct?

    b. Again related to a., what is the use case that the CPSW Ethernet is disabled in Linux and controlled by one of the R5F cores? It does not seem to make sense to disable the Ethernet in Linux on a AM64x to me. I wonder what the possible applications are.

    Thank you for your help!

  • Hi Matt,

    a. Yes, it needs to be disabled from the Linux device tree to prevent Linux and uboot to access the peripheral. 

    b. If the usecase is memory sensitive, or the TSN application is expected to run in RTOS environment for the required application, then users would opt for using R5. There are few more usecases which we came accross with other customers which wanted to control CPSW with RTOS on R5 core, in tsn and controlled loop applications. 

    Regards,
    Teja.

  • Hi Teja,

    In the case of b, on a AM64x EVM, the Linux may control the first Ethernet port, one of the R5 cores control the second Ethernet port. If needed, another R5 control the third Ethernet port. Does this make sense?

    Also, all three ports can use CPSW, or the third one need to use PRU?

    Thank you!

  • Hi Matt,

    Unfortunately, this is not possible to split the CPSW ownership between multiple cores concurrently. At given time, the peripheral can be controlled by only one core. So, Having one port connected to R5 and one connected to A53 cannot be possible. But if you need such functionality, we have shared memory based ethernet traffic tunneling drivers accross Linux and RTOS, which support both R5-R5 and R5-A53 communication.

    Coming to the next part of your query, It is not possible for all 3 ports to be controlled by CPSW. One port is directly connected to CPSW, one to ICSS, and one port is muxed between the two. So, CPSW can only use 2 ports at the highest.

    If you need more ports being connected and can use ICSSG for your system, we have 2 ICSSG peripherals available, and these can run on same core, or 2 different cores. Or you can use CPSW and ICSS on different cores as well.

    You can find related documentation here: https://www.ti.com/lit/an/spradh8/spradh8.pdf?ts=1736738445031&ref_url=https%253A%252F%252Fwww.bing.com%252F

    Regards,
    Teja.

  • Thank you Teja for the answers!