点击上方蓝字【囧囧妹】一起学习，一起成长！
一、编译SBL 可以加载的app image
SBL 加载的应用程序通常必须符合sbl-memory-usage（J721E - SBL(2)）（内存映射前面已经说过）。在应用程序的链接器命令文件中，必须注意不要使用 MCU R5 的 ATCM 存储器的前 0x100 字节，以及从 0x41C00100 到 0x41C80000 的 SBL 保留存储器，用于 J7xx 器件（0x41C00100 到 0x41C3E00，对于 AM65xx）。如果应用程序已签名，则不得在 SBL 暂存区中放置可加载部分。临时内存可在应用程序运行时用于堆栈、堆等。 此外，现在需要在 MCU1_0 上启动 SCISERVER，作为 MCU1_0 应用程序的一部分。SBL 为 MCU SRAM 中的 SCISERVER 留下的板级配置空间应做为预留，至少在 MCU1_0 上执行 Sciclient_init() 之前（ 0x41C80000 到 0x41C82000）。同样，从 0x41CFFB00 到 0x41D00000 的公共头部位置也应该保持预留，直到 Sciclient_init() 完成执行。 MCU 无法访问 MPU 的本地地址 0x0，因此任何 MPU 链接器命令文件都不得指定该内存区域中的任何可加载段。SBL 将无法访问该内存来加载代码或数据。 使用 CCS：使用 pdkProjectCreate 脚本创建的任何项目都将自动生成 SBL 可加载应用程序，作为构建后的一部分。
使用 makefile：将以下行添加到组件的 .mk 文件中。
现有的 ELF 可执行文件：通过调用 K3ImageGen 脚本。
根据示例，ELF 应用程序可执行文件可以转换为可由 SBL 以多种方式加载的镜像。
app_name_SBL_APPIMAGEGEN = yesexport app_name_SBL_APPIMAGEGEN
Linux Syntax: ./K3ImageGen.sh <CoreID> <.out>Example:cd <sdk_install_path>/pdk_*/packages/ti/boot/sbl/tools/scripts/./K3ImageGen.sh 4 sbl_baremetal_boot_test_<board>_mcu1_0TestApp_release.xer5f
Windows Syntax: K3ImageGen.bat "<CoreID> <.out>"Example:cd <sdk_install_path>\pdk_*\packages\ti\boot\sbl\tools\scripts\K3ImageGen.bat "4 sbl_baremetal_boot_test_<board>_mcu1_0TestApp_release.xer5f"
多核镜像：顾名思义，多核镜像允许 SBL 从单个镜像加载多个内核的应用程序。创建这样的镜像涉及三个步骤：
为单个内核生成 ELF 应用程序可执行文件
将 ELF 可执行文件转换为中间 .rprc 镜像
组合单个内核的 .rprc 映像以创建单个多核镜像
For Linux:mono <PDK>/packages/ti/boot/sbl/tools/out2rprc/bin/out2rprc.exe input.out output.rprc
For Windows:<PDK>\packages\ti\boot\sbl\tools\out2rprc\bin\out2rprc.exe input.out output.rprc
For Linux:<PDK>/packages/ti/boot/sbl/tools/multicoreImageGen/bin/MulticoreImageGen LE 55 output.appimage <core_id_1> core_1.rprc <core_id_2> core_2.rprc
For Windows:<PDK>/packages/ti/boot/sbl/tools/multicoreImageGen/bin/MulticoreImageGen.exe LE 55 output.appimage <core_id_1> core_1.rprc <core_id_2> core_2.rprc
注意：
linux 主机环境需要安装mono。
用于核ID 和设备 ID 的值可以在sbl/soc/k3/sbl_slave_core_boot.h中找到
要简单地加载 ELF 而不执行它，请使用 CoreID 值 ONLY_LOAD_ID
如果提供了 MCU_1 内核的映像，SBL 将尝试切换到split模式。
如果只提供 MCU_0 的镜像，SBL 不会改变 MCU 子系统的模式。
要在 MPU 上启用 SMP，即从同一地址的单个二进制文件中执行多个 MPU，请使用以下 core_id 之一
MPU1_SMP_ID：相同的应用程序二进制文件在 MPU 集群 1 的两个内核上运行
MPU2_SMP_ID：相同的应用程序二进制文件在 MPU 集群 2 的两个内核上运行
MPU_SMP_ID：同一个应用程序二进制文件运行所有 MPU
使用 combine_appimage 工具启动 HLOS+RTOS appimage
创建包含在 SoC 的 Cortex-A 内核上启动 U-boot 或 HLOS 以及在其他远程内核上启动 RTOS 镜像所需的所有镜像的 combine.appimage 文件可以通过以下 4 个步骤完成：
修改 sbl/tools/combined_appimage/config.mk 文件HLOS_BIN_PATH 变量以指向要引导的所需 HLOS 镜像 修改同一文件中的HLOS_BOOT 变量以选择“开发”选项（引导至 SPL/U-boot）或“优化”选项（引导 ATF/OPTEE/Linux） 修改RTOS_BIN_PATH 变量以指向您的 RTOS 二进制文件，然后列出要在变量中加载的内核和二进制文件：IMG1、IMG2、... 使用以下 make 命令制作 combined.appimage 输出应用程序：
make BOARD=<board> GCC_LINUX_ARM_PATH=<path>Example:cd <sdk_install_path>/pdk_*/packages/ti/boot/sbl/tools/combined_appimagemake BOARD=<board> GCC_LINUX_ARM_PATH=<sdk_install_path>/gcc-arm-9.2-2019.12-x86_64-aarch64-none-elfcd bin/<board>ls *.appimage
有时，对于超低延迟启动或无 DDR 系统等极其受限和特殊的用例，可以将 ELF 应用程序可执行文件转换为可以直接从启动媒体执行的二进制镜像，而无需加载到内部存储器中。
由于始终可以访问内部存储器，因此这种执行模式允许稍后完成或完全跳过某些其他强制性步骤，例如 DDR 初始化或时钟初始化。
使用这种高度约束的系统需要一些特殊的步骤：
确保启动媒体支持就地执行 (XIP)。 使用自定义 SBL 构建选择构建选项以构建满足用例要求的 SBL。 在应用程序的链接器命令文件中，确保所有数据段、堆栈、堆和全局都在内部读/写存储器中 在应用程序的链接器命令文件中，确保可加载部分中没有漏洞。与 ELF 可执行文件的大小相比，这种不连续的部分会大大增加二进制镜像的大小。
要从应用程序 ELF 文件生成可执行二进制镜像，请将以下行添加到组件的 .mk 文件中
app_name_SBL_APP_BINIMAGEGEN = yesexport app_name_SBL_APP_BINIMAGEGEN
打开 <PDK>/packages/ti/boot/sbl/tools/scripts/K3ImageGen.sh for Linux 或 K3ImageGen.bat for Windows 通过添加标志来 编辑以“$PDK_INSTALL_PATH/ti/build/makerules/x509...”开头的第 88 行： -e $PDK_INSTALL_PATH/ti/build/makerules/k3_dev_mek.txt -y ENCRYPT
cd <sdk_install_path>/pdk_*/packages/ti/boot/sbl/tools/scripts./K3ImageGen.sh 4 <path_to_ELF_file>/sbl_baremetal_boot_test_<board>_mcu1_0TestApp_release.xer5f
