This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM625: R5 Image for HS-SE Clarification

Part Number: AM625

Tool/software:

Hi,

I mentioned in my other thread https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1429271/am625-secure-boot-hs-se that the hs-se is working. At that moment, I was using the ipc_rpmsg_echo_linux.release.out to be part of tiboot3.bin

If I set the DEVICE_TYPE=HS then build, it produced a file ipc_rpmsg_echo_linux.release.appimage.hs.

I tried to use it as part of tiboot3.bin but it didn't work.

How to use the ipc_rpmsg_echo_linux.release.appimage.hs image.hs?. 

Regards,

John

  • Hello,

    The Processor SDK takes the ELF file only for the WKUP R5F application. The application will be signed & packaged in `tispl.bin`. It will then be authenticated at run time before booting it.

    Thanks!

  • How does encryption work in this context?  If the board has been configured with an SMEK, how does the Processor SDK encrypt the ELF file before signing and packaging it in tispl.bin?

  • If the board has been configured with an SMEK, how does the Processor SDK encrypt the ELF file before signing and packaging it in tispl.bin?

    The PSDK does not have the support for encryption. Any blob will only be signed & authenticated but not encrypted/decrypted.

  • I see.  Thank you.  In that case, we should not bother using an SMEK because its not supported?

    In what context then is encryption supported, if not the PSDK?

    Or are you saying that we have to inject an already encrypted binary into the PSDK build, instead of just the unencrypted ELF?

  • In that case, we should not bother using an SMEK because its not supported?

    That depends. You may want to program the encryption keys just in case since they can only be programmed in the HSFS state using the keywriter. Once the device is HSSE, there is no going back.

    In what context then is encryption supported, if not the PSDK?

    The MCU+ SDK boot flow supports booting the encrypted images.

    Or are you saying that we have to inject an already encrypted binary into the PSDK build, instead of just the unencrypted ELF?

    The PSDK itself signs the images & that's where the encryption is not yet supported.