• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 99 subscribers
  • Views 512 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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: SCICLIENT, load SYSFW, and Secure Proxy Configuration

Boshra
Intellectual 418 points
Part Number: AM6442

Hi, 

We are using AM6442 no-rtos, bare-metal, using single core R5f_0_0, using CCS boot method (no SBL instead Sciclient_ccs_init used).

We have simplified the Sciclient code based on our need and kept only the messages we need, also simplified the header files, and removed sciclient_init as it was only initializing the handle instead we have defined macros for constant values and defined the register set and used it in all the related called functions in the secure proxy files. Also, we have simplified the header files for the default_boardcfg files

However when we try to load the sciclient_ccs_init which is our CCS boot method, we are never able to load the sysfw using Sciclient_loadFirmware, another point is that it seems the secure proxy is not even configured. We think like that because some registers like DMASS0_SEC_PROXY_0_CONFIG Register, etc  are not having any values before we try to put any data in the tx thread. so we think the secure proxy is not even configured. 

  • do you know what can be the reason?
  • also the function CSL_secProxyCfg seems to be for configuring the secure proxy but this function is not called by anyone. who is calling this function?
  • In the bootloader section of the TRM it is said configuring the secure proxy is by DMSC ROM, if its the case, does that mean somehow DMSC needs to use the handle gSciclientSecProxyCfg or the function CSL_secProxyCfg? if yes how these are passed to DMSC? is it part of SYSFW?

Thanks, 
Boshra

  • 0
    Intellectual 418 points

    Also as I said earlier we use the CCS boot method, which set the pins to the following:

    based on the TRM, if we are using Development boot mode the following happens:

    Does this mean that the image integrity check will not be executed?

    and what does the DMSC do for integrity checks? sysfw is also part of the code as a hex array, when we try to load the sysfw does it check if the sysfw integrated in the boot code .out matches with the sysfw we are trying to load as a hex array?

    Your answer is very valuable in our case. 

    thanks for your help, 

    Boshra

  • 0 in reply to Boshra
    TI__Guru 69511 points

    Hello,

    Boshra said:
    and what does the DMSC do for integrity checks?

    This involves the authentication of the signed combined boot image (.tiimage) in all bootmodes except DEVBOOT.

    In DEVBOOT mode specifically, the ROM allows loading of a R5 application (sciclient_ccs_init in MCU+ SDK) directly. This application must at least request ROM to load a signed Sysfw image (included as a hex array in sciclient_ccs_init) which will be authenticated by the ROM. If successful, the ROM loads and run the Sysfw image.

    Boshra said:
    However when we try to load the sciclient_ccs_init which is our CCS boot method, we are never able to load the sysfw using Sciclient_loadFirmware,

    About this original issue, it seems like you have done too many changes which may not be feasible to easily debug. I would like to know if you have a working base from where you can start adding your things one by one and resolve the ones which breaks the functionality.

    Regards,

    Prashant

  • 0 in reply to Prashant Shivhare
    Intellectual 418 points
    Prashant Shivhare said:
    hich will be authenticated by the ROM

    Sorry, I'm confused. Do you mean even in DEVBOOT mode the authentication is done? and we still need to use the signed Sysfw?

    about the hex arrays including Sysfw and boardcfg hex arrays, in the DEVBOOT mode does it require to use the hs files or it doesn't matter in this mode? (our board is HS-FS type)

    thanks, 

    Boshra

  • 0 in reply to Boshra
    TI__Guru 69511 points

    Hello,

    Yes, on HS devices, even the DEVBOOT mode requires using the signed Sysfw. The sciclient_ccs_init example already includes by default the HSFS Sysfw.

    The header file sysfw_hs_fs_signed.h defines an array of bytes for HSFS Sysfw Cert + Sysfw Binary. More specifically, the array is basically generated by getting the hex dump of the concatenation of sysfw-hs-fs-enc-cert.bin and sysfw-hs-fs-enc.bin.

    Regards,

    Prashant

  • 0 in reply to Prashant Shivhare
    Intellectual 418 points

    yes, I saw that in the code, however in the makefile, it does not build the files for the HS Device by default, as the DEVICE_TYPE has nowhere defined as HS. so it seems that the build was considered for GP device. So does it mean in case we have changed the files it is necessary to define DEVICE_TYPE as HS?

    how about the BoardCFG hex arrays? does it also need to use the HS ones? and what happens if the HS hex arrays be changed but we still use the old ones? because based on the makefile_board we don't rebuild the HS hex arrays because we are not using HS. so in this case, is there any integrity or anything that can check it causes an exception, etc?

  • +1 in reply to Boshra
    TI__Guru 69511 points
    Boshra said:
    So does it mean in case we have changed the files it is necessary to define DEVICE_TYPE as HS?

    No. Following is the convention for DEVICE_TYPE defined in devconfig/devconfig.mak which is included in all the makefiles in the SDK.

    DEVICE_TYPE=HS: Build images for HSSE device.

    DEVICE_TYPE=GP: Build images for GP & HSFS device. Board configuration binaries (unsigned) remains same for GP and HSFS devices.

    So, the default BoardCfg hex files included by the sciclient_ccs_init are correct for both GP & HSFS devices