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: AMP on R5F

Part Number: AM6442

HI

According to

    (9) AM6442: AM64x Software build sheet - Processors - INTERNAL forum - Processors - INTERNAL - TI E2E support forums

 

"

 The Cortex A clusters are designed for SMP, one symmetric operating system (or one hypervisor). There are shared registers and concepts of privilidge levels, so in practice one SMP operating system, and assigning tasks statically per core is what an RTOS enables. There are commercial RTOSes that already enable to do this (VxWorks, QNX, GHS Integrity, ...).

"

 

How about R5F?

Is it also designed for SMP?

Is it possible to run MCU+ SDK Free RTOS at each R5F cores?

 

  • Hi,

    Thanks for your query.

    A53 NORTOS, A53 FREERTOS and A53 FREERTOS SMP support is a experimental feature, see Experimental Features

    Best Regards

    Ashwani

  • I'd like to know about R5F.

    Is it possible to run MCU+ SDK Free RTOS at each R5F cores?

  • Hi Tsrumoto,

    It should be supported out of box. I hope you have referred below page:

    https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/09_01_00_41/exports/docs/api_guide_am64x/index.html

    MCUSDK contains examples, libraries and tools to develop RTOS and no-RTOS based applications for ARM R5F, ARM M4F, ARM A53 (single core and SMP on both cores) CPUs and related peripherals.

    Best Regards

    Ashwani

  • Hi Ashwani,

    I'm very sorry, again.

    But, the page doesn't mention the details.

    I know the free RTOS TI support on SDK is not SMP RTOS.

    Therefore, if customer run it on every R5F core, each core run separatory.

     

    Then, my first concerning point is, if there is any resource which is shared among R5F cores. 

    At Cortex-A case, Pekka mentioned that some resources are shared among cores, then only one Free RTOS can run.

    I'd like to know if it is true on R5F also or not.

     

    Second concerning point is, if the free RTOS can be run on each R5F core, I'd like to know if customer need prepare some controlling mechanism of the shared resources such like hypervisor.

  • Hello Tsurumoto-san,

    I will respond to what I think you are asking. If I misunderstood your question, please restate the question for us.

    Is symmetric multicore processing supported on R5F cores? 

    No.

    Can I run MCU+ SDK on each of the R5F cores in my system, or are there limitations? 

    You can run FreeRTOS, NORTOS, etc on every R5F core that is in the processor that you select. For example, on AM6442, which has two R5F subsystems with 2 R5F cores in each subsystem, you can run a separate RTOS instance on each R5F core, for 4 RTOS instances total across the 4 R5F cores.

    How should resources be used in a multicore system? 

    In general, each peripheral is designed to be controlled by only one software instance (i.e., two different R5F cores should NOT try to control the same UART peripheral). Similarly, each memory region should only be used by one software instance, unless you are specifically using it as shared memory to pass data between cores.

    For more information about peripheral usage and memory usage in a multicore system, please refer to the AM64x academy, multicore module, pages "How to allocate peripherals" and "how to allocate memory"
    https://dev.ti.com/tirex/explore/node?a=7qm9DIS__LATEST&node=A__AROmAnuFxeqz306G2XuoZw__AM64-ACADEMY__WI1KRXP__LATEST

    How is this enforced? 

    Whenever a software instance wants to use a peripheral, it requests that peripheral from the SYSFW software running on a separate device manager core. If the peripheral has already been allocated to a different software instance, that request will be denied. Customers will often see that as their MCU+ application stalling out at the line where they request ownership of the peripheral.

    What about shared resources, like DMA, interrupt routers, etc? 

    These are configured in the board config / resource management settings. The settings are applied early in the boot process by either the SBL boot flow (used by default in MCU+ SDK), or the SPL boot flow (used by default in the Linux SDK). For some very basic getting started information about configuring those settings, see https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1308689/faq-how-to-use-resource-partitioning-tool-with-processor-sdk-v9-1

    Regards,

    Nick

  • Can I run MCU+ SDK on each of the R5F cores in my system, or are there limitations? 

    You can run FreeRTOS, NORTOS, etc on every R5F core that is in the processor that you select. For example, on AM6442, which has two R5F subsystems with 2 R5F cores in each subsystem, you can run a separate RTOS instance on each R5F core, for 4 RTOS instances total across the 4 R5F cores.

    I see. How about the mixing the OS among these 4 R5F cores?

    For example, 1 RTOS instance on one R5F core, and 3 noRTOS instance on three R5F cores.

  • Hello Tsurumoto-san,

    As far as I am aware, you can run different OSes (or no OS) on different R5F cores. Please keep in mind that with the MCU+ SDK, TI tests FreeRTOS and NORTOS (i.e., bare metal).

    I believe there are some third party companies who provide other RTOSes other than the MCU+ SDK. We do NOT test the AM64x running a combination of TI-provided OSes, and third-party provided OSes.

    Regards,

    Nick

  • I am going to reassign your thread to another team member who can double-check the information I have provided. Feel free to ask followup questions, or to create a new e2e thread if you have questions about a different subject.

    Regards,

    Nick

  • I see. How about the mixing the OS among these 4 R5F cores?

    Hello Tsurumoto-san,

    You can run Free RTOS on one core and Run Bare Metal (NO RTOS ) on different cores, and there is no issue.

    Please keep in mind that  we support only free RTOS and NO  RTOS in MCU+SDK .

    Regards,

    S.Anil.

  • I see. Thanks Nick and Anil!