CAN 响应和引导加载程序演示应用程序

此应用程序演示了 J721E SoC 上的八通道 SPI 闪存控制器提供的快速启动功能。默认情况下，它使用基本应用程序启动主域内核，并提供在 MPU1_0（即 A72）内核上交替启动 Linux 或 QNX 的机制。此外，它还演示了通过 J721E SoC 上的 MMCSD 介质启动主域内核。该应用程序执行以下操作：

 MCAL Can 驱动程序托管在 MCU1_0 上传输 64 字节 CAN 消息，或者运行 CAN 分析使用示例应用程序映像启动主域核心（可选）在主域 MPU1_0 上启动 HLOS（Linux、QNX）

这有助于实现汽车 ECU 通常需要的早期 CAN 响应功能，然后启动 SoC 上的主要域内核。

系统资源

[J721E]	Name	mcu 1 0	Note that all computing cores might not be supported in MCUSW
[J721E]	MCU R5F Core 0	mcu 1 0	Note that all computing cores might not be supported in MCUSW
^	MCU R5F Core 1	mcu 1 1	^
^	1ST MCU Core 0	mcu 2 0	^
^	1ST MCU Core 1	mcu 2 1	^
^	2ND MCU Core 0	mcu 3 0	^
^	2ND MCU Core 1	mcu 3 1	^
^	A72 Core 0	mpu 1 0	^
^	A72 Core 1	mpu 1 1	^
^	1ST C66X DSP	c66x_1	^
^	2ND C66X DSP	c66x_2	^
^	C7X DSP	c7x_1

该设备实现了一个双核 Arm® Cortex®-A72 MPU，它与其他模块一起集成在计算集群中。 Cortex-A72 内核是通用处理器，可用于运行客户应用程序。 A72SS 围绕 Arm Cortex-A72 MPCore（A72 集群）构建，由 Arm 提供并由 TI 配置。它基于对称多处理器 (SMP) 架构，因此可提供高性能和最佳电源管理和调试功能。 A72 处理器是一个多问题无序超标量执行引擎，具有集成的 L1 指令和数据缓存，兼容 Armv8-A 架构。 Armv8-A 架构带来了许多新特性。其中包括 64 位数据处理、扩展虚拟寻址和 64 位通用寄存器。

MCU_ARMSS 是针对拆分/锁定操作配置的 Arm® Cortex®-R5F 处理器的双核实现。它还包括随附存储器（L1 缓存和紧耦合存储器）、标准 Arm® CoreSight™ 调试和跟踪架构、集成向量中断管理器 (VIM)、ECC 聚合器以及用于协议转换和地址转换的各种包装器，以便轻松集成到SoC。

TMS320C71x 是下一代定点和浮点 DSP 平台。 C71x DSP 是德州仪器 (TI) DSP 系列中的新内核。 C71x DSP 支持矢量信号处理，与 C6x DSP 系列相比，在广泛的通用信号处理任务中显着提升了 DSP 处理能力。此外，C71x 还提供了多项专用功能，可将目标功能加速 30 倍以上。除了扩展向量处理能力外，新的 C71x 内核还融合了先进技术来提高控制代码效率和编程的简易性，例如分支预测、受保护的流水线、精确的异常和虚拟内存管理

C66x 子系统基于 TI 的标准 TMS320C66x DSP CorePac 模块。它包括子系统逻辑，以简化 C66x CorePac 与 SoC 的集成，同时最大限度地重复使用以前设备的软件。 C66x DSP 通过增强功能和新功能扩展了 C64x+ 和 C674x DSP 的性能。许多新功能旨在提高矢量处理的性能。 C64x+ 和 C674x DSP 支持 16 位数据的 2 路 SIMD 操作和 8 位数据的 4 路 SIMD 操作。在 C66x DSP 上，通过扩展 SIMD 指令的宽度来提高矢量处理能力。 C66x DSP 可以执行对 128 位向量进行操作的指令。例如，QMPY32 指令能够在每个包含四个 32 位数据的两个向量之间执行元素到元素的乘法。 C66x DSP 还支持 SIMD 进行浮点运算。改进的向量处理能力（每条指令可以并行处理多个数据）与 C6000 架构的自然指令级并行性（例如，每个周期最多执行 8 条指令）相结合，产生了非常高的并行性，可通过DSP 程序员通过使用 TI 优化的 C/C++ 编译器

