AM2434: AM243x Secure Boot (SBL OSPI) - how to modify memory map layout for applications greater than 256kb?

Hi Daniil Nahliuk,

The assigned expert engineer is on leave this week. Once he is back, he will address this thread and provide a response next week.

Thanks,

JOMY

Thank you.

Additional information:
1. would a multi-partition opsi boot alleviate the issue of application images exceeding 256kb? How would such a boot process work? (flash -> msram -> decrypt partition 1 -> repeat for all partitions only moving smaller chunks of the 1600kb to msram for decryption?) Would it be a process where a partitioning is checked for tampering and if passes the check is then just released from MSRAM? 

2. Can the process of decrypting image for secure boot verification be moved from MSRAM to ddr4? If yes, please guide me on what needs to be re-configured to achieve this. 

3. In the AM243x SDK it states, "f the application is running in a core other than the core SBL is running in (usually the R5F0-0 core), the application may start before the SBL comes to a halt and cause a race condition on the memory access and might crash SBL. This can be problematic in multi-core image scenarios. So make sure to assign only the non-SBL-reserved part of the MSRAM to the application if it is running on a non self core. If this is not possible, make necessary arrangements in the application and SBL to wait till SBL ends and then start executing the application." 

 What is the process for making such arrangements in the application and SBL to ensure that application waits until SBL ends to start execution? 

Daniil Nahliuk said:

Also, I have 2 multi-core images for different applications one that is ~300kb and another ~1600kb. For 1st application only memory map layout adjustment is needed, but for 2nd from my understanding it is too large even with memory map adjustment, thus (2) what sort of recommendations do you have for estabilishing secure boot for an application of that size? 

Unless you have extra RAM on your board, the only option is to use XIP but it also has some limitations. The best would be to evaluate if any space optimisations could be done for your applications like if you are building the application with correct flags for space optimisation.

Daniil Nahliuk said:

1. would a multi-partition opsi boot alleviate the issue of application images exceeding 256kb? How would such a boot process work? (flash -> msram -> decrypt partition 1 -> repeat for all partitions only moving smaller chunks of the 1600kb to msram for decryption?) Would it be a process where a partitioning is checked for tampering and if passes the check is then just released from MSRAM? 

This is not possible.

Daniil Nahliuk said:

2. Can the process of decrypting image for secure boot verification be moved from MSRAM to ddr4? If yes, please guide me on what needs to be re-configured to achieve this. 

Do you DDR available on your board?

Hi Prashant, thank you for the reply and clarifying the process! 

1. I have DDR available on my am64x-evm. Please provide information on how the secure boot verification can be moved from MSRAM to ddr. 
2. You mentioned that XIP is an option. Could you clarify how that that could be used in secure boot as in SDK for both 64x & 243x it's mentioned that, "XIP boot : Secure boot is yet to be supported for XIP applications. This is due to the fact that the XIP sections are loaded before the SBL parses the other sections."?

Hi Prashant, thank you for explaining. Can you respond to my other questions, please? Prashant Shivhare 

Daniil Nahliuk said:

2. You mentioned that XIP is an option. Could you clarify how that that could be used in secure boot as in SDK for both 64x & 243x it's mentioned that, "XIP boot : Secure boot is yet to be supported for XIP applications. This is due to the fact that the XIP sections are loaded before the SBL parses the other sections."?

Those are the limitations. The XIP allows execution of larger applications but the secure boot is not supported for the XIP.

Before proceeding further, I would like to clarify that the encrypted boot is not supported in the latest SDK because it moved to the MCELF image format for the applications which do not actually require any intermediate buffer for the authentication. However, the encrypted boot is not yet supported for MCELF images in the SDK.

The secure boot information in the documentation you are referring to applies only to the SDK version prior to v12.0 which used the APPIMAGE format for the application images.

I see thank you for clarifying. This will not be an issue as our build system creates both .appimage and .mcelf for the multicore application. Please proceed with guidance on how to migrate secure boot process from MSRAM to DDR. 

Hello,

This is the buffer used for authentication of the application images (only the .appimage) as the MCELF images are authenticated on-the-fly by the SYSFW and loaded to their load addresses.

https://github.com/TexasInstruments/mcupsdk-core/blob/6a622a5c2729c5ad10ba066646944609dc0c64bb/examples/drivers/boot/sbl_ospi/am64x-evm/r5fss0-0_nortos/main.c#L47

and this buffer is already allocated to the DDR for AM64 devices

github.com/.../example.syscfg

Hi Prashant, thank you for the help!

For AM64x platform I found that a lot of application code size is allocated for A53 MMU tables and after analyzing the .map file of the A53 application I found that only 1/3 of the space allocated for MMU is actually being used. Can you provide information on how the MMU table size and alignments can be adjusted and reduced for A53, please?  

Daniil Nahliuk said:

For AM64x platform I found that a lot of application code size is allocated for A53 MMU tables and after analyzing the .map file of the A53 application I found that only 1/3 of the space allocated for MMU is actually being used.

It should not causing the problem. The size used in the MMU is large to accomodate the application size in case it grows. This is helpful since you won't have to keep changing the size everytime the application size changes.

In any case, the MMU can be configured or updated by opening the A53 application sysconfig file.

Hi Prashant, thank you for clarifying. At further inspection for our use case, it is necessary to reduce the MMU size. Analysis of the .map was conducted again and it was found that,

"The largest platform-specific block is the MMU table area: 196,608 allocated bytes across three 64 KiB-aligned slots. The actual table storage is roughly 64 KiB; approximately 128 KiB is slot/alignment overhead"

as well as the below table describing the allocation within the MMU:



We took the below actions to reduce this allocation but none of them helped:
1. Modified MMU allocation within A53's sysconfig file to be (1) smaller and (2) just be removed, neither resulted in any change in the application size.
2. Within SDK's "MmuP_armv8.c" modified these variables to have reduced alignment:

FROM:

#include "MmuP_armv8_internal.h"

__attribute__((aligned(65536))) uintptr_t *gMmuLevel1Table;
__attribute__((aligned(65536))) uint64_t gMmuTableArray[MMUP_TABLE_LEN * MMUP_TABLE_ARRAY_LEN];
__attribute__((aligned(65536))) uint64_t gMmuTableArraySlot;


TO:

#include "MmuP_armv8_internal.h"

__attribute__((aligned(4096))) uintptr_t *gMmuLevel1Table;
__attribute__((aligned(4096))) uint64_t gMmuTableArray[MMUP_TABLE_LEN * MMUP_TABLE_ARRAY_LEN];
__attribute__((aligned(4096))) uint64_t gMmuTableArraySlot;

3.  Added random text to the "MmuP_armv8.c" and the project still build meaning that the file is never compiled and doesn't affect the project
4. Modified the 'MmuP_armv8_internal.h' to have reduced table array size 


Thus, these are the questions I have:
1. What component or configuration actually controls the MMU memory allocation if neither the SysConfig file nor 'MmuP_armv8.c' (or its .h file) appear to affect the built project?

I see, thank you for clarifying and all the help!!