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.