内部依赖

此应用程序依赖于多个组件，并在以下部分详细说明

 MCAL CAN 驱动程序MCAL BSW 存根 使用 coresdk_rtos_jacinto_xx_yy_xx_bb/mcusw/mcal_drv/mcal/Bsw_Stubs 的存根。 函数 CanIf_TxConfirmation () 是必需的。MCAL 配置 使用 coresdk_rtos_jacinto_xx_yy_xx_bb/mcusw/mcuss_demos/mcal_config 中的 CAN 和 DIO 配置。

外部依赖

此应用程序依赖于 Processor SDK RTOS 的辅助引导加载程序 (SBL) 组件。有关在 J721E 上使用辅助引导加载程序的更多详细信息，请参阅 SBL J721E 用户指南和 SBL AM65x/J721E 详细信息。

流程图

以下流程图显示了 MCU1_0 上的主要应用程序，它最多可以产生 2 个当前任务。

MCU1_0 CAN and Bootloader Application

如果 CAN 功能设置为“can_profiling”，以下流程图显示了 CAN 任务的功能。

如果 CAN 功能设置为“can_fast_response”，以下流程图显示了 CAN 任务的功能。

以下流程图显示了引导任务的功能，以及在主域核心上启动的应用程序。

引导应用程序的编译时配置

1、Enable/Disable Boot Task 可以启用/禁用引导主域核心的任务。以下是此功能的配置标志。

BOOTFUNC 选项为“启用”（默认）或“禁用”。

2、启动媒体启动任务可以使用位于 OSPI 或 MMCSD 卡上的应用程序映像启动主域内核。以下是此功能的配置标志。

BOOTMODE 选项是“ospi”（默认）或“mmcsd”。请注意，如果使用“ospi”选项，则自定义辅助引导加载程序 (sbl_cust_img) 将加载 MCUSW 引导应用程序。如果使用“mmcsd”选项，则应使用 mmcsd 辅助引导加载程序 (sbl_mmcsd_img) 加载 MCUSW 引导应用程序。

3、MPU1_0 的引导操作系统默认情况下，引导任务将为所有主域内核（包括 MPU1_0）加载为 TI 实时操作系统 (RTOS) 编写的示例应用程序。或者，可以在 MPU1_0 上加载 Linux 或 QNX 操作系统。以下是此功能的配置标志。

HLOSBOOT 选项为“none”（默认，这意味着 MPU1_0 TI RTOS 应用程序已加载）、“qnx”或“linux”。

4、CAN 功能 CAN 任务可以执行快速 CAN 响应、对许多消息进行一些 CAN 分析，或者完全关闭。以下是此功能的配置标志。

CANFUNC 选项是“can_fast_response”（默认）、“can_profiling”或“none”（完全禁用 CAN 任务）。

CAN 分析/CAN 快速响应任务的编译时间配置

1、启用 CAN 仅传输模式在仅传输模式下，如果外部 CAN 实用程序（如 CANOE 工具或 PEAK 工具）连接到 EVM 板，则可以接收消息。 J721E EVM 有四个 CAN 端口：MCU_MCAN0、MCU_MCAN1、MCAN0 和 MCAN2。但是，此演示仅使用第一个实例 MCU_MCAN0。以下是与此功能相关的配置标志。

    CAN_LOOPBACK_ENABLE 启用/禁用内部环回模式。选项是“STD_ON”或“STD_OFF”。 CAN 环回配置存在于 coresdk_rtos_jacinto_xx_yy_xx_bb/mcusw/mcuss_demos/mcal_config/Can_Demo_Cfg/output/generated/soc/j721e/mcu1_0/include/Can_Cfg.hCAN_TX_ONLY_MODE 启用 TX-only 模式（与 RX-only 模式相比）。选项是“STD_ON”或“STD_OFF”。 CAN TX only 配置存在于 coresdk_rtos_jacinto_xx_yy_xx_bb/mcusw/mcuss_demos/boot_app_mcu_rtos/can_resp.h（如果使用 CAN 响应任务）和 mcuss_demos/boot_app_mcu_rtos/can_profile.h（如果使用 CAN Profile 任务）

