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.

AM6442: am64x using sa2ul + firewall in R5F

Part Number: AM6442

Hi,

I am using am64x with sbl bootflow to start R5F. Now we wanted to add Linux, so we load also the linux.appimage.hs_fs in the bootloader.

At first I had to sync the security handover between boardconfig and sec-cfg.yaml inside U-Boot SPL. So I changed the sec-cfg.yaml to msg_sender TISCI_HOST_ID_MAIN_0_R5_0 and to_host_id TISCI_HOST_ID_MAIN_0_R5_0. Finally U-Boot SPL passed the Authentication of the Image. Linux boots fine under one condition, which I will explain in the following!

Information:

Our R5F application uses sa2ul driver and also controls the firewall (MCU+SDK 11.00.00.18).

Condition, how it boots:

In case of trying to boot linux, I always get a resource conflict between R5F application and the linux artifacts (especially U-Boot SPL). If I comment out sa2ul driver and firewall in my R5F application, Linux boots without any problems.

But when I try to comment it in again, it is not booting correctly. R5F application simply does not start correctly and hangs while opening sa2ul driver or firewall.

In case of U-Boot SPL not synced the security handover (default values in yaml were 0 and 0) I get always the error, that te ti_sci driver requests triggered from system-controller something and does get a NACK, which results in "Authentication failed!" In this case, I am able to boot R5F application again!
 
Here the log ( I added print outs who called ti_sci_do_xfer because this method fails.
 
ti_sci_cmd_get_revision: calling ti_sci_do_xfer
Authenticating image at address 0x0000000081c01cac
Authenticating image of size 1114756 bytes
ti_sci_cmd_proc_auth_boot_image: calling ti_sci_do_xfer
ti_sci system-controller@44043000: Message not acknowledged
Authentication failed!
### ERROR ### Please RESET the board ###
 
In case of syncing the security handover again but not starting the A53 core in Bootloader R5F application starts also without any problems (should also be like that, because it was default behavior before our decision to add linux).
 
In the mean time I also tried to build OP-TEE with option:
CFG_WITH_SOFTWARE_PRNG=y
which ends up setting
CFG_SA2UL=n
 
After that I also tried to disable ATF from loading OP-TEE with removing the build option:
SPD=opteed
 
But both approaches did not work.
 
Any suggestions from your side what to change in the linux.appimage.hs_fs to boot and still be able to use firewall and sa2ul inside R5F application?
 
BR Dominik
  • Hello,

    At first I had to sync the security handover between boardconfig and sec-cfg.yaml inside U-Boot SPL. So I changed the sec-cfg.yaml to msg_sender TISCI_HOST_ID_MAIN_0_R5_0 and to_host_id TISCI_HOST_ID_MAIN_0_R5_0. Finally U-Boot SPL passed the Authentication of the Image. Linux boots fine under one condition, which I will explain in the following!

    If you are always using the SBL from MCU+ SDK to boot the cores then the baord config modifications in the U-Boot shouldn't have any effect as the board config are part of the SBL or the R5 SPL only. So, if you are booting the SBL then the board config blob packaged with the SBL will come into effect.

    In case of syncing the security handover again but not starting the A53 core in Bootloader R5F application starts also without any problems (should also be like that, because it was default behavior before our decision to add linux).

    Can you try adding, let's say, 5 seconds after the SBL boots the A53 core to let the U-Boot SPL boot the U-Boot before SBL goes any further? This should boot the R5F core successfully.

  • Hello,
    I am Dominik's colleague and I am currently working on this topic.
    I have tried your proposal to insert a delay into the SBL between Linux boot and R5 cores. With a delay of minimum 1 second U-boot boots successfully. 

    But our system needs to start the FreeRTOS on R5 cores as quickly as possible. Any extra delay is not acceptable for our application. Is there another possibility to fix the authentification of OPTEE in U-Boot SPL?

  • The issue is caused by the following call (Bootloader_socSecHandover) by the SBL before handing the core to the application.

    https://github.com/TexasInstruments/mcupsdk-core/blob/6a622a5c2729c5ad10ba066646944609dc0c64bb/source/drivers/bootloader/soc/am64x_am243x/bootloader_soc.c#L1004

    The consequence of this call is that the SYSFW relinquishes the security service which includes the PROC_AUTH_BOOT as well used for authentication of the application images. Because of this, the U-Boot fails to authenticate the images as the SBL would have requested the Security Handover by the time U-Boot starts authenticating the images.

    If you comment this function then the U-Boot should be able to authenticate the images. However, you will then not be able to use the SA2UL PKA or the Firewall modules in the R5F application.

    If you are using SA2UL and Firewall module in the R5F application then the Security Handover is necessary.

    So, you would need to ensure the security handover is requested only after the U-Boot has completed the authentication of the images.

  • Hi,
    thanks for your answer.

    Is it possible to authenticate the images on U-Boot without requiring the SA2UL/Firewall resources, so that R5F application uses it directly?

    I tried that already with compiler flags (see first post in this E2E Thread), but maybe I am missing something.


    BR Dominik

  • Is it possible to authenticate the images on U-Boot without requiring the SA2UL/Firewall resources, so that R5F application uses it directly?

    The U-Boot asks the SYSFW, which uses SA2UL, to authenticate the images. So, the authentication procedure must complete before the SBL requests the Security Handover. You would need to have synchronization mechansim between the authentication requested by U-Boot and the Security Handover done by the SBL. The latter must be done after the former is completed.