Fail to burn fuses and initiate the secure boot (Mallow board V1.1A, AM62)

[xistva02]

Hello,

I have a problem with secure boot implementation for Toradex Mallow board V1.1A with Verdin AM62D 1GB WBIT. I followed the instructions but cannot progress further. First I encountered problems with Yocto build (tdx-reference-multimedia-image) when using meta-toradex-security layer (INHERIT += "tdx-signed") but it was resolved by creating clean build with all updates, layers, and patches already applied in first build.

I provided custom keys (backMpk.key, backMpk.pem, custMpk.key, custMpk.pem, and ti-degenerate-key.pem) during build (TDX_K3_HSSE_KEY_DIR ?= "${TOPDIR}/keys/ti"). I short-cut the pins to enter recovery mode, flash the EasyInstaller and install the image as usual. However, if I want to connect to the device, I cannot. UART and USB do not show any information. I supposes this is correct behaviour as the fuses were not burned so the boot fails (altough I cannot debug it and be sure as long as UART does not send any information).
I followed the instruction from TI docs and OTP Keywriter, creating tiboot3.bin file that should be able to burn the fuses.
Here: https://dev.ti.com/tirex/explore/node?node=A__AfTbl6-QQ9.goHdZtWK8.w__AM62-ACADEMY__uiYMDcq__9.02.00.00%20v1, they show how to flash the tiboot3.bin file to burn the fuses. But Mallow does not have configuration of the boot mode switches for USB-DFU boot mode as shown in Figure 1. Is that correct? I am not sure how to flash the tiboot3.bin into Mallow. When I run "sudo dfu-util -l" I see no devices. The tiboot3.bin provided by Toradex within the Yocto image does not burn the fuses, right?

Did anyone test the Mallow board with AM62 and secure boot? How to burn he fuses in this setup using TI's tiboot3.bin?

In this thread: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1342080/sk-am62-lp-sequence-for-enabling-secure-boot-using-custom-keys, I cannot proceed with:

7 Rebuild u-boot, now signed with the new custom key.
8 The tiboot3.bin is loaded by dfu boot, it is executed and burning the eFuses.

as I do not know how to load the tiboot3.bin.

Thanks for any information.

Matej I.

[sergioprado]

Hello,

I have a problem with secure boot implementation for Toradex Mallow board V1.1A with Verdin AM62D 1GB WBIT. I followed the instructions but cannot progress further. First I encountered problems with Yocto build (tdx-reference-multimedia-image) when using meta-toradex-security layer (INHERIT += "tdx-signed") but it was resolved by creating clean build with all updates, layers, and patches already applied in first build.

You should not have any build issues. Feel free to report them, providing the logs, so we can help you investigate it.

I provided custom keys (backMpk.key, backMpk.pem, custMpk.key, custMpk.pem, and ti-degenerate-key.pem) during build (TDX_K3_HSSE_KEY_DIR ?= "${TOPDIR}/keys/ti"). I short-cut the pins to enter recovery mode, flash the EasyInstaller and install the image as usual. However, if I want to connect to the device, I cannot. UART and USB do not show any information. I supposes this is correct behaviour as the fuses were not burned so the boot fails (altough I cannot debug it and be sure as long as UART does not send any information).

Yes, that is correct. A signed image will not boot on a device with no keys fused.

I followed the instruction from TI docs and OTP Keywriter, creating tiboot3.bin file that should be able to burn the fuses.
Here: https://dev.ti.com/tirex/explore/node?node=A__AfTbl6-QQ9.goHdZtWK8.w__AM62-ACADEMY__uiYMDcq__9.02.00.00%20v1, they show how to flash the tiboot3.bin file to burn the fuses. But Mallow does not have configuration of the boot mode switches for USB-DFU boot mode as shown in Figure 1. Is that correct?

Yeas, Mallow doesn't have the switches. But you can get it into recover mode as documented here: https://developer.toradex.com/easy-installer/toradex-easy-installer/loading-toradex-easy-installer/?module=verdin_am62&carrier=mallow#start

I am not sure how to flash the tiboot3.bin into Mallow. When I run "sudo dfu-util -l" I see no devices.

If you are not seing the device when running 'sudo dfu-util -l', it is probably because the device is not in recovery mode. For your record, this is the command I used to boot tiboot3.bin and fuse the keys:

