[参考译文] 如果 SBL 启用 QSPI 闪存&#39；s DMA 模式、则无法保护引导应用程序

尊敬的 Jenny：

您使用的是 TI EVM 还是定制电路板？ 您是在 MCU+SDK 中提供的默认 sbl_ospi 下遇到了此问题、还是进行了任何更改？

此致、

会面。  

尊敬的会议：

我正在使用定制电路板、我正在使用仅具有 DDR 的默认 sbl_ospi、并通过"example.cfg"更改了闪存配置。

还有一个信息是、一切都使用 SDK'mcu_plus_sdk_am64x_10_00_20'运行良好。

看起来就像使用新的 SDK 一样、虽然执行安全启动、但在启用"MMA 时无法读取一些特殊偏移。

您好：

[引述 userid="581907" url="~/support/processors-group/processors/f/processors-forum/1513656/failed-to-secure-boot-application-if-sbl-enable-qspi-flash-s-dma-mode

传输的 TR 响应失败：SRC = 0x61000000、dst = 0x84000000、size = 32

断言：18.407657s：ospi/V0/LLD/DMA/UDMA/ospi_UDMA_LLD.c：OSPI_udmaUpdateSubmitTR：259：false failed！！

[/报价]

对于这些地址、特别是 SRC 地址、感觉不对、因为 OSPI 是映射到地址0x60000000的存储器、因此该地址意味着偏移量为64MB。 至少对于 EVM 来说、这是不正确的、因为它只有64MB 闪存器件。

我刚刚尝试在 EVM 上启动加密的应用程序、成功：

[19:29:41.073] DMSC Firmware Version 11.0.7--v11.00.07 (Fancy Rat)
[19:29:41.080] DMSC Firmware revision 0xb
[19:29:41.082] DMSC ABI revision 4.0

[19:29:41.085] TR Response success for transfer : SRC = 0x60080000, DST = 0x82000000, SIZE = 32
[19:29:41.104] TR Response success for transfer : SRC = 0x60080000, DST = 0x82000000, SIZE = 2048
[19:29:41.110] TR Response success for transfer : SRC = 0x60080000, DST = 0x82000000, SIZE = 32
[19:29:41.114] TR Response success for transfer : SRC = 0x60080000, DST = 0x82000000, SIZE = 64512
[19:29:41.119] TR Response success for transfer : SRC = 0x6008FC00, DST = 0x8200FC00, SIZE = 26496
[19:29:41.156] KPI_DATA: [BOOTLOADER_PROFILE] Boot Media       : NOR SPI FLASH
[19:29:41.174] KPI_DATA: [BOOTLOADER_PROFILE] Boot Media Clock : 166.667 MHz
[19:29:41.177] KPI_DATA: [BOOTLOADER_PROFILE] Boot Image Size  : 86 KB
[19:29:41.189] KPI_DATA: [BOOTLOADER_PROFILE] Cores present    :
[19:29:41.191] r5f0-0
[19:29:41.192] KPI_DATA: [BOOTLOADER PROFILE] SYSFW init                       :      11238us
[19:29:41.196] KPI_DATA: [BOOTLOADER PROFILE] System_init                      :     363766us
[19:29:41.200] KPI_DATA: [BOOTLOADER PROFILE] Drivers_open                     :       1762us
[19:29:41.214] KPI_DATA: [BOOTLOADER PROFILE] Board_driversOpen                :     136033us
[19:29:41.218] KPI_DATA: [BOOTLOADER PROFILE] Sciclient Get Version            :       9992us
[19:29:41.230] KPI_DATA: [BOOTLOADER PROFILE] CPU Load                         :      72632us
[19:29:41.234] KPI_DATA: [BOOTLOADER PROFILE] SBL End                          :       1345us
[19:29:41.246] KPI_DATA: [BOOTLOADER_PROFILE] SBL Total Time Taken             :     596771us

[19:29:41.250] Image loading done, switching to application ...
[19:29:41.253] Hello World!

通过以下补丁启用了其他日志记录：

diff --git a/source/drivers/ospi/v0/lld/dma/udma/ospi_udma_lld.c b/source/drivers/ospi/v0/lld/dma/udma/ospi_udma_lld.c
index ee0da5b3..6e4f15b1 100644
--- a/source/drivers/ospi/v0/lld/dma/udma/ospi_udma_lld.c
+++ b/source/drivers/ospi/v0/lld/dma/udma/ospi_udma_lld.c
@@ -258,6 +258,10 @@ static int32_t OSPI_udmaUpdateSubmitTR(OSPI_UdmaParams *udmaParams, void* dst, v
                 DebugP_log("TR Response failed for transfer : SRC = 0x%X, DST = 0x%X, SIZE = %u\r\n", (uint32_t)src, (uint32_t)dst, length);
                 DebugP_assert(FALSE);
             }
+            else
+            {
+                DebugP_log("TR Response success for transfer : SRC = 0x%X, DST = 0x%X, SIZE = %u\r\n", (uint32_t)src, (uint32_t)dst, length);
+            }
             break;
         }
     }
