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.

[FAQ] TDA4VM: Different ways to load an RTOS or Baremetal application along with Linux

Part Number: TDA4VM

How to load an existing SDK example/demo:

  1. Standalone
  2. Integrated with linux

  • Loading a standalone application

    An SDK example/demo can be loaded by a number of ways. This FAQ tries to enumerate all the number of ways in which an application can be loaded.


    All applications are tested with CCS using the "No Boot mode". When using this boot mode, the SoC needs to be initialized with the GEL files (packaged with Code Composer Studio)

    Refer for how to setup CCS.

    SBL (can also boot multicore app)

    Most of the stand alone applications are tested with SBL. SBL can also be used to boot multicore applications on multiple core.


    This is the most convenient way to use SBL to load an application. Booting requires putting the MMCSD SBL (tiboot3.bin), sysfw.bin and the application elf (app) in the boot partition of the SD card.


    This is mostly for faster boot time. Booting requires putting the OSPI SBL at 0x0 offset of the flash, sysfw.bin at 0x40000 and application elf at 0xA0000.

    Integration with Linux

    Sometimes an RTOS/Baremetal application might run successfully with CCS / SBL in a standalone manner i.e. there is nothing running on the processor apart from the application itself. But when there are other pieces of SW, like Linux, running alongside it - then there are multiple things which need to be looked at. Please see the FAQ - for more details on this.

    When loading and running an application on R5F along with Linux, the application can be loaded by R5 SPL or u-boot or Kernel. The coming sections describe loading from all of them and what needs to be taken care of while loading from each of them.

    Q> Can any xer5f can be loaded as a firmware from u-boot/kernel provided it doesn’t conflict with the memory map or any other resource?

    Not any image. Along with the above, there are range checks when kernel is doing the load and boot (so it will error out if the firmware sections do not fall into the reserved-memory regions associated with the device - this can be defined in the DTB). The image needs to adhere to the ATCM, BTCM, loczrama settings configured for that processor.

    General careabouts for applications when running on R5F

    When R5 come out of reset, DDR (or anything after 0x7FFFFFFFF) is execute never as shown in the table 7-1 Default Memory Map, so the MPU entries need to be modified by the application startup code in case it needs to execute from such sections. For this the MPU initialization code needs to be in a memory which has execute permissions by default. Hence we see that the MPU configuration, Cache related functions are put in TCM or other internal memories.

    Refer for details.

    # Linker File
    .text_boot {
    }  palign(8)   > R5F_TCMB0
    .text:xdc_runtime_Startup_reset__I     : {} palign(8) > R5F_TCMB0
    .text:ti_sysbios_family_arm_v7r_Cache* : {} palign(8) > R5F_TCMB0
    .text:ti_sysbios_family_arm_MPU*       : {} palign(8) > R5F_TCMB0

    Loading from R5 SPL

    R5 SPL can load the MCU R5F0_0 (MCU1_0) and MAIN R5F0_0 (MCU2_0).

    For R5 SPL to pick up the application and load it, we need to place the application elf in the filesystem at /lib/firmware and by a pre-defined name.

    Pre-defined fw names loaded by R5 SPL
    Core Firmware pre-defined name
    MCU R5F0_0 (mcu1_0) j7-mcu-r5f0_0-fw
    MAIN R5F0_0 (mcu2_0) j7-main-r5f0_0-fw

    Key careabouts to load application from R5 SPL

    • The MPU configuration related code needs to be in BTCM/other internal memory (but NOT ATCM).
    • Firmware can be picked up only from the file system in the SD card not NFS or eMMC.

    Special case of loading MCU1_0 with R5 SPL

    The MCU R5F is special since the same core is also used for booting in Linux (R5 SPL). The Linux boot flow has the R5 SPL running from MCU SRAM, and it will just perform a load and branch to the entry point address point from the new application firmware image that is being early-booted. There is no new core reset performed (unlike the ROM to R5 SPL switch), and as such the application firmware has to be a cooperative application.

    • In R5 SPL the ATCM in disabled for MCU R5F0_0, hence the application loading there should not use ATCM at all.
    • When loading a firmware on the MCU R5F0_0, the ATF loading and starting steps are done after the firmware load is done. The last step is branching to the new image entry point. Hence the memory map of the application should not overwrite the existing code in the memory which is yet to be executed.
    • In case of R5 SPL loading the firmware, there is no reset of the core. The SPL just branches to the new entry point of the firmware i.e. the Program Counter (PC) value is changed.

    Cooperative application:

    1. Conform to the mode that the core has come up
    2. Stay away from the memory that the R5 SPL is running from
    3. Not overwrite the MPU entries used by the R5 SPL

    Process of loading

    Automatic, if you have the firmware with the correct pre-defined name as mentioned in the table.

    Loading from u-boot

    The u-boot can be halted at the prompt and you can load the firmware manually or you can some environment variables (see details below) to do the same automatically. Note that, to load a firmware on to MCU R5F0_0 or MAIN R5F0_0 (two cores which R5 SPL can also load), you need to disable loading them in the R5 SPL. This can be done by just deleting/renaming the files j7-mcu-r5f0_0-fw and j7-main-r5f0_0-fw in the /lib/firmware. This way R5 SPL will not find a valid image to load and won't load the cores.

    Look to for more details.

    Key careabouts to load application from u-boot

    • In u-boot the ATCM in enabled, hence the application should have its reset vectors in ATCM. Booting from anywhere apart from ATCM is not possible in case if the ATCM is enabled.
    • The MPU configuration related code needs to be in ATCM/BTCM/other internal memory.
    • Firmware can be picked up from the file system in the SD card and eMMC.

    Loading sequence

    • CORE0 for any R5F Sub-system needs to be loaded before CORE1.
    • In case you try to load MAIN R5F0_1 befor MAIN R5F0_0 it will give an error.

    Process of loading

    • Automatic - if you modify environment variables. In the following example we try to load core MAIN R5F0_1 (MCU2_1) with the binary /lib/firmware/j7-main-r5f0_1-fw
    # At u-boot prompt, run the following (only for the first time)
    Hit any key to stop autoboot:  0
    => setenv rproc_fw_binaries '3 /lib/firmware/j7-main-r5f0_1-fw'
    => setenv dorprocboot 1
    => saveenv
    => boot
    • Manual - stop at u-boot prompt and load using rproc commands.
    # At u-boot prompt, run the following
    Hit any key to stop autoboot:  0
    => rproc init
    => rproc list
    0 - Name:'r5f@41000000' type:'internal memory mapped' supports: load start stop reset
    1 - Name:'r5f@41400000' type:'internal memory mapped' supports: load start stop reset
    2 - Name:'r5f@5c00000' type:'internal memory mapped' supports: load start stop reset
    3 - Name:'r5f@5d00000' type:'internal memory mapped' supports: load start stop reset
    4 - Name:'r5f@5e00000' type:'internal memory mapped' supports: load start stop reset
    5 - Name:'r5f@5f00000' type:'internal memory mapped' supports: load start stop reset
    6 - Name:'dsp@4d80800000' type:'internal memory mapped' supports: load start stop reset
    7 - Name:'dsp@4d81800000' type:'internal memory mapped' supports: load start stop reset
    8 - Name:'dsp@64800000' type:'internal memory mapped' supports: load start stop reset
    => load mmc 1:2 0x90000000 /lib/firmware/j7-main-r5f0_1-fw
    2600844 bytes read in 60 ms (41.3 MiB/s)
    => rproc load 3 0x90000000 0x${filesize}
    Load Remote Processor 3 with data@addr=0x90000000 2600844 bytes: Success!
    => rproc start 3
    => => boot

    Loading from Kernel

    Kernel will pick up the firmware and load it, provided it doesn't conflict with the memory map (resides in the memory reserved for it in the DTB), doesn't conflict resources with the Kernel and is placed in /lib/firmware by the pre-defined name. Also, the core Kernel is trying to load should not have been loaded by either R5 SPL or u-boot.

    Key careabouts to load application from kernel

    • There is one caveat here, here the core0 loading before core1 is not enforced and so if core0 firmware image is larger than core1, then mostly because of SMP, the Core1 tends to get booted first, causing a hang. This is because as mentioned earlier, core0 always needs to be loaded before core1.
    • Supports loading the firmware from NFS. Kernel always uses the relevant file system.

    Linux remote proc requires a resource table, without which it can not communicate from the MPU. If we don't have a proper resource table and load a firmware from u-boot, the kernel can not attach to it even though the firmware might be running successfully.

    In case of remote proc mode, kernel loads. In case of IPC only mode, R5 SPL loads and kernel just attaches to it.



  • From SDK7.1 and later there are a few changes to the above post.

    1. The MCU1_0 is the only core which can be loaded from R5F SPL. MCU2_0 can no longer be loaded by R5 SPL.

    2. Skipping MCU1_0 load from R5F SPL and then loading from u-boot is not possible. This because SDK7.1 and later SDKs have DM (Device Manager) integrated as a part of the MCU1_0 binary and as the DM needs to be up as soon as R5F SPL execution is done hence the MCU1_0 application needs to be loaded at the earliest by R5F SPL (and not u-boot).

    Failing to meet the above will result in a failed boot as no other core (including u-boot on A72) can be booted without DM on MCU1_0.

    Please go through the below links to understand more on why this change (of hosting DM on MCU1_0) was made: