[参考译文] TDA4VM：从 eMMC/ospi 引导 MCU1_0

您好！

[引用 user="Wall-E">我尝试加快 mcu1_0启动时间。 一些文档说我可以将固件写入 ospi 以使用快速启动。[/quot]

我想您在这里指的是 MCUSW boot_app http://downloads.ti.com/jacinto7/esd/processor-sdk-rtos-jacinto7/latest/exports/docs/mcusw/mcal_drv/docs/drv_docs/demo_boot_app_mcu_rtos_top.html 

该应用用于执行早期 CAN 响应。 但 CAN 响应应用(此处为早期用例)不是作为/lib/firmware.的固件运行 它在 boot_app 本身内作为任务运行、而另一个任务引导其他内核。

您看到的是预期的情况、您没有刷写引导应用程序和其他部分、因此您看不到任何内容。

一些问题：

1.在运行 Linux 的同时，是否要加速 MCU1_0的启动？ 还是这是独立用例？

2.您的目标用例是什么？

此致、

Karan

您好、Karan、

感谢您的回复。

1.在运行 Linux 的同时，是否要加速 MCU1_0的启动？ 还是这是独立用例？

是的、它是 RTOS + Linux。但是 MCU1_0 CAN 应用程序不依赖于 Linux。 并且 不需要 Linux 启动时间。

似乎早期的 CAN 响应无法启动 VISION_APPS 生成的.out 文件？ .appimage 和.out 之间有何不同？

2.您的目标用例是什么？

我在 MCU1_0 RTOS 中写入了一些与 CAN 相关的应用程序、该部分应用程序必须在上电后的极短时间(小于100ms)内运行。 但目前、如果从 SD 卡启动、则 mcu1_0的启动时间约为3-4秒。这对我来说太长了。

此致

您好！

[引用 user="Wall-E"]

似乎早期的 CAN 响应无法启动 VISION_APPS 生成的.out 文件？ .appimage 和.out 之间有何不同？

[/报价]

.out 或.xer5f 基本上是 ELF 格式。 另一方面、.appimage 是 RPRC 格式。 您可以在此处找到更多详细信息- http://downloads.ti.com/jacinto7/esd/processor-sdk-rtos-jacinto7/latest/exports/docs/pdk_jacinto_07_00_00/docs/userguide/boot/boot_jacinto.html#image-formats

[引用 user="Wall-E"]

步骤2. 生成我的应用程序。 我的应用代码来自 PSDK_RTOS_auto_J7_07_00_11/vision_apps/apps/basic_demos/app_tirtos/tirtos_linux/mcu1_0。 创建 vision_apps、并将 在 PSDK_RTOS_auto_J7_07_00_00_11/targetfs/lib/firmware 中生成 J7-mcU-r5f0_0-fw

[/报价]

在这种情况下、您尝试使用 SBL 引导/lib/firmware.中的固件 这不奏效。  

因此，让我尝试解释一下，当您使用 SPL 和 u-boot 启动 Linux 时，文件系统中/lib/firmware 中的固件将被拾取并加载到远程内核(R5、C66、C7)上。

引导应用程序(http://downloads.ti.com/jacinto7/esd/processor-sdk-rtos-jacinto7/latest/exports/docs/mcusw/mcal_drv/docs/drv_docs/demo_boot_app_mcu_rtos_top.html )或 CAN 响应应用程序是完全不同的路径，不涉及 SPL 和 u-boot。

因此、您可以通过3种方式运行应用程序：

1. SPL/uboot 方法：将 ELF 格式映像放在/lib/firmware 中、然后 SPL (对于 mcu1_0和 MCU2_0内核)或 u-boot (对于其余内核)将拾取该映像并加载该映像。
2. SBL 方法：使用 SBL、sysfw 和 appimage 格式来引导内核。 借助 SBL、您可以加载所有内核、但无法引导 Linux。
3. 引导应用程序：在此 SBL 中、加载 boot_app、然后 boot_app 有2个任务。 其中一个任务运行 CAN 应用程序、另一个任务引导 Linux。

3人的意图是使 CAN 能够及早作出反应。 但 SDK7.0中存在一个已知问题、即 Linux 无法引导至文件系统(由于资源与 RTOS 内核冲突)。

1主要是针对引导时间进行了大量专用优化、其中的引导时间实际上仅取决于您使用的引导介质。

2也取决于引导介质的选择、但我认为使用 SBL 加载 mcu1_0的速度会更快、因为 SDK 中提供了优化的 SBL (CUST SBL)。

我想我们可以查看您想要实现的用例并确定路线。

此致、

Karan

此致、

Karan

您好、Karan、

我认为第1条路更好。 因为我们必须使用 Linux。而且与其他工具相比、它的实施似乎更容易。

是否是更改引导介质的好方法？ 比如将 SBL/uboot 放入 OSPI 或从 eMMC 引导？ 会更快吗？

实际上、我昨天已经尝试过从 eMMC 引导、它比 SD 卡要长很多。  在出现 Linux 登录窗口之前、无法正常工作

请帮帮我、非常感谢。

此致。

您好、Karan、

我已经厌倦了从 eMMC 启动。 但我发现固件是由内核加载的、而不是 uboot。 它的加载很晚。

我在这里共享完整的引导日志。

/cfs-file/__key/communityserver-discussions-components-files/791/4760.log.txt

为什么要延迟加载 mcu1_0固件？ 为什么内核加载而不是 uboot(或 spl)？

是一种更改加载顺序的方法吗？

谢谢。

此致。

您好！

我们也可以从 SPL 加载 mcu1_0固件。 如果将固件放在 rootfs 分区的/lib/firmware 中并重命名为 j7-mcU-r5f0_0-fw，SPL 将自动加载固件。 我建议您访问常见问题 解答 https://e2e.ti.com/support/processors/f/791/t/915474 、以获得更多了解。

2.您能否告诉我您目前是如何构建 CAN 应用的、即您参考了什么示例？

 PSDK_RTOS_auto_J7_07_00_00_11/mcusw/mcus_demos/profile/CAN 中有一个应用。 此应用程序或 SDK 中的任何其他应用程序都是独立的驱动程序测试、可能与 Linux 有一些冲突(请参阅 https://e2e.ti.com/support/processors/f/791/t/931992)、但我认为通过一些更改、我们可以使其从 SPL 加载。

3.现在，如何确认在 Linux 提示后 CAN 是否正常工作？ 您是否连接了一些外部 CAN 仿真器、以便从 TDA4接收消息？

此致、

Karan

您好、Karan、

我将从中学习。

我将应用程序从"psdk_rtos_auto_j7_06_02_00_21/vision_apps/apps/cockpit_demos/app_tirtos_linux"中引用、我开发其他 CAN 并在其基础上移植新版本的 SDK。

3.启动时，我的应用程序将始终传输 CAN 消息。 我有一个外部 CAN 仿真器来接收 CAN 消息。 当我收到正确的 CAN 消息时、我认为它已经启动。  

谢谢。

此致。

您好！

如果您的应用程序名为 J7-MCU-r5f0_0-FW、则 R5 SPL 将加载该应用程序。  

请参阅下面的启动日志、在启动 ATF 打印之前、您会看到 Remoteproc 2已成功启动、我相信您会看到类似的内容、但 Remoteproc 0已成功启动(我认为您之前没有附加这些打印内容)。 ->请检查您是否看到此内容。

您稍后在内核中看到的内容、即"remoteproc teproproc1：引导 FW 映像 J7-mcU-r5f0_0-fw、大小为174028"、即内核只是连接它。

Remoteproc 2已成功启动
**文件未找到/lib/firmware/j7-mcu-r5f0_0-fw **
正在 ARM64内核上启动 ATF...

注意：BL31：v2.3 ()：07.00.005-脏
通知：BL31：构建时间：14：33：55、2020年6月17

日 U-Boot SPL 2020.01-gf9b0d030d3 (2020年6月17日- 14：34：25 +0000)
SYSFW ABI：3.0 (检测到固件版本0x0014 '20.044.1-v204B-XC-REV
JESI
：检测到极好的 J0X-Je3：
J7X-VSC8514-ETH 修订版 E2
尝试从 MMC2


U-Boot 2020.01-gf9b0d030d3 (2020年6月17日- 14：34：25 +0000)

SoC：J721E SR1.0
模型：德州仪器(TI) K3 J721E SoC
板：J721EX-PM2-rev 800d3 mmc：从 mmc




环境中加载4个字节 mmc 0@@dh dsmc0：b0... 0 mcm 4 mcm mcm 4 mcm dh mcm 4 mcr dh mcm 0：mcr f 4 mcr dh mcr f 4 b
正常输入：串行@2800000
输出：串行@2800000
错误：检测到串行@2800000
：
检测到 J7X-BASE-CPB 修订版 E3：
检测到 J7X-GESI-EXP 修订版 E3：J7X-VSC8514-ETH 修订版 E2
网络：
警告：以太网@046000000使用 ROM 中的 MAC 地址
eth0：以太网@046000000
自动启动任何密钥停止 0
切换到分区#0，好
的，mmc1是当前在
设备上找到的设备 SD/MMC 在
从
uEnv.txt 加载 env 的1ms (53.7 KiB/s)内读取1 55个字节
从 mmc1导入环境...
1513584字节在36ms (40.1 MIB/s)内读取
数据@addr=0x80080000 1513584字节：成功！
1513584字节在37ms (39 MiB/s)内读取
数据加载远程处理器7 (含数据)@addr=0x80000 1513584字节：成功！
9314288字节在73ms (121.7 MIB/s)内读取
数据加载远程处理器8 (含数据)@addr=0x80000 9314288字节：成功！
16654344字节在347 ms (45.8 MIB/s)内读取
89857字节在5 ms (17.1 MIB/s)内读取
1719字节在3 ms (559.6 KB/s)
内读取###平展器件树状引脚在82000000处
使用0x82000000处的 FDT 引脚启动
将器件树加载到00000000fdda1000、结束000000009fdff... 确定

启动内核... 

话虽如此、您也可以尝试一种方法-在 u-boot 处停止(通过在 u-boot 提示符上按任意键)、然后查看您是否能够运行固件(我想它将运行)。 问题可能是加载了固件、但与内核有一定的同步、因此 CAN 任务/函数稍后会执行。 您可以在 u-boot 停止并连接 CCS (不要加载任何 gels)、连接到 MCU1_0 (加载符号)并查看其位置。 这将让您很好地了解事情发生在哪里。

如果您在 u-boot 停止后无法连接(以防万一)、则会出现问题、固件实际上未加载、并且 MCU1_0已关闭。

总结以下步骤：

1.检查我提到的打印内容(ATF 打印之前)。

2.在 u-boot 停止并验证 CAN 功能、何时启动(在本例中不引导至内核)

3. u-boot 停止(不引导至内核)->连接 CCS 并检查 mcu1_0的状态

让我知道上述结果，我们就可以向前迈进。

此致、

Karan

您好、Karan、

让我澄清一下我们的讨论。  

我的目标：让 mcu1_0可以更快地启动应用程序、我希望引导时间小于100ms。

实现方法：

1. SPL/uboot 方法
2. SBL 方法
3. 启动应用程序

由于 way2、way3无法支持 Linux、因此我们选择 Way1。 您说过引导时间由不同的引导介质决定。 因此我尝试 SD 卡引导和 eMMC 引导。(实际上我还尝试过 OSPI 引导、但它不起作用)

因此、调试路线图是：

1.SPL/uboot 方法  --> 1.1 尝试 SD 卡启动

                  --> 1.2 尝试 eMMC 引导

                  -->  1.3 尝试 OSPI 引导(失败)

我测量不同引导介质的引导时间。(可能 不是很高精度)。 测量起始条件：切换 SW2 swith 以打开 TDA4VM EVK 板的电源。 测量停止条件：外部 CAN 仿真器接收来自 TDA4VM 的 CAN 消息。

SD 卡引导：大约3.2秒

eMMC 引导：10秒以上。

我在此附上完整的引导日志(SD 卡和 eMMC)。 在 eMMC 引导日志中，没有“Remoteproc…… 已成功启动"日志。  但它确实出现在 SD 卡引导日志中。

e2e.ti.com/.../sd.loge2e.ti.com/.../emmc.log

最后、我参考您的答案、尝试在 u-boot 处暂停并连接 CCS 以检查 mcu1_0的状态。 此外、还有两种情况：eMMC 引导和 SD 卡引导。

eMMC 引导：

连接到 mcu1_0时出错。 我的 CAN 仿真器未收到 CAN 消息。 似乎 SPL 未加载并启动 mcu1_0。

SD 卡引导：

成功进入我的 CAN 应用程序。 我的 CAN 仿真器接收来自 TDA4VM 的 CAN 消息。

我有一些发现。 从切换 SW2开关到 UART 开始打印的时间、eMMC 短于 SD 卡。 我想、如果有办法让 SPL 加载并在 eMMC 引导模式下启动 mcu1_0、我们可能可以缩短引导时间。

此致。

您好！

[引用 user="Wall-E"] eMMC 引导：超过10秒。

之后是否收到消息？ 尽管您说过、对于 eMMC、您无法加载固件。

1. 此外、从 eMMC 引导时、是否插入了 SD 卡？
2. 您的文件系统是否也位于 eMMC 中？
3. 如何刷写 eMMC？

此外、请查看- e2e.ti.com/.../923930

此致、

Karan

您好、Karan、

之后是否收到消息？ 尽管您说过、对于 eMMC、您无法加载固件。

是的、我的 CAN 仿真器可以接收 CAN 消息。 我认为固件是由内核加载的。

我所说的无法加载固件、我意味着它不是由 SPL 加载的、我认为它是由内核加载的。

此外、从 eMMC 引导时、是否插入了 SD 卡？

否

2.您的文件系统是否也在 eMMC 中？

是的。

如何刷写 eMMC？

我提到这一主题。

https://e2e.ti.com/support/processors/f/791/t/886980?tisearch=e2e-quicksearch&keymatch=emmc%20boot%20switch

https://e2e.ti.com/support/processors/f/791/t/887773

此外、请查看- e2e.ti.com/.../923930

此方法是否在 u-boot 中加载并启动固件？ 我已经尝试过。 仅比从 SD 卡引导快0.4秒。

此致。

您好、Karan、

现在 SPL 可以在 eMMC 引导模式下从 eMMC 加载固件。 我的 CAN 应用程序启动时间减少到大约1.4秒。

我将进行测试、以验证当前引导时间是否足够短、以便与车辆控制器单元握手。  

非常感谢您、Karan。

此致。

您好、Karan、

我已经验证了我与车辆控制器单元的 CAN 应用握手。 遗憾的是、启动时间仍然过长。  

是否有一些方法来优化 eMMC 引导时间？

或其他缩短启动时间的方法？

我将创建一个新主题、以讨论此主题。

此致。

您好！

[引用 user="Wall-E"]我将创建一个新主题，以讨论此主题。

这应该是好的。 (也请在该线程中提及您的 SDK 版本)

同时、我还将尝试通过内部讨论来获取一些信息。

此致、

Karan

您好、Karan、

我创建了一个有关早期 CAN 响应 CAN_BOOT_APP_MCU_RTOS 的新主题。 请检查。

https://e2e.ti.com/support/processors/f/791/t/941104

谢谢。

此致