sudo dfu-util -c 1 -i 0 -a bootloader -D tiboot3.bin

The tiboot3.bin provided by Toradex within the Yocto image does not burn the fuses, right?

No, it doesn't.

Did anyone test the Mallow board with AM62 and secure boot? How to burn he fuses in this setup using TI's tiboot3.bin?

I tested on Verdin Develoment Board, but not on Mallow.

One important thing to mention is that, to fuse the keys, you have to toggle the VPP pin while you are writing to the fuses. Did you implemented that in our keywriter software?

[xistva02]

Hello,

Thank you for the information. I was able to find the devices (right after switching to recovery mode). However, I did not toggle the VPP pin. It seems that in SODIMM, it corresponds to pin 104 (SOC_VPP ballname) but I did not find it on the Mallow board. How is it connected to the board so I can configure it?

[sergioprado]

VPP pin is connected to SODIMM 104. I quickly looked at the Mallow board datasheet, and didn't find any connection to it. It seems this pin is not exposed in the Mallow board. You might want to confirm this with a Toradex FAE via the community website (https://community.toradex.com/).

This is the correct programming sequence to write to the fuses:

1. Power on the board per the power-up sequencing. No voltage should be applied on the VPP terminal during power up and normal operation.
2. Load the OTP write software required to program the eFuse (you need to contact a TI representative for the OTP software package, which requires NDA).
3. Apply the voltage on the VPP terminal according to the AM62 datasheet (Section 7.9.1).
4. Run the software that programs the OTP registers.
5. After validating the content of the OTP registers, remove the voltage from the VPP terminal.

[xistva02]

Hello,

Toradex technical support confirmed that on Mallow V1.1, the VPP pin is not exposed to the board. However, we were able to connect small wire to the VPP pin and use pin 3 in X10 header of Mallow board to provide 1.8 V during fusing. But, it still does not work.

I want to confirm one thing that I am doing it right. First, I reset the device to recovery mode. Than, I provide 1.8 V to VPP pin and call:

sudo dfu-util -c 1 -i 0 -a bootloader -D tiboot3.bin

Which provides very similar output to what is expected in https://dev.ti.com/tirex/explore/node?node=A__AfTbl6-QQ9.goHdZtWK8.w__AM62-ACADEMY__uiYMDcq__LATEST

Then, to flash the image, I again reset the device to recovery mode and flash Easy Installer and install image via USB flash disc. My question is: Is this procedure correct? Can I reset the device to recovery mode again or is it wrong? I suppose it would be better to flash the image directly without using "Easy Installer" by Toradex but would this solve the problem?

Thank you.

Matej I.

[sergioprado]

@xistva02 Unfortunatelly, it is not that simple.

You have to follow the AM62X OTP Keywriter User Guide to prepare a development environment with TI tools to create a custom boot container (tiboot3.bin). This boot container should have a custom R5 firmware provided by TI under NDA and your key writer application.

Now, one important thing is that you have to toggle the VPP pin only when writing to the fuses. So this needs to be done in software, in your key writer application.

This is the main() function of my keywriter application for your reference (in my tests, the VPP pin was connected to a GPIO, so I could toggle it in software):

int main()
{
    uint32_t gpio_vpp_base_addr, gpio_vpp_pin;

    System_init();
    Drivers_open();

    DebugP_log("\r\n");
    DebugP_log("Starting Keywriting 1.0\r\n");

    gpio_vpp_base_addr = (uint32_t) AddrTranslateP_getLocalAddr(GPIO_VPP_BASE_ADDR);
    gpio_vpp_pin = GPIO_VPP_PIN;

    GPIO_setDirMode(gpio_vpp_base_addr, gpio_vpp_pin, GPIO_VPP_DIR);

    DebugP_log("Writing to fuses\r\n");
    GPIO_pinWriteHigh(gpio_vpp_base_addr, gpio_vpp_pin);
    keywriter_processKeyConfig();
    GPIO_pinWriteLow(gpio_vpp_base_addr, gpio_vpp_pin);
    DebugP_log("Done!\r\n");

    Drivers_close();
    System_deinit();

    loop_forever();

    return 0;
}

[xistva02]

I followed the guidelines for TI OTP keywriter. The problem was that AM62 V1.1 does not have direct routing to Mallow board V1.1. However, we connected one of the GPIOs to the VPP pin and made custom modification so it satisfies the VPP voltage and power recommendations. Then, we modified the main function in keywriter application as follows:

int main()
{
    System_init();
    Drivers_open();

    DebugP_log("\r\n");
    DebugP_log("Starting Keywriting\r\n");

    keywriter_setVpp();
    DebugP_log("Enabled VPP\r\n");

	keywriter_processKeyConfig();
    DebugP_log("Done Keywriting\r\n");

    keywriter_clearVpp();
    DebugP_log("Disabled VPP\r\n");

    Drivers_close();
    System_deinit();

	loop_forever();

    return 0;
}

and board.c as:

void keywriter_setVpp(){
    uint32_t gpio_vpp_base_addr, gpio_vpp_pin;
    gpio_vpp_base_addr = (uint32_t) AddrTranslateP_getLocalAddr(GPIO_VPP_BASE_ADDR);
    gpio_vpp_pin = GPIO_VPP_PIN;
    GPIO_setDirMode(gpio_vpp_base_addr, gpio_vpp_pin, GPIO_VPP_DIR);
    GPIO_pinWriteHigh(gpio_vpp_base_addr, gpio_vpp_pin);
}

void keywriter_clearVpp(){
    uint32_t gpio_vpp_base_addr, gpio_vpp_pin;
    gpio_vpp_base_addr = (uint32_t) AddrTranslateP_getLocalAddr(GPIO_VPP_BASE_ADDR);
    gpio_vpp_pin = GPIO_VPP_PIN;
    GPIO_setDirMode(gpio_vpp_base_addr, gpio_vpp_pin, GPIO_VPP_DIR);
    GPIO_pinWriteLow(gpio_vpp_base_addr, gpio_vpp_pin);
}

In syscfg, the GPIO settings is:

gpio1.GPIO.$assign         = "GPIO0";
gpio1.GPIO.gpioPin.$assign = "OSPI0_D5";

so we can control it via software to toggle 1.8V for VPP pin. However, when I try to run the fusing process by calling:

sudo dfu-util -c 1 -i 0 -a bootloader -D tiboot3.bin

it does not work. The error in UART is:

Starting Keywriting
Enabled VPP
keys Certificate found: 0x43c15500 
Keywriter Debug Response:0x20 
Error occured... 

Based on Bruno suggestions and guidelines, this seems to be an error during key generation (rather than VPP pin problems) so I assume the keys were generated incorrectly (which is weird as I followed exact steps of Bruno). Can you confirm this?

Thank you.

Matej I.

[sergioprado]

@xistva02 according to [1], it seems the error is indeed with the BMPK key.

[1] https://downloads.ti.com/tisci/esd/latest/2_tisci_msgs/security/keywriter.html#otp-key-writer-error-codes

You can find in keys-ti.zip the development keys I use for testing. Maybe if you test with them, you can confirm if the issue is with your keys, or something else in your process.

[ChethanMaddur]

Hello ,

Is issue is resolved ?
i also facing the same issue, getting the below error, I am using TI default key to fuse , still facing the below error.

Starting Keywriting
Enabled VPP
keys Certificate found: 0x43c15500
Keywriter Debug Response:0x20
Error occured.

[sergioprado]

@ChethanMaddur I am trying to provide some support here, but this is not an issue caused by this layer.

This layer just provide an infrastructure to build a signed image, but fusing the keys is a separated process.

In case you need some support, I would recommend the Toradex community website (https://community.toradex.com/) or getting in touch with TI's support.

[xistva02]

Hello @ChethanMaddur and @sergioprado ,

Today, I was able to make it work. There were several things and processes involved including routing VPP pin from processor (AM62 Verdin V1.1) to one of the GPIOs of Mallow board, customizing the power supply of this GPIO pin to provide stable 1.8V, patching the OTP keywriter binary to toggle VPP pin when fusing process starts and ends (the patch was made for Verdin 1.2 but we made GPIO modifications), creating the keys in a specific way and downloading correct versions of all OTP binaries and additional modules. This issue started as meta-toradex-security layer problem but evolved more to the fusing process. I discussed this issue on toradex community as well, but in a private thread for security reasons. Make sure to ask bruno.tx, as he was extremely useful on this topic.

[sergioprado]

@xistva02 Thanks for the feedback. I am glad to know it worked!