MCU-PLUS-SDK-AM263X: SBL KeyWriter 1.1 incompatibility with MCU+ SDK v10

Part Number: MCU-PLUS-SDK-AM263X
Other Parts Discussed in Thread: SYSCONFIG

Tool/software:

Hi, I am trying to compile the SBL KEYWRITER project to program the AM263X's e-fuses with MCU+ SDK version 10 (as this version addresses a lot of issues that we encountered with previous versions); also because we need to actually modify this SBL image to perform some hw piloting of certain on-board devices (the sitara is not on the CC evaluation board).

In any case, I noticed that at line 59 of "keywriter_utils.c" the call to "Hsmclient_loadHSMRtFirmware" is incorrect (with just one parameter), and checking the acutal function signature in the sdk I get this: "int32_t Hsmclient_loadHSMRtFirmware(HsmClient_t *gHSMClient, const uint8_t *pHSMRt_firmware);".

Since the signature is different, I also expect other changes to the internal workings of the library. Coud you tell me when do you expect to update the sbl keywriter to support MCU+ SDK version 10?

Just to clarify, we are specifically using version 10 of the sdk because of the problems that we encountered with the previous versions (we need to actually modify the sbl keywriter fw and interact with the rest of the board to correctly burn the e-fuses); see: https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1353815/am2634-hsm-app-encryption-for-secure-boot-on-hs_se-devices

Thanks,

Riccardo

  • Hi Reccardo,

    I am looking into this issue, allow me to get back by Wednesday next week latest.

  • Hi Nilabh,

    thanks for the quick reply, have a nice weekend!

    Riccardo

  • Hi Riccardo,

    In any case, I noticed that at line 59 of "keywriter_utils.c" the call to "Hsmclient_loadHSMRtFirmware" is incorrect (with just one parameter),

    The OTP keywriter compatible with SDK 10.0 has not been released yet, nonetheless OTP keywriting is independent of the issue you faced in the previous e2e. As you can see we only have OTP keywriter  till 09_01_00_05. 

  • The secure boot feature is provided by TIFS SDK. The feature you are looking for has been implemented in SDK and TIFS release version 10.0

    Check the fast secure boot implementation here: software-dl.ti.com/.../FAST_SECURE_BOOT.html

  • Hi Nilabh,

    thanks for the reply. I'm aware of the software versions compatibility; we did upgrade to the latest MCU SDK specifically to circumvent the linked issue alongside with other issues (mainly related to the i2c stack and other ipc quirks). Point is, with our board configuration as is, we cannot use the sbl keywiter as-is, but we need to modify it to actually have it interact with the board in some way (that I can't obviously write here).

    We do internally track a fork of this mcu+ library to incorporate it with some changes inherent to our specific architecture and needs, but also to implement fixes and/or workarounds that we have to implement to have them work before they get released with an sdk update. Seeing as how the file and folder structure of the sdk keeps changing (as well as sysconfig itself apparently, since we received breaking changes with the newest versions that didn't seem to work with "older" files, but that's a topic for another day), we wanted to wait to update to version v10 due to a promised "[...]architectural change with a lot of fixes addressed". We just thought that such a big refactor could be a good starting point, to avoid re-testing all of our projects with all minor releases of the sdk and only using major releases.

    Here is a non-comprehensive list of all of the issues that we somehow needed to circumvent:

    AM2634: IPC hangs on callback

    SYSCONFIG: 1.21.1 LogZone ignored

    TMDSCNCD263: AM263x: sbl_qspi_am263x example stucks during HSM's runtime firmware load

    MCU-PLUS-SDK-AM263X: Failed to run signed code on HF-SE AM2634 device

    MCU-PLUS-SDK-AM263X: I2C HLD timeout (regression)

    Note that before opening a thread on TI's website we have to actually find the issue, debug it, and decide if it is worth opening a forum post; providing a reproducible example obviously takes time and effort, and most of the time we just incorporate such fixes on our fork of the mcu sdk and call it a day, hoping that the sdk's api (or sysconfig's one) doesn't change.

    The obvious workaround for this specific issue is to download mcu sdk v9.1 (as v9.2 is when the change in folder structure seems to have happened for the files relative to the hsmclient needed to build the otp keywriter, oddly enough) and modify the relevant code to include our keys, certificate, code fixes, sdk fixes, etc., but it really is a lot more cumbersome than it should be, and also really too brittle for such a delicate one-chance procedure; we also need it to get it to work for our pipeline, it needs testing, etc. Not to mention the developer's effort, as on every developer's machine there needs to be installed a quite old version of sysconfig and CCS, which just increases room for user error.

    For now we do have a working temporary solution as described above, but it would be really good news if a release date for a compatible keywriter (as in compatible with the other latest development tools provided by TI), to not keep track of multiple SDKs, tools, etc.

    Thanks,

    Riccardo

  • Hi Riccardo,

    Apologies that you had to face all these issue, I would like to help you out here. I agree it would be a hassle to test it on two versions of SDK.

    Allow me to discuss with the internal team on the expected date for OTP key writer and get back to you latest by Wednesday next week, as this week most folks are out due to thanksgiving.

  • Hi Nilabh,

    thanks for the reply; I'm looking forward to more news then!

    Thanks again for your time and patience,

    Riccardo