2、 Use first instance of CAN外设只使用配置的CAN外设的第一个实例（MCU_MCAN0）来节省启动时间。下面是配置。

APP_INSTANCE_1_INST_IN_CFG_ONLY 仅使用 CAN 外设的第一个实例。选项是“STD_ON”或“STD_OFF”。 CAN 配置存在于 coresdk_rtos_jacinto_xx_yy_xx_bb/mcusw/mcuss_demos/boot_app_mcu_rtos/can_resp.h（如果使用 CAN 响应任务）和 mcuss_demos/boot_app_mcu_rtos/can_profile.h（如果使用 CAN Profile 任务）

3、在 CAN 响应之前禁用早期打印在测试早期 CAN 响应时，重要的是禁用在 CAN 响应实际开始之前可能需要额外时间的任何早期打印。下面是配置。

CAN_INITIAL_PRINT_DISABLE_BEFORE_CAN_RESPONSE 启用此标志以最小化由于早期打印导致的延迟（禁用早期打印）。选项是“STD_ON”或“STD_OFF”。 CAN 早期打印配置存在于 coresdk_rtos_jacinto_xx_yy_xx_bb/mcusw/mcuss_demos/boot_app_mcu_rtos/can_resp.h（如果使用 CAN 响应任务）和 mcuss_demos/boot_app_mcu_rtos/can_profile.h（如果使用 CAN Profile 任务）

构建依赖二进制文件

我们需要从 coresdk_rtos_jacinto_xx_yy_xx_bb 构建以下二进制文件：

sbl_cust_img 加载 SYSFW 并初始化 OSPI 闪存。当使用带有 BOOTMODE=“ospi” 的 MCUSW Boot App 时使用此 SBL。
sbl_mmcsd 加载 SYSFW，初始化电路板，并将 MCUSW Boot App 映像从 SD 卡复制到 DDR 内存。当使用带有 BOOTMODE=“mmcsd” 的 MCUSW Boot App 时使用此 SBL。

除了上述二进制文件，我们还需要构建 SBL 从 OSPI 闪存或 SD 卡复制的 can_boot_app_mcu_rtos，并执行以下操作：

CAN环回/传输
启动可用的主域内核：MPU1_0、MCU2_0、MCU2_1、MCU3_0、MCU3_1、C66X_0、C66X_1、C7X_0

Building sbl_cust_img

转到 coresdk_rtos_jacinto_xx_yy_xx_bb/pdk_jacinto_07.x.x/packages/ti/build 并运行以下命令：

make -j BOARD=j721e_evm CORE=mcu1_0 BUILD_PROFILE=release sbl_cust_img

注意：对于具有最快启动时间的早期 CAN 响应（启用无打印），您可以在构建 sbl_cust_img 之前通过修改文件 coresdk_rtos_jacinto_xx_yy_xx_bb/pdk_jacinto_07.xx/packages/ti/ti/pdk_jacinto_07.xx/packages/ti/中的 CUST_SBL_TEST_FLAGS 预先配置 SBL 标志 sbl_component.mk。只需搜索这一行并取消注释（并注释掉上面类似的行），然后保存并构建 sbl_cust_img：

#CUST_SBL_TEST_FLAGS =" -DSBL_USE_DMA=0 -DSBL_LOG_LEVEL=1 -DSBL_SCRATCH_MEM_START=0x41cc0000 -DSBL_SCRATCH_MEM_SIZE=0x40000 -DSBL_ENABLE_PLL -DSBL_ENABLE_CLOCKS -DSBL_SKIP_MCU_RESET -DBOOT_OSPI -DSBL_ENABLE_DEV_GRP_MCU -DSBL_HLOS_OWNS_FLASH -DSBL_SKIP_PINMUX_ENABLE -DSBL_SKIP_LATE_INIT -DSBL_USE_MCU_DOMAIN_ONLY"

Building sbl_mmcsd_img

Go to coresdk_rtos_jacinto_xx_yy_xx_bb/pdk_jacinto_07.x.x/packages/ti/build and run the following:

make -j BOARD=j721e_evm CORE=mcu1_0 BUILD_PROFILE=release sbl_mmcsd_img

Building can_boot_app_mcu_rtos

Go to coresdk_rtos_jacinto_xx_yy_xx_bb/mcusw/build and run the following:

