• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 99 subscribers
  • Views 459 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.

AM6422: [OTP Keywriter] The HS-SE device boot failure if update the SWRV to 2 by TISCI_MSG_WRITE_SWREV

Tiger Yu
Prodigy 100 points
Part Number: AM6422

Tool/software:

I’m using the TISCI_MSG_WRITE_SWREV to update the SWRV to 2 on the HS-SE device, and using the TISCI_MSG_READ_SWREV to readback that the SWRV has been updated to 2 successfully.
After reboot, the SE device will be boot failure, no any output in the UART console.

So my question is what is about SWREV? Is there any detail information about this field? Is there any possible to recover my device?
In OTP keywriter, there is also similar command to update the swrev like below, not sure they are the same thing.
./gen_keywr_cert.sh -t tifek/ti_fek_public.pem --sr-sbl 1 --sr-sysfw 1


Here is some log when update the swrev to 2 using TISCI_MSG_WRITE_SWREV for your ref as below:

# Update the swrev to 0x2

Starting runtime keyrev ...

DMSC Firmware Version 8.6.4--v08.06.04 (Chill Capybar
DMSC Firmware revision 0x8
DMSC ABI revision 3.1

Read keyrev & keycnt
read keyrev & keycnt passed!
KEYREV : 0x1
KEYCNT : 0x1

VPP is ON
INFO: tisci_sendmsg_write_swrev:89: Success writing SWREV value
INFO: tisci_sendmsg_read_swrev:48: Success reading SWREV value
INFO: tisci_sendmsg_read_swrev:50: SWREV value reported : 0x2
ID:2, get swrev: 0x2
  • 0
    TI__Guru 69061 points

    Hello,

    May I know why are you updating SWREV in the context of the KEYREV example? I suppose you got the KEYREV example from the following FAQ

    https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1202686/faq-am6442-am243-how-to-use-the-tisci-apis-read_keycnt_keyrev-write_keyrev-to-activate-the-backup-key-set

    Regards,

    Prashant

  • 0 in reply to Prashant Shivhare
    Prodigy 100 points

    Hi Prashant,

    Just for test to see whether we can use this field, and which will cause the device boot failure.

    And we can close this issue now.

    Thanks,

    Tiger

    Prashant Shivhare said:
    Regards
  • 0 in reply to Tiger Yu
    TI__Guru 69061 points

    Hi Tiger,

    Would you like to know how to make the device bootable again?

    The SWREV field is intended for Rollback Protection of different images. This means that you could make your previously signed images unbootable by incrementing the SWREV field.

    Now, there could be any reason of doing this. One of the major is if you found some vulnerability in your software and released a patched one. In that case, you may want that the vulnerable image should not boot anymore. For that, you would use the SWREV field.

    The X.509 certificate of the signed imaes would contain the SWREV field. The ROM or Sysfw would only boot the images with the SWREV matching against the configured SWREV in e-fuses.

    Regards,

    Prashant

  • 0 in reply to Prashant Shivhare
    Prodigy 100 points

    Hi Prashant,

    Thanks for your elaborating detail information for SWREV for main use of rollback protection.

    There are still two questions:

    1. As you know, there are three software revision identifiers, list as below, now I just test the OTP_REV_ID_SEC_BRDCFG.

        From test if update the OTP_REV_ID_SEC_BRDCFG to 2, the original image will be boot failure, it's expected as design.

        I didn't test the others, so what about the others for rollback protection?

    /** Sofware Revision SBL */
    OTP_REV_ID_SBL = 0,
    /** Software Revision SYSFW */
    OTP_REV_ID_SYSFW = 1,
    /** Software Revision Secure Board Configuration */
    OTP_REV_ID_SEC_BRDCFG = 2,

    2. I can't read back the SWREV value by TISCI_MSG_READ_SWREV for the first time for OTP_REV_ID_SBL & OTP_REV_ID_SYSFW.

       But it's ok for the OTP_REV_ID_SEC_BRDCFG. What's the difference design here?

    Here is previous log saved for your ref.

    ID:2, get swrev: 0x1

    ERROR: tisci_sendmsg_read_swrev:56: Error reading SWREV !!! id=0, status=0, resp_flags:0x0, response.val=4294967295

    Error reading swrev

    ERROR: tisci_sendmsg_read_swrev:56: Error reading SWREV !!! id=1, status=0, resp_flags:0x0, response.val=4294967295

    Error reading swrev

    Thanks,

    Tiger

  • 0 in reply to Tiger Yu
    TI__Guru 69061 points

    Hi Tiger,

    Tiger Yu said:
    I didn't test the others, so what about the others for rollback protection?

    The SWREV field is supported for three different binaries: SBL, Sysfw, and Board configuration. You updated the SWREV field for the Board Configuration binaries (ID: 2).

    So, in order to make the device bootable again, you would need to generate the signed board config binaries with SWREV 2.

    Tiger Yu said:
    But it's ok for the OTP_REV_ID_SEC_BRDCFG. What's the difference design here?

    The Sysfw doesn't not yet support reading SWREV for SBL and Sysfw as documented here: https://software-dl.ti.com/tisci/esd/latest/2_tisci_msgs/security/otp_revision.html?highlight=tisci_msg_read_swrev

    Please note, the SWREV fields in the e-fuses for all the components comes already programmed with an initial value of 1 from TI.

    Regards,

    Prashant