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: OTP

Part Number: AM6442
Other Parts Discussed in Thread: AM6422

Hi team, 
How to enable the OTP keywriter app running on the HS-SE device?

Generally, for OTP keywriter, it will run on non-SE device. It will use the rom_degenerateKey.pem to generate final image.
When using the BMPK as a backup option, with this scenario, I think it needs to run keywriter again on the security device to choose the BMPK key sets, right?

I just tried to rebuild the OTP keywriter tool by replacing the original key rom_degenerateKey.pem with correct customer key. But it failed to load this new app, no any output on the UART console after loading by xmodem protocol.

And here are some building logs for your ref as below:

~/ti/mcu_plus_sdk_am64x_08_06_00_43/source/security/tifs/sbl_keywriter/am64x-evm/r5fss0-0_nortos/ti-arm-clang ~/ti/mcu_plus_sdk_am64x_08_06_00_43/source/security/tifs/sbl_keywriter/am64x-evm/r5fss0-0_nortos/ti-arm-clang

Debug Extension is Enabled :
SoC UID not specified for Debug Extension. Using UID 0
UID = 0000000000000000000000000000000000000000000000000000000000000000
DBG_TYPE = 4
R5 Certificate being generated :
X509_CFG = ./x509-temp.cfg
KEY = /home/lubancat/work/baoSight/T3/bsp/board-support/core-secdev-k3/keys/custMpk.pem
BIN = /home/lubancat/ti/mcu_plus_sdk_am64x_08_06_00_43/source/security/tifs/sbl_keywriter/am64x-evm/r5fss0-0_nortos/ti-arm-clang/sbl_keywriter.release.bin
CERT TYPE = R5, 1
CORE ID = 16
LOADADDR = 0x70000000
IMAGE_SIZE = 258560
BOOT_OPTIONS = 2
SUCCESS: Image /home/lubancat/ti/mcu_plus_sdk_am64x_08_06_00_43/source/security/tifs/sbl_keywriter/am64x-evm/r5fss0-0_nortos/ti-arm-clang/sbl_keywriter.release.tiimage generated. Good to boot

  • Hello,

    How to enable the OTP keywriter app running on the HS-SE device?

    This is not possible. The OTP Keywriter runs only on HSFS devices.

    The backup keys must be programmed along with the primary keys during the OTP Keywriter procedure. Once the device is HSSE, the programmed backup keys can be activated by updating the Key Revision. Please refer:

    [FAQ] AM6442/AM243: How to use the TISCI APIs (READ_KEYCNT_KEYREV & WRITE_KEYREV) to activate the backup key set - Processors forum - Processors - TI E2E support forums

    Regards,

    Prashant

  • Hi Prashant,

    Just tried with 8371.AM64x_TISCI_API_KEYREV_package.zip, do some little modification to make sure building successfully. Before that, I have replaced the below keys with our own test keys.

    1. tools/boot/signing/mcu_custMpk.pem
    2. tools/boot/signing/mcu_custMek.key
    3. examples/otp/runtime_keyrev/scripts/ keys_devel/am64x/*

     

    Building environment: mcu_plus_sdk_am64x_08_06_00_43

    Tested device: AM6422 HS-SE

     

    The test result is that there is no any output after loading this new tool by UART downloading over Xmodem on the HS-SE device. It’s same symptom when loading the OTP keywriter to SE device.

     

    So any step missing when running this example to update keyrev for SE device?

  • Hello,

    Did you already program the backup keys during the OTP Keywriter procedure?

    If in doubt, please share the output of the Python script mentioned in the following FAQ

    [FAQ] [AM6XX]: How to check if device type is HS-SE, HS-FS or GP? - Processors forum - Processors - TI E2E support forums

  • Yes, backup keys are already programmed (but my keycnt is set to 1 not to 2).

    The point here is not to activate the backup keys by far (actually I have commented out the runtime_writeKeyRev in the main() func to avoid mistake when not ready).

    It is about the new app loading failure. No any output from uart console after loading.

    And here are soc ID info for your ref as below.

    -----------------------
    SoC ID Header Info:
    -----------------------
    NumBlocks : 2
    -----------------------
    SoC ID Public ROM Info:
    -----------------------
    SubBlockId : 1
    SubBlockSize : 26
    DeviceName : am64x
    DeviceType : HSSE
    DMSC ROM Version : [0, 2, 0, 0]
    R5 ROM Version : [0, 2, 0, 0]
    -----------------------
    SoC ID Secure ROM Info:
    -----------------------
    Sec SubBlockId : 2
    Sec SubBlockSize : 166
    Sec Prime : 0
    Sec Key Revision : 1
    Sec Key Count : 1
    Sec TI MPK Hash : b018658ad99dc903c8c9bfb27b12751099920a042ad1dfea7b7ba57369f15546de285edde6a7b39a8bdc40a27b237f8fb1e57f245e80b929c1e28b024aa2ecc6
    Sec Cust MPK Hash : cf31d0348b03ebbaba33f9e8156ab8c8186f00f54c9a48b9f6fbb90ddb78a0fec2cef3d9883b1b211f1ba0b632b98c902d0f14c7cbd5d67101267f1f456cbc5d
    Sec Unique ID : 6c3f84e9ea8e8c824b4631fd6cffbd2c00e9d3e9bf21f2ab044e7efe13dee623

  • Sec Key Revision : 1
    Sec Key Count : 1

    The RUNTIME_KEYREV example even if booted successfully will not work as the Key Count is 1 instead of the expected value 2.

    May I know what is the end goal here? Are you just looking to boot your board after converting it into HSSE?

  • Hi Prashant,

    Here key count is 1 in my device is a mistake. In our normal product, this value will be programed to 2.

    But I think it shouldn't block the example app to run on the HS-SE device.

    And as you know I have already comment out the runtime_writeKeyRev to avoid keyrev update to lead device not working during development.

    The key point here I need to run this example app first on my SE device, then will add back runtime_writeKeyRev to do real keyrev updating later.

    So the problem is I have build the below example successfully, but no any output in the uart console after loading the image by UART over XMODEM protocol. Is our in the same page now? 

    e2e.ti.com/.../8371.AM64x_5F00_TISCI_5F00_API_5F00_KEYREV_5F00_package.zip

    Thanks

  • But I think it shouldn't block the example app to run on the HS-SE device.

    That is true. I just wanted to make sure you understand the example even if booted successfully will not work.

    Anyways, if you are just looking to boot the example but it is not booting then the most probable cause is the use of wrong keys to generate the image. And indeed it looks like this is the issue.

    • tools/boot/signing/mcu_custMpk.pem
    • tools/boot/signing/mcu_custMek.key

    The correct keys to replace are

    ~/ti/mcu_plus_sdk/am64x/09_02_00_50
    ❯ cat devconfig/devconfig.mak | grep am64x
            CUST_MPK=$(SIGNING_TOOL_PATH)/custMpk_am64x_am243x.pem
            CUST_MEK=$(SIGNING_TOOL_PATH)/custMek_am64x_am243x.txt

    Regards,

    Prashant

  • Hi Prashant,

    Just tried by replacing the custMpk_am64x_am243x.pem with correct customer key. Still loading failure with no any output.

    Due to custMek_am64x_am243x.txt is text format, and the smek.key is binary format.

    I can't replace it directly or will get building error. Do you know how to get the custMek_am64x_am243x.txt from smek.key?

    Thanks

  • Hi Sam,

    The conversion can be done as follows

    ~/ti/otp_keywriter/am64x/09_00_00/sbl_keywriter/scripts/cert_gen/am64x/keys_devel
    ❯ xxd -p -c 10000 smek.key | tr -d $'\n' > smek.txt
    
    ~/ti/otp_keywriter/am64x/09_00_00/sbl_keywriter/scripts/cert_gen/am64x/keys_devel
    ❯ /usr/bin/ls -l smek.txt
    -rw-r--r-- 1 p-shivhare p-shivhare 64 May 10 13:09 smek.txt
    

    Regards,

    Prashant

  • Hi Prashant,

    Thanks for your help, I can load this app now.

    Another question: since I have already programmed the keycnt 1 to the SE device, so are we able to update the keycnt to 2 again?

    For the keycnt/keyrev, no wp option added for the last program.

    Thanks,

    Tiger

  • Hi Sam,

    Another question: since I have already programmed the keycnt 1 to the SE device, so are we able to update the keycnt to 2 again?

    The KEYCNT is programmed only once during the OTP Keywriter procedure and cannot be updated again. If the KEYCNT value programmed is 2 for the two set of keys (SMPK/SMEK & BMPK/BMEK) then the KEYREV only, on the HS-SE device, can be updated from the initial value of 1 to 2 to active the BMPK/BMEK and discard SMPK/SMEK (irreversible).

    So, to support the KEYREV update on HS-SE device, at least the following must be programmed during the OTP Keywriter procedure (HS-FS -> HS-SE):

    • S-keys (smpk.pem/smek.key)
    • B-keys (bmpk.pem/bmek.key)
    • KEYCNT => 2
    • KEYREV => 1 (active set of keys => S-keys)

    Regards,

    Prashant