make -s -j can_boot_app_mcu_rtos BOARD=j721e_evm SOC=j721e BUILD_PROFILE=release CORE=mcu1_0 BUILD_OS_TYPE=tirtos

默认模式为 OSPI 启动和 CAN 快速响应，所有主域内核都加载了 TI RTOS 映像。

还支持的一些常见配置包括：

对于早期 CAN 响应测量（无打印，无内核启动）：

make -s -j can_boot_app_mcu_rtos BOOTFUNC=disabled BOARD=j721e_evm SOC=j721e BUILD_PROFILE=release CORE=mcu1_0 BUILD_OS_TYPE=tirtos MCUSW_UART_ENABLE=false

从 MMCSD 启动 TI RTOS 映像（主域内核的所有 TI RTOS 映像）：

make -s -j can_boot_app_mcu_rtos BOOTMODE=mmcsd BOARD=j721e_evm SOC=j721e BUILD_PROFILE=release CORE=mcu1_0 BUILD_OS_TYPE=tirtos

使用其他主域内核上的 TI RTOS 映像在 MPU1_0 上启动 HLOS（OSPI 模式）：

make -s -j can_boot_app_mcu_rtos HLOSBOOT=linux BOARD=j721e_evm SOC=j721e BUILD_PROFILE=release CORE=mcu1_0 BUILD_OS_TYPE=tirtos
make -s -j can_boot_app_mcu_rtos HLOSBOOT=qnx BOARD=j721e_evm SOC=j721e BUILD_PROFILE=release CORE=mcu1_0 BUILD_OS_TYPE=tirtos

使用其他主域内核上的 TI RTOS 映像在 MPU1_0 上启动 HLOS（MMCSD 模式）：

make -s -j can_boot_app_mcu_rtos HLOSBOOT=linux BOOTMODE=mmcsd BOARD=j721e_evm SOC=j721e BUILD_PROFILE=release CORE=mcu1_0 BUILD_OS_TYPE=tirtos
make -s -j can_boot_app_mcu_rtos HLOSBOOT=qnx BOOTMODE=mmcsd BOARD=j721e_evm SOC=j721e BUILD_PROFILE=release CORE=mcu1_0 BUILD_OS_TYPE=tirtos

输出的 appimage “can_boot_app_mcu_rtos_mcu1_0_release.appimage” 将被放置在 coresdk_rtos_jacinto_xx_yy_xx_bb/mcusw/binary/can_boot_app_mcu_rtos/bin/j721e_evm 目录中。

Building main domain applications

为主域核心创建 RTOS appimage

转到 coresdk_rtos_jacinto_xx_yy_xx_bb/mcusw/mcuss_demos/boot_app_mcu_rtos/main_domain_apps/scripts 并运行以下命令：./makemulticore.sh

在为每个主域核心构建所有二进制文件后，该脚本调用constructappimage_multistage.sh 脚本来构建用于加载主域核心的主域appimage 文件，分为三个独立的阶段。
MCUSW 引导应用程序将使用多阶段 appimage 文件来加载主域核心。
- 输出的appimage文件“multicore_MCU2_0_MCU2_1_stage1.appimage”、“multicore_DSPs_MCU3_0_MCU3_1_stage2.appimage”和“multicore_MPU1_0_stage3.appimage”将被放置在coresdk_rtos_jacinto_xx_yy_xx/boots_mains_appimage/binary_apps/binary_mains_apps/binary_apps/binary_mains_appj/bind_mains_apps/binary_apps/binary_apps/binary_mains_apps/binary_apps/binary_boots_appimage/binary_mains_apps_mains_appimage_appimage_appimage目录下。
以下内核：MPU1_0、MCU2_0、MCU2_1、MCU3_0、MCU3_1、C66X_0、C66X_1、C7X_0。

还有一个单独的脚本，constructappimage_singlestage.sh，如果需要在单个阶段加载所有主域内核，它可用于将所有核心图像组合到一个应用程序图像文件“multicore_split_with_DSPs.appimage”中。这个appimage的内容可以通过对脚本的轻微修改来定制。此脚本包含主域中最有可能的 appimage 情况的一些变量：

