Failed to secure boot application if SBL enable QSPI flash's DMA mode

Hi Jenny,

Are you using a TI EVM or a custom board? Did you face this issue with the default sbl_ospi available in the MCU+SDK or did you make any changes?

Best Regards,

Meet. 

Hi Meet,

I'm using a custom board, I'm using the default sbl_ospi with only DDR and flash configuration is changed through 'example.cfg'.

One more information is that everything run well with SDK'mcu_plus_sdk_am64x_10_00_00_20'.

Looks like with new SDK, and while do secure boot, there's some special offset can not be read with 'DMA is enabled'.

Hello,

Jenny Zhou said:

TR Response failed for transfer : SRC = 0x61000000, DST = 0x84000000, SIZE = 32

ASSERT: 18.407657s: ospi/v0/lld/dma/udma/ospi_udma_lld.c:OSPI_udmaUpdateSubmitTR:259: FALSE failed !!!

Something doesn't feel right about these addresses specifically the SRC address as the OSPI is memory mapped at address 0x60000000 so that address means an offset of 64MB. This would be incorrect at least for EVM as it has only 64MB flash part.

I just tried booting an encrypted application on the EVM and it was successful:

[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!

The additional logging was enabled with the following patch:

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
+}

Could you please check your boot flow and clarify the inconsistencies about those SRC and DST addresses?

Regards,

Prashant

Hi Prashant,

offset: 0x61000000, should means the offset 0x01000000 of flash, right? because in direct read mode, flash data is mapped to memory start at 0x60000000, right?

Jenny Zhou said:

offset: 0x61000000, should means the offset 0x01000000 of flash, right? because in direct read mode, flash data is mapped to memory start at 0x60000000, right?

That is correct.

The default offset is 0x80000 so the offset in your logs is unexpected.

Hi Prashant,

I found the root cause is the sequence of some initial code: 'system_init(), Bootloader_socOpenFirewalls()' etc. See below code snippet.

#if 1 //can boot // from SDK:mcu_plus_sdk_am64x_11_00_00_15
System_init();
Bootloader_profileAddProfilePoint("System_init");

Bootloader_socOpenFirewalls();

Bootloader_socNotifyFirewallOpen();

#else //can not boot // from 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");

So seems new SDK(mcu_plus_sdk_am64x_11_00_00_15) has specially adjusted the sequence, what's the aim for?

Hello,

Jenny Zhou said:

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

I am not sure if I am following the issue. Here, you say the boot is successful with SDK v11.0 but is unsuccessful with SDK v10.0. But previously, you communicated the issue other way around.

In any case, the order in the SDK v11.0 is correct. The order is fixed by the following commit:

am64x,am243x: sbl: Move open firewall apis after system_init · TexasInstruments/mcupsdk-core@71cc503

Regards,

Prashant

Hi Prashant,

Our SBL's initial code has not be changed when we moved to new SDK v11.0. Suppose that's why previous 'OSPI_udma() assert issue' occurs.

so from the comment of commit, suppose we need to adjust the initial code accordingly to support secure boot, right?

Hello,

Jenny Zhou said:

so from the comment of commit, suppose we need to adjust the initial code accordingly to support secure boot, right?

That seems to be the case. It is recommended to once evaluate the changes for the SBL OSPI between the two versions and accordingly backport the required changes.

Regards,

Prashant