.. _run-apps-from-ddr-on-r5-cores:

Once the R5 core is out of reset, the R5 defaults to no execute permissions for
the DDR memory space. The side effect of this is,  that all code, from entry point 
till the code that sets up the MPU (Memory Protection Unit), has to be run from 
internal memory.

.. _run-bios-app-from-ddr-on-r5:

Run BIOS Applications from DDR on R5
-------------------------------------

In BIOS, the application sets up the MPU as per the memory configuration specified
in the *.xs file (that is referred to in the applications bios config file).  Once the
MPU is setup by the app, the rest of the code can run from DDR. 

To ensure that all code from entry point to MPU setup is run from internal memory, the 
text sections of the following libs must be placed in internal memory using the application's linker
command file. 

* *sysbios.aer5f(.text)

* *boot.aer5f(.text)

* *auto_init.aer5f(.text)

* *<app>_per5f.oer5f(.text)

Refer `emac_linker_r5.lds <https://git.ti.com/keystone-rtos/emac-lld/blobs/master/test/EmacLoopbackTest/am65xx/emac_linker_r5.lds>`__
for an example.

.. note::  Please note that you need to replace *<app>_per5f.oer5f with the corresponding
           file for your application. For eg, if the application's .cfg file is emacUnitTest_r5.cfg, 
           then the .oer5f file will be named emacUnitTest_r5_per5f.oer5f


You also need to update the *.xs file referred to by the applications .cfg file
to make sure that the DDR has execute privileges. Please refer `r5_mpu.xs <http://git.ti.com/keystone-rtos/processor-pdk-build/blobs/master/am65xx/r5_mpu.xs>`__
for an example memory configuration. You could also make the applications .cfg 
file refer to the common .xs file, as shown in the example 
`emacUnitTest_r5.cfg <https://git.ti.com/keystone-rtos/emac-lld/blobs/master/test/EmacLoopbackTest/am65xx/emacUnitTest_r5.cfg>`__. 

.. warning::   Once you update the .xs file, please note remember to delete *<app>_per5f.oer5f 
               from the applications *configuro directory, so that it is autogenerated again.
               If you simply do a clean build, *<app>_per5f.oer5f will not be updated to reflect the
               changes in the *.xs file.



.. _run-baremetal-app-from-ddr-on-r5:

Run Baremetal Applications from DDR on R5
------------------------------------------

Baremetal applications have similar restrictions on running code from 
internal memory till the MPU is configured, just like BIOS applications.
For best comaptibility, however, make sure that the entry point is 
always the reset vector, and that the code that sets up the DDR access
permissions in the MPU resides completely within 0x100 bytes of the 
entry point.

For applications that find the default R5 configuration setup by the
CSL sufficient, there is another method that can be used to execute
an application from DDR. If the bootloader (SBL) is re-built using the
SBL_SKIP_MCU_RESET compile option (by enabling the corresponding line
in `sbl_component.mk <https://git.ti.com/keystone-rtos/sbl/blobs/master/sbl_component.mk#line399>`__,
then SBL will branch to the application entry point without resetting the R5 core.

In this scenario, as the  R5 core was already setup when the SBL
invoked CSL init, the app can execute directly from DDR, right from its
entry point. However, the app must take care not to redo the R5 initialization
using CSL init, as the CSL initialization code assumes that the R5 registers are at their
reset default values. This can be done by simply defining an empty __mpu_init function in the
baremetal application. Refer `sbl_smp_r5.asm <https://git.ti.com/keystone-rtos/sbl/blobs/master/example/k3MulticoreApp/sbl_smp_r5.asm>`__ 
for an example.
