Because of the holidays, TI E2E™ design support forum responses will be delayed from Dec. 25 through Jan. 2. Thank you for your patience.

  • State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 100 subscribers
  • Views 586 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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: Booting MCU2_1 application form SBL

Parth Nagpal
Mastermind 42135 points
Part Number: TDA4VM

Hi,

Section “6.3.3.2” of TDA4VM TRM states:

“In split mode, each R5F core works completely independent from the other (asymmetric multi-processing, or AMP). Each core uses its own RAMs and interfaces, with no coherence between the two cores. The only restriction is that CPU0 must be in a higher power/reset state than CPU1. For instance, CPU1 cannot be out of reset if CPU0 is not.”

I am building an application for MCU2_1. How can I achieve the above condition to boot the application on MCU2_1

  • 0
    TI__Mastermind 42135 points

    Hi,

    Referring to TRM section 6.3.3.3, in split mode, each R5 core can work completely independent with the only restriction that CPU0 must be in higher power/reset state than CPU1. For instance, CPU1 can not be out of reset if CPU 0 is not. So, if you want to run an application in CPU1 of R5 core, say mcu2_1, we need to make sure that mcu2_0 is out of reset.

    When an application is run using CCS, the gel files takes care of taking mcu2_0 out of reset and the application can be loaded and run on mcu2_0 without any issues.

    But, when the application is run using SBL booting, by default, the SBL only releases the cores for which the binaries are available in the appimage. So, if the appimage does not have any binary for mcu2_0, then mcu2_0 won’t be released and the application can’t run on mcu2_1.

    For this reason, all the applications that are built for mcu2_1 in PDK, uses dummy app sbl_mcux_0_dummy_app.rprc available at <PDK_Install_Path>\packages\ti\build\j721e. See the part highlighted in red in snapshot from a build of mcu2_1 application below:

    [Note]: When building application for cores other than mcu1_0, sciServer is always loaded on mcu1_0. See the part highlighted in green in the snapshot,

     

    However, SBL can be modified to release the CPU0, if there is a binary available for CPU1. This way, there will be no need for loading a dummy application on CPU0.

    There are many ways for modifying the SBL to release CPU0. Please find a patch for one such example below:

    sbl_rprc.patch

    Apply the patch by running following command at <PDK_Install_Path>\packages\ti\boot\sbl\src\rprc

    git apply <Path_To_sbl_rprc.patch>

     Rebuild the lib and binary for MMCSD

    • Switch to PDK\package\ti\build directory
    • gmake BOARD=j721e_evm CORE=mcu1_0 sbl_lib_<BootMode>_clean
    • gmake BOARD=j721e_evm CORE=mcu1_0 sbl_<BootMode>_img_clean
    • gmake BOARD=j721e_evm CORE=mcu1_0 sbl_<BootMode>_mmcsd
    • gmake BOARD=j721e_evm CORE=mcu1_0 sbl_<BootMode>_img

    Where BootMode can be:

    mmcsd, uart, ospi

    With the generated SBL you should be able to boot binaries on mcu2_1 without having to load a dummy image on mcu2_0.

    Regards,
    Parth