1、mpu_rtos_enabled - 该标志控制appimage是否包含MPU1_0二进制文件。默认情况下，此标志已设置，因此包括示例 RTOS MPU1_0 应用程序。如果 MPU1_0 上需要 Linux 或 QNX，则应将此标志设置为 0，然后重新运行constructappimage.sh。
2、split_mode - 该标志控制主 MCU 是否在拆分模式下运行。如果设置为 0，则 MCU2_1 和 MCU3_1 图像将被排除在 appimage 之外。请注意，禁用此标志时，生成的输出的名称会发生变化。
3、dsp_binaries_included - 此标志控制是否包含 C66 和 C7 DSP 二进制文件。请注意，禁用此标志时，生成的输出的名称会发生变化。

使用其他二进制文件来制定主域应用程序镜像

请注意，constructappimage_multistage.sh 或constructappimage_singlestage.sh 均可用于在每个核心上使用其他二进制文件来制定主域应用程序镜像。可以简单地将这些 ELF 映像复制到 mcuss_demos/boot_app_mcu_rtos/main_domain_apps/binary/bin/j721e_evm 目录，然后在运行脚本之前修改脚本中的 ElfImages、CoreRprcFiles 和 CoreIds 数组。

为 Linux 或 QNX 创建 HLOS 应用程序镜像

在 Linux/QNX 在 MPU1_0 上启动的常见替代情况下，应遵循以下步骤：

1、重建 can_boot_app_mcu_rtos 镜像，HLOSBOOT 标志设置为“linux”或“qnx”，如构建 can_boot_app_mcu_rtos 部分所述。

2、进入 coresdk_rtos_jacinto_xx_yy_xx_bb/mcusw/mcuss_demos/boot_app_mcu_rtos/main_domain_apps/scripts/hlos 目录并通过设置“OS”和 Linux 特定或 QNX 特定路径来编辑constructappimageshlos.sh 以匹配您的设置。这假设已经创建了 Linux/QNX 二进制文件，因为此脚本仅基于这些已创建的 HLOS 二进制文件创建应用程序图像。

3、修改constructappimageshlos.sh脚本中的自定义变量后，运行该脚本。如果运行正确，coresdk_rtos_jacinto_xx_yy_xx_bb/mcusw/mcuss_demos/boot_app_mcu_rtos/main_domain_apps/binary/bin/j721e_evm 目录现在应该包含以下文件：

对于 Linux - atf_optee.appimage、tidtb_linux.appimage 和 tikernelimage_linux.appimage
对于 QNX - atf_optee.appimage 和 ifs_qnx.appimage

4、注意：为了启动剩余的 MAIN 域内核（A72 除外），您可以简单地重用在二进制文件中先前步骤中构建的 RTOS 映像：“multicore_MCU2_0_MCU2_1_stage1.appimage”和“multicore_DSPs_MCU3_0_MCU3_1_stage2.appimage”

运行步骤

Writing needed binaries to OSPI

要在所有主域内核上运行默认的 TI RTOS 应用程序，请在 OSPI 存储器中以各自的偏移量（十六进制）闪存以下二进制文件，如下所示：

coresdk_rtos_jacinto_xx_yy_xx_bb/pdk_jacinto_07.x.x/packages/ti/boot/sbl/binary/j721e_evm/cust/bin/sbl_cust_img_mcu1_0_release.tiimage @ 0coresdk_rtos_jacinto_xx_yy_xx_bb/pdk_jacinto_07.x.x/packages/ti/drv/sciclient/soc/V1/sysfw.bin @ 40000coresdk_rtos_jacinto_xx_yy_xx_bb/mcusw/binary/can_boot_app_mcu_rtos/bin/j721e_evm/can_boot_app_mcu_rtos_mcu1_0_release.appimage @ a0000coresdk_rtos_jacinto_xx_yy_xx_bb/mcusw/mcuss_demos/boot_app_mcu_rtos/main_domain_apps/binary/bin/j721e_evm/multicore_MCU2_0_MCU2_1_stage1.appimage @ 1800000coresdk_rtos_jacinto_xx_yy_xx_bb/mcusw/mcuss_demos/boot_app_mcu_rtos/main_domain_apps/binary/bin/j721e_evm/multicore_DSPs_MCU3_0_MCU3_1_stage2.appimage @ 2400000coresdk_rtos_jacinto_xx_yy_xx_bb/mcusw/mcuss_demos/boot_app_mcu_rtos/main_domain_apps/binary/bin/j721e_evm/multicore_MPU1_0_stage3.appimage @ 3200000