@@ -339,4 +343,4 @@ int32_t OSPI_udmaItrStatus(OSPI_DmaHandle ospiDmaHandle)
     int32_t status = OSPI_SYSTEM_FAILURE;
     /* UDMA Interrupt TO-DO */
     return status;
-}
\ No newline at end of file
+}

您能否检查您的引导流程并澄清有关这些 SRC 和 DST 地址的不一致之处？

此致、

Prashant

您好 、Prashant、

偏移：0x61000000应该表示闪存的偏移0x01000000、对吗？ 因为在直接读取模式下、闪存数据映射到从0x60000000开始的存储器、对吗？

Unknown 说：

offset：0x61000000、应该表示闪存的偏移0x01000000、对吧？ 因为在直接读取模式下、闪存数据映射到从0x60000000开始的存储器、对吗？

正确。

默认偏移为0x80000、因此日志中的偏移是意外的。

您好、Prashant、

我发现根本原因是一些初始代码的顺序:'system_init (), Bootloader_socOpenFirewalls ()'等 请参阅下面的代码片段。

#if 1 //可以从 SDK：MCU_PLUS_SDK_am64x_11_00_00_15引导//
system_init()；
bootloader_profileAddProfilePoint ("System_init")；

bootloader_socOpenFirewalls()；

bootloader_socNotifyFirewallOpen ();

#else //无法从 SDK：mcu_plus_sdk_am64x_10_00_00_20引导//
bootloader_profileAddProfilePoint ("SYSFW init")；

bootloader_socOpenFirewalls()；

bootloader_socNotifyFirewallOpen ();

system_init()；
bootloader_profileAddProfilePoint ("System_init")；
#endif
drivers_open()；
bootloader_profileAddProfilePoint ("Drivers_open")；

新 SDK (mcu_plus_sdk_am64x_11_00_00_15)似乎专门调整了序列、目标是什么？

您好：

Unknown 说：

#if 1 //can boot // from SDK：mcu_plus_sdk_am64x_11_00_00_15

我不确定我是否关注此问题。 在这里、您表示使用 SDK v11.0引导成功、但使用 SDK v10.0引导失败。 但之前、您以相反的方式传达了该问题。

在任何情况下、SDK v11.0中的顺序都是正确的。 订单由以下提交决定：

am64x、am243x：SBL：在 system_init·TexasInstruments/mcupsdk-core@71cc503之后移动打开的防火墙 API

此致、

Prashant

您好、Prashant、

 迁移到新的 SDK v11.0时、SBL 的初始代码未更改。 假设这就是为什么 会发生之前的"OSPI_UDMA ()断言问题"。

从 commit 的注释来看、假设我们需要相应地调整初始代码以支持安全启动、对吧？