[参考译文] AM625-Q1：OSPI NOR SBL 引导在启动期间需要很长时间

尊敬的 Tony：

你能否让我知道这个时间戳是如何拍摄的、用什么计时器来拍摄这些时间戳？

它们太长了、在哪里花费的时间？ 如何优化启动时间？

我假设您只想优化该内核启动时间、而不是总体启动时间、请确认相同的时间。

[报价 userid=“35100" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1541549/am625-q1-ospi-nor-sbl-boot-takes-too-long-during-startup

在第 1 阶段：loadifage2 和启动时间：63ms 到 233ms。

在第 2 阶段：迁移：A53_0_0 和启动：A53_0_0：325ms 至 572ms。

[/报价]

您似乎正在根据 hello world 被打印到 UART 终端的时间来占用这些时间戳、对于 A53 内核、ATF 软件在 freertos/nortos 应用程序执行之前运行： AM62x MCU+ SDK：了解 A53 的 ATF 集成流程

在默认 SBL OSPI 示例中、首先使用 App_loadA53Images API 将所有映像加载到存储器中、然后使用 Bootloader_runCpu API 启动（从复位释放）内核： mcupsdk-core-k3/examples/drivers/boot/sbl_ospi_multistage2/am62x-sk3/cupask3-main-coresk3/r5fssc_cnortosc_cnosc-coresk3-main.c ··

我不确定这会对时序产生多大的影响、但您可以 在 App_loadA53Images  执行完毕后不久尝试调用此 App_runA53Cpu、至少对于 A53 应用程序映像、对于 DM R5、您必须小心、因为您首先应该加载每个其他代码、从复位 Bootloader_Jump 状态中释放它们、然后只执行到 DM R5 应用程序的跳转、这就是在 SelCpu 被调用的原因：  k3_main TexasInstruments/mcupsdk-core-k3··GitHub 上的 mcupsdk-core-k3/examples/drivers/boot/sbl_ospi_multistage/sbl_ospi_stage2/am62x-sk/r5fss0-0_nortos/main.c

此致、

会面。

大家好、

这个问题是由 Tony 代表我提交的。 因此、我现在回答你的以下问题：

[报价 userid=“628103" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1541549/am625-q1-ospi-nor-sbl-boot-takes-too-long-during-startup/5933662

你能否让我知道这个时间戳是如何拍摄的、用什么计时器来拍摄这些时间戳？

唐英年说：

他们太长了,时间花在哪里? 如何优化启动时间？

[/报价]

该时间戳是串行端口调试工具接收数据时的内置时间戳。 它表示 PC 上的当前时间。

[报价 userid=“628103" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1541549/am625-q1-ospi-nor-sbl-boot-takes-too-long-during-startup/5933662

我假设您只想优化该内核启动时间、而不是总体启动时间、请确认相同的时间。

唐英年说：

在第 1 阶段：loadifage2 和启动时间：63ms 到 233ms。

在第 2 阶段：迁移：A53_0_0 和启动：A53_0_0：325ms 至 572ms。

[/报价]

我的目标是：优化 A53 内核和 R5 内核的启动时间。  关于问题中的两段时间,我不知道我现在在哪里花。 它们太长了、我想知道是否可以优化它们。

在这种情况下、您可以尝试上一回答中建议的解决方案：

]我不确定这会对时序产生多大影响、但您可以 在 App_runA53Cpu  执行完毕后立即尝试调用此 App_runA53Cpu、至少对于 A53 应用程序映像、对于 DM R5、您必须小心、因为首先应该加载所有其他代码、将它们从重置状态释放到应用程序跳转、然后仅执行 DM R5、 这就是您看到 SelfCpu 在末尾被调用的原因：mcupsdk-core-k3/examples/drivers/boot/sbl_ospi_multistation/sbl_ospi_stage2/am62x-sk/r5fss0-0_nortos/main.c 处的 k3_main Bootloader_Jump TexasInstruments/msdk-core-k3[Cupquote] ··

请注意、我之前提到过、您要记下打印 hello world 的时间戳、而不是内核实际开始执行的时间、在执行应用之前、ATF 也会执行。

大家好、

您正在记录打印 hello world 的时间戳、而不是内核实际开始执行的时间、在应用程序执行之前、ATF 也会执行。

Hello world 是一个简单示例、我们的最终目标是在 300ms 内实现输出显示、是否存在标记 Hello world 以标记启动时间的问题？ 我们关心整个启动时间、现在启动时间太长了、我们弄清楚启动时间最长、您需要解释原因吗？

根据我对您的建议的理解、我们会得出以下测试结果：从启动内核到运行（释放复位）内核的大部分时间。

更多问题：

1.我应该用什么测试方法和测试用例来验证 A53 和 R5 内核的实际启动时间?

2. ATF 必须存在吗?  如果是、是否必须在运行应用程序之前执行 ATF？

#3. 有指南说明了如何从 makefile 禁用 ATF、可以在 CCS 中禁用 ATF？

3.是否有一个基于 SBL 的引导时间基准可供参考,当你自己做的时候,你会回答自己很多问题。  

由 Tony Tang 更新。

您好、

我假设您的目标是减少在 UART 终端上打印 hello_world/显示某些内容所需的总时间、而不仅仅是启动时间、请确认相同的时间。  

我应该使用哪些测试方法和测试用例来验证 A53 和 R5 内核的实际启动时间？

您可以在 SBL 中配置一个 GPIO 引脚并切换该引脚以标记应用程序中的不同时间戳、例如、在调用 API App_runA53Cpu 之前将该引脚设置为高电平、然后在 A53 应用程序中将该引脚设置为低电平。 该引脚保持的时间量应该表示从  App_runA53Cpu 到应用程序开始运行的时间。 请尝试使用直接寄存器写入来切换引脚、以避免 API 调用引起任何延迟。

我还建议使用释放模式二进制文件而不是调试二进制文件、因为使用 CCS 调试二进制文件时默认会生成。

[报价 userid=“525560" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1541549/am625-q1-ospi-nor-sbl-boot-takes-too-long-during-startup/5933819

2. ATF 必须存在吗?  如果是、是否必须在运行应用程序之前执行 ATF？

#3. 有指南说明了如何从 makefile 禁用 ATF、可以在 CCS 中禁用 ATF？

[/报价]

实际上、不建议从应用程序中删除 ATF。

[quote userid=“525560" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1541549/am625-q1-ospi-nor-sbl-boot-takes-too-long-during-startup/5933819 是否有基于 SBL 的引导时间基准可供参考、您将自行回答许多问题。  [/报价]

这里的数据表中记录了一些 SBL 基准测试以供参考： AM62x MCU+ SDK：数据表

另请注意、加载图像所需的时间也取决于图像的大小。

我们尚未对   从 App_runA53Cpu 到在 UART 上打印某些内容所需的时间进行基准测试、A53 内核在从复位中释放第一条指令（在本例中为 ATF/bl31_entrypoint）后立即开始执行第一条指令。

此致、

会面。

尊敬的会议：  

您专注于如何获得准确的时间、我们讨论的是几百毫秒的时间花费、而不是 UART 打印花费的额外时间、Linux 系统还会将日志输出到 UART 控制台。  

我们尚未对从 App_runA53Cpu 到在 UART 上打印某些内容所需的时间进行基准测试、 那就是 A53 内核在从复位中释放第一条指令（在本例中为 ATF/bl31_entrypoint）后立即开始执行第一条指令。

A53 将开始执行第一条指令、但需要等待 R5 DMSC 运行、设置 sci sever、然后才能运行。 时间应该花在那里,我们需要你帮助,以了解如何和为什么这么长的花费,以及如何优化。

尊敬的 Tony：

您关注的是如何获得精确的时间

抱歉、如果有任何混淆、但我的回答是回答客户的此问题：  

我应该使用哪些测试方法和测试用例来验证 A53 和 R5 内核的实际启动时间？

我也不能确定这种使用所述 UART 工具记录时间戳的方法有多可靠。

A53 将开始执行第一条指令、但需要等待 R5 DMSC 运行、设置 sci sever 之类的内容、然后才能运行。

对的、感谢您指出这一点。 为此、 在 R5 内核上运行的 DM 应用程序中调用 sciServer_init、之后 A53 应用程序应该能够继续运行。 但该时间将基于阶段 1 和阶段 2 SBL 所用的总时间。 SBL 完成执行后、DM 固件将在 R5 内核上运行并初始化 SciServer、这些时序在我们这边不会测试、因此我们不能提供参考时序、但我怀疑这会花费很长时间、这次不能进行优化、因为您必须等待 DM 应用程序引导才能有任何其他内核启动其应用程序。

您好、认识：

：是添加了时间戳的 UART 打印日志、这是测量输出日志时间的常用工具/方法 μ s

e2e.ti.com/.../2025_5F00_07_5F00_22_2D00_19_5F00_18_5F00_45_5F00_Auto_5F00_uart_5F00_raw_5F00_data-_2800_1_2900_.txt

您可以参考前面突出显示的红色文本以了解打印信息：

 启动时间过长、启动过程中的阶段过多、每一个需要几毫秒、我们需要您帮助了解如何 减少时间。  

尊敬的 Zegeng：

感谢您提供这些详细的日志、我将尝试分析哪些部件可能需要更长的执行时间、以及是否有任何空间来优化这些部件。 从我们之前的讨论中、我假设您的最终目标是完成 SBL 阶段和 A53 应用程序的执行并在 300ms 内将 hello world 打印到 UART 终端、根据我将尝试检查是否可以实现该时序、请确认我的理解是否正确。

请确认您是在调试模式还是释放模式下编译二进制文件？ 如果您使用的是调试模式、请尝试使用释放模式二进制文件一次。 以下是 SBL OSPI 的编号、也未在 MCU+SDK 数据表： AM62x MCU+ SDK：数据表、在您针对 SBL OSPI NOR（针对定制电路板）分享的第一个屏幕截图中、我看到这些时序与 MCU+SDK 数据表中的数字不匹配、因此我怀疑您可能要使用调试二进制文件进行测试。

大家好、

请确认您是在调试模式还是释放模式下编译二进制文件？ 如果您使用的是调试模式、请尝试使用释放模式二进制文件一次。 [/报价]

非常感谢您的提醒。 我们之前确实在调试模式下使用了二进制文件。 下面是我们在释放模式下使用二进制文件获得的串行端口日志数据。 与调试模式相比减少的时间约为 100 毫秒。 请查看此日志进行分析。

e2e.ti.com/.../teraterm_5F00_250723140438.log 

在我们之前的讨论中、我假设您的最终目标是完成 SBL 阶段和 A53 应用程序的执行、并在 300ms 内将 hello world 打印到 UART 终端

Hello world 是一个简单示例、我们的最终目标是 在 300ms 内完成 SBL 阶段和 A53 应用程序和输出显示的执行。 我认为、此时您可以根据您目前的理解继续、帮助我们评估是否可以达到这一时间要求。

 

更多问题：

如果我们不使用 HSM、可以去掉 1 级吗？ 如果是、请告诉我们如何操作？

[/quote]

尊敬的 Zegeng：

无法删除 SBL 阶段 1。  (https://software-dl.ti.com/mcu-plus-sdk/esd/AM62X/11_01_00_16/exports/docs/api_guide_am62x/EXAMPLES_DRIVERS_SBL_OSPI_NAND_LINUX_MULTISTAGE.html#autotoc_md1417)

问题 1：SBL stage1 初始化 DDR。 然后、可以将 stage2 加载到 DDR 并运行。 如果您要删除 stage1 处的 HSM、您需要修改 SBL 源代码、请试用。 相信这项工作并不容易。

我验证了 SK-AM62x-LP EVM 板 OSPI NAND 启动性能、您可以在 EVM 板上找到以下结果。 由于 stage2 加载映像与您使用的 hello world 演示不同、因此启动时间与您略有不同、但时间与 RDK11.0 提供的数据表的时间级别相同。 (https://software-dl.ti.com/mcu-plus-sdk/esd/AM62X/11_01_00_16/exports/docs/api_guide_am62x/DATASHEET_AM62X_EVM.html#autotoc_md211)

stage1 使用 77.3ms 运行、stage2 使用 61.8ms。 从第一行输出  15：46：59.510] SYSFW 固件版本 11.0.7 到[SYSFW 2025年07月24日 15：46：59.782]图像加载完成、它使用了 272ms、结果相同。

e2e.ti.com/.../AM62_2D00_lp.txt

我们将与研发部门一起检查如何优化 272ms stage1+stage2 启动时间。

对于您的应用而言、300ms 显示屏 CAN 输出非常困难。 我们在 AM62x 上的快速显示体验需要~1.21 秒。 以下是引导方法。

stage1 -> stage2 -> uboot。  

显示图像是 静态 BMP 文件。

此致！

Han Tao

尊敬的会议：

正如在 Webex 上讨论过的、客户不使用 HSM。 需要您的指南将引导至应用程序/A53 的阶段减少到一个。 有两级冗余、这是不必要的。  

尊敬的 Tony、Zegeng：

引导加载程序的第一阶段必须从 HSM RAM 运行、因此无法使用此引导流程加载 HSM 应用程序、因此不能直接移除第 1 阶段。 为此、您必须将两个阶段合并为单个引导加载程序应用程序。  

为此、您必须在 stage-1 中的 syscfg 中为 A53 映像添加额外的引导加载程序实例、并且还必须添加加载这些映像的代码、您可以将该代码从 stage-2 复制到 stage-1。 此外、您必须为 R5 加载应用程序映像、而不是在 stage-1 中将 SBL stage-2 映像加载到 R5 上。 在数据表编号末尾建议执行一些其他优化步骤：

如果您检查时间戳、那么打印这么多日志似乎也需要一些时间、您现在可以删除 bootloader_profile 日志、并查看您可以通过此实现多少优化。

此致、

会面。  

见面、

#1。 它是专用 e2e、客户无法访问。

#2. 我看了那篇文章,没有找到详细的说明。  几乎与较高内容相同。 详细步骤会有所帮助。

#3. 为什么 stage-1 必须在 HSM RAM 上运行？ HSM RAM 是否为 256KB SMS 子系统？

#4. 可以更改为其他片上 RAM 空间？ 如 M4F、  

尊敬的 Tony：

[报价 userid=“35100" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1541549/am625-q1-ospi-nor-sbl-boot-takes-too-long-during-startup/5944026 ]我看了那篇文章,没有找到详细说明。  几乎与较高内容相同。 详细步骤将有所帮助。

您可以按照我在上一个答复中提到的步骤操作：

- 在第 1 阶段的 syscfg 中为 A53 映像添加额外的引导加载程序实例,对于 R5 内核,加载 DM 应用程序而不是 SBL 第 2 阶段:

-您还必须添加加载这些图像的代码,您可以将相同的代码从 stage-2 复制到 stage-1 :

k3_main TexasInstruments/mcupsdk-core-k3··GitHub 上的 mcupsdk-core-k3/examples/drivers/boot/sbl_ospi_multistage/sbl_ospi_stage2/am62x-sk/r5fss0-0_nortos/main.c

- 我们只有大约 240KB 的 HSMRAM 可用于 SBL ,所以如果您的 SBL appimage 超过此限制,您可能无法加载它。

HSM RAM 是 256KB SMS 子系统吗？

是的

可以更改为其他片上 RAM 空间吗？ 例如 M4F、 [/报价]

这是不可能的、因为  ROM 代码会将 1 级代码加载到 HSM RAM 中、并且不会更改 ROM 代码。

此致、

会面。

尊敬的会议：

客户仅遵循第 1 阶段的诚信指南。 节省了大量时间、但在运行 CPU：A53 和启动之间仍然需要相当长的时间、即~200ms。

#1。 假设它是 ATF 获取的、移除 ATF 可以节省大量时间。

#2. 对于基于 RTOS 的用例、ATF 是必须还是必要的吗？

#3. 这么长时间内它做了什么？

尊敬的 Tony：

实际上不建议删除 ATF、如果客户在 300ms 内运行应用程序的用例得到满足、那么您不应该尝试删除它。

我还认为、这段额外的时间 是由于打印 boot_profile 日志、打印这些日志所需的时间未包括在计算 SBL 总时间时、您还可以根据时间戳估算打印这些日志所需的时间。您是否可以尝试禁用日志并再次检查时序、 评论对以下 API 调用的调用：

你也可以禁用 Sciclient 获取版本 API,这将节省大约 10 毫秒,它似乎不可能进一步优化启动时间,你可以要求他们现在尝试这 2 件事.

此致。

会面。

您好、认识、

我们仅遵循您的完整性指南至第 1 阶段。  以下是串行端口日志数据、runCPU：A53 和启动之间仍然需要相当长的时间、因为这是一个简单的示例、最终示例将更大。 我们需要尽可能进行优化。  

e2e.ti.com/.../teraterm_5F00_250728173938.log

#1。 这么长时间内它做了什么？

确实不建议删除 ATF

#2. 为什么不建议删除 ATF？ MCU SDK10 之前没有 ATF、似乎并非如此。

#3. UART 打印需要一些时间、但很简单、我们可以看到在每条线路上花费的时间、我们可以在最终集成中禁用它。 但现在、请将其保留在此处以供参考。  

[ 2025年07月28日 17：39：41.963]--或非 stage1-–05---
[Flash 2025年07月28日 17：39：41.965] Flash_norOspiOpen ()-start
[ 2025年07月28日 17：39：41.969]
[SYSFW 固件版本 10.1.8--v10.01.08 (Fiery Fox) 2025年07月28日 17:39:41.969]
[SYSFW 17：39：41.977] 2025年07月28日 固件版本 0xA.
[SYSFW ABI 修订版 4.0 2025年07月28日 17：39：41.977]
[ 2025年07月28日 17：39：41.978]

尊敬的 Zegeng：

请参阅以下文档、 了解 ATF 集成流程：AM62x MCU+ SDK：了解 A53 的 ATF 集成流程

如果您要在没有 ATF 的情况下编译应用、则必须将 ATF_integrated_boot 设置为 no、而不是 yes、这将允许您在没有 ATF 的情况下编译应用： mcupsdk-core-k3/examples/hello_world/am62x-sk/a53ss0-0_freertos/gcc-Aarch64/makefile、位于 k3_next TexasInstruments/mcupsdk3-core-k3-k3 ··

在大多数情况下、我认为仍可归因于打印日志、移除 ATF 可以为您节省 20-30ms。  

请检查以下时间戳：

打印这些日志本身大约需要 100ms、请注意、此次不计入 SBL 所用的总时间、如前所述、A53 在 SBL 完成执行且 DM 应用程序开始在 R5 上运行之前无法启动应用程序。 请注意、这将延迟 SBL 完成、并将属性为引导 A53 所需的总时间。  

此致、

会面。

尊敬的 Zegeng：

添加了一些关于在没有 ATF 的情况下在 A53 上运行应用程序的注释。

ATF (Arm Trusted Firmware) 用作所有 K3 平台的 ARMv8-A 内核上的初始启动代码。 这是来自 Arm 的建议顺序、用于：

1.设置初始内核状态

2.应用针对 Arm Cortex A53（来自 Arm）的勘误修复

3.它将自身设置为 EL3 监视器处理程序

https://software-dl.ti.com/processor-sdk-linux/esd/AM62X/latest/exports/docs/linux/Foundational_Components_ATF.html 

在生产系统中、为了克服安全漏洞并确保按照 Arm 的建议遵循 A53 启动时的事件序列、需要执行这些操作。 对于评估、您可以跳过、但对于量产、建议这样做。

此致

Karan