要在 MPU1_0 上启动 Linux（同时仍在其他主域内核上启动 TI RTOS 应用程序），还要在 OSPI 存储器中以各自的偏移量（十六进制）闪存以下二进制文件：

coresdk_rtos_jacinto_xx_yy_xx_bb/mcusw/mcuss_demos/boot_app_mcu_rtos/main_domain_apps/binary/bin/j721e_evm/atf_optee.appimage @ e0000coresdk_rtos_jacinto_xx_yy_xx_bb/mcusw/mcuss_demos/boot_app_mcu_rtos/main_domain_apps/binary/bin/j721e_evm/tidtb_linux.appimage @ 16c0000coresdk_rtos_jacinto_xx_yy_xx_bb/mcusw/mcuss_demos/boot_app_mcu_rtos/main_domain_apps/binary/bin/j721e_evm/tikernelimage_linux.appimage @ 6c0000

要在 MPU1_0 上启动 QNX（同时仍在其他主域内核上启动 TI RTOS 应用程序），还要在 OSPI 存储器中以各自的偏移量（十六进制）闪存以下二进制文件：

coresdk_rtos_jacinto_xx_yy_xx_bb/mcusw/mcuss_demos/boot_app_mcu_rtos/main_domain_apps/binary/bin/j721e_evm/atf_optee.appimage @ e0000coresdk_rtos_jacinto_xx_yy_xx_bb/mcusw/mcuss_demos/boot_app_mcu_rtos/main_domain_apps/binary/bin/j721e_evm/ifs_qnx.appimage @ 6c0000

请注意，对于 Linux/QNX 二进制文件，还需要重建 can_boot_app_mcu_rtos_mcu1_0_release.appimage，如为 Linux 或 QNX 创建 HLOS 应用程序中所述，并重新下载到上面指定的 OSPI 位置。为了启动剩余的 MAIN 域内核（A72 除外），您可以简单地重用在二进制文件的早期步骤中构建的 RTOS 映像：“multicore_MCU2_0_MCU2_1_stage1.appimage”和“multicore_DSPs_MCU3_0_MCU3_1_stage2.appimage”。

Writing needed binaries to MMCSD

要在所有主域内核上运行默认的 TI RTOS 应用程序，请将以下二进制文件复制到 MMCSD 卡上：

coresdk_rtos_jacinto_xx_yy_xx_bb/pdk_jacinto_07.x.x/packages/ti/boot/sbl/binary/j721e_evm/cust/bin/sbl_mmcsd_img_mcu1_0_release.tiimage，重命名为tiboot3.bin
coresdk_rtos_jacinto_xx_yy_xx_bb/pdk_jacinto_07.x.x/packages/ti/drv/sciclient/soc/V1/sysfw.bin
coresdk_rtos_jacinto_xx_yy_xx_bb/mcusw/binary/can_boot_app_mcu_rtos/bin/j721e_evm/can_boot_app_mcu_rtos_mcu1_0_release.appimage，重命名为app
coresdk_rtos_jacinto_xx_yy_xx_bb/mcusw/mcuss_demos/boot_app_mcu_rtos/main_domain_apps/binary/bin/j721e_evm/multicore_MCU2_0_MCU2_1_stage1.appimage，重命名为lateapp1
coresdk_rtos_jacinto_xx_yy_xx_bb/mcusw/mcuss_demos/boot_app_mcu_rtos/main_domain_apps/binary/bin/j721e_evm/multicore_DSPs_MCU3_0_MCU3_1_stage2.appimage，重命名为lateapp2
coresdk_rtos_jacinto_xx_yy_xx_bb/mcusw/mcuss_demos/boot_app_mcu_rtos/main_domain_apps/binary/bin/j721e_evm/multicore_MPU1_0_stage3.appimage，重命名为lateapp3

要在 MPU1_0 上启动 Linux（同时仍在其他主域内核上启动 TI RTOS 应用程序），还要将以下二进制文件复制到 MMCSD 卡上：

coresdk_rtos_jacinto_xx_yy_xx_bb/mcusw/mcuss_demos/boot_app_mcu_rtos/main_domain_apps/binary/bin/j721e_evm/atf_optee.appimage
coresdk_rtos_jacinto_xx_yy_xx_bb/mcusw/mcuss_demos/boot_app_mcu_rtos/main_domain_apps/binary/bin/j721e_evm/tidtb_linux.appimage
coresdk_rtos_jacinto_xx_yy_xx_bb/mcusw/mcuss_demos/boot_app_mcu_rtos/main_domain_apps/binary/bin/j721e_evm/tikernelimage_linux.appimage

要在 MPU1_0 上启动 QNX（同时仍在其他主域内核上启动 TI RTOS 应用程序），还要将以下二进制文件复制到 MMCSD 卡上：

coresdk_rtos_jacinto_xx_yy_xx_bb/mcusw/mcuss_demos/boot_app_mcu_rtos/main_domain_apps/binary/bin/j721e_evm/atf_optee.appimage
coresdk_rtos_jacinto_xx_yy_xx_bb/mcusw/mcuss_demos/boot_app_mcu_rtos/main_domain_apps/binary/bin/j721e_evm/ifs_qnx.appimage

请注意，对于 Linux/QNX 二进制文件，还需要重建 can_boot_app_mcu_rtos_mcu1_0_release.appimage，如为 Linux 或 QNX 创建 HLOS 应用程序中所述，并再次复制到 MMCSD 卡。为了启动剩余的 MAIN 域内核（A72 除外），您可以简单地重用在二进制文件的早期步骤中构建的 RTOS 映像：“multicore_MCU2_0_MCU2_1_stage1.appimage”和“multicore_DSPs_MCU3_0_MCU3_1_stage2.appimage”。

运行演示

1、确保按照 (J721E EVM MMC/SD Boot Mode) 或 (J721E EVM OSPI Boot Mode) 中所述配置 EVM 的引导模式

2、用于演示应用程序日志/消息的 UART/控制台

J721E EVM 有 2 个 UART 端口
当演示应用程序托管在 MCU R5F（例如 MCU1_0）上时，将使用名为 MCU UART 的 UART 端口
当演示应用程序托管在 MAIN R5F（例如 MCU2_1 等）上时，将使用名为 UART 的 UART 端口
请参阅 (J721E EVM) 处的 EVM 图像

3、在 MCU UART 端口 (J43) <> 主机 PC 和主 UART 端口 (J44) <> 主机 PC 之间连接两条单独的微型 USB 电缆

4、在主机 PC 上配置串行控制台应用程序的两个单独实例，以分别使用 MCU UART 端口、通道 #2（即第二个 UART 实例）和主 UART 端口、通道 #2（即第四个 UART 实例）。对于每个实例，使用“115200 8N1”配置。

如果还要测试 Linux/QNX 启动，还需要使用类似的“115200 8N1”配置配置主 UART 端口、通道 #1（即第三个 UART 实例）。

5、打开电路板并确认串行控制台上的引导日志

应用程序完成后，UART 日志包含在以下 UART 端口中：

 MCU UART 端口，通道 #2（即第二个 UART 实例）- MCU R5F CAN 启动应用程序日志主 UART 端口，通道 #1（即第三个 UART 实例）- Linux/QNX 引导日志（仅当启用了 Linux/QNX 构建时）主 UART 端口，通道 #2（即第四个 UART 实例）- 主域 RTOS 应用程序日志

已知的问题

当前版本：psdk_rtos_auto_j7_07_00_00_11-ALL 当前，由于 Linux 内核和用于构建 SBL 引导加载程序的 board_data 默认值（PDK 中使用的 board_data 配置）之间的 Sciclient board_data 配置期望不同，因此在 MPU1_0 上启动 Linux 未完成启动。（新版本已解决）

从 MMCSD 在 MPU1_0 上启动 QNX 时，IFS (QNX) 映像的读取未针对 MMCSD 进行优化。因此，QNX 的启动可能要等到 MCUSW CAN Boot App 启动后大约 8-10 秒才会发生。请注意，我们鼓励客户使用 OSPI 启动媒体来获得最佳启动时间。

【TDA4系列】通过MCU域的R5F1_0启动全部核心MAIN域核心（R5F DSP A73）