How to load an existing SDK example/demo:
- Standalone
- Integrated with linux
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.
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 http://software-dl.ti.com/jacinto7/esd/processor-sdk-rtos-jacinto7/latest/exports/docs/psdk_rtos_auto/docs/user_guide/ccs_setup_j721e.html for how to setup CCS.
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.
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 - https://e2e.ti.com/support/processors/f/791/t/931992 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.
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 http://infocenter.arm.com/help/topic/com.arm.doc.ddi0460c/DDI0460C_cortexr5_trm.pdf for details.
# Linker File .text_boot { *boot.aer5f*<*boot.o*>(.text) } 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
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.
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 |
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.
Cooperative application:
Automatic, if you have the firmware with the correct pre-defined name as mentioned in the table.
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 https://software-dl.ti.com/jacinto7/esd/processor-sdk-linux-jacinto7/latest/exports/docs/linux/Foundational_Components_U-Boot.html#remoteproc for more details.
# 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
# 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
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.
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.
Regards,
Karan
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:
Regards
Karan