STM32MP257F-EV1 - CM33 Firmware Signing Key Issue - OpenSTLinux v26.02.18"

[Radha Kadam]

CM33 FIRMWARE SIGNING KEY MISMATCH
---

We have successfully flashed OpenSTLinux v26.02.18 with the full optee layout and confirmed:
- remoteproc0 fw_format = TEE
- The pre-built example firmware (USBPD_DRP_UCSI_CM33_NonSecure_sign.bin) loads and runs correctly
- STM32CubeIDE debugger successfully attaches to the running CM33

However, when we sign our own CM33 firmware using sign_rproc_fw.py, OP-TEE rejects it:

   tee_remoteproc: TA_RPROC_FW_CMD_LOAD_FW invoke failed TEE err: ffff0006
   remoteproc remoteproc0: Boot failed: -5

Error 0xffff0006 = TEE_ERROR_SECURITY (signature verification failure)

Signing command used:
   python3 sign_rproc_fw.py --in CM33_LED_CM33_NonSecure.elf --out CM33_LED_sign.bin --key default.pem

Keys tried (all have identical MD5: c5254a254e63da936a640d0a0093bcf0):
- STM32CubeMP2-1.3.0/Utilities/optee_os/keys/default.pem
- sdk/sysroots/cortexa35-ostl-linux/usr/include/optee/export-user_ta_arm64/keys/default.pem
- sdk/sysroots/cortexa35-ostl-linux/usr/include/optee/export-user_ta_arm64/keys/default_ta.pem
- sdk_x86_installed/.../keys/default.pem

We also tried flashing with the opteemin layout hoping it uses the development key, but found that the opteemin image does NOT include the remoteproc OP-TEE TA (80a4c275-0a47-4905-8285-1486a9771a08.ta), so remoteproc stays in deferred probe state.

Questions:
1. What is the correct signing key (.pem file) to use with sign_rproc_fw.py for CM33 firmware on OpenSTLinux v26.02.18 with the full optee layout?
2. Where can we obtain the private key that matches the OP-TEE remoteproc TA built into the v26.02.18 flash image?
3. Is there a recommended development workflow for signing and loading custom CM33 NonSecure firmware with v26.02.18?
4. Does the opteemin layout support custom CM33 firmware loading? If yes, what is the correct procedure?

[Christophe Guibout]

Hello ​@Radha Kadam,

I would suggest to have a look into this wiki page which could help : sign_rproc_fw.py needs more parameters.

BR,

Christophe

[Radha Kadam]

1. Signed Firmware Analysis

We compared our generated CM33 signed firmware with the signed example binaries provided in the OpenSTLinux SDK.

• We verified that the generated binary contains an STM32 signed image header (magic value 68 A4 43 35).
• We compared the header structure against ST example signed binaries such as:
  • LowPower_SRAM_Demo_CM33_NonSecure_sign.bin
  • USBPD_DRP_UCSI_CM33_NonSecure_sign.bin
• The overall format appears similar to the ST examples.

However, when attempting to validate both our generated binary and the ST example binaries using:

STM32_SigningTool_CLI -dump <signed_binary>

the tool reports:

Error: Cannot parse header with corrupted data !

for both our binary and the ST example binaries.

2. Firmware Transfer Verification

To eliminate transfer corruption concerns:

• We encoded the signed firmware using Base64 on the host PC.
• Transferred the data to the target board.
• Reconstructed the binary on the target.
• Compared file sizes and line counts during reconstruction.

During testing we discovered an incomplete transfer and corrected it by rebuilding the Base64 file. The reconstructed binary size on the host was:

42036 bytes

and the binary header appeared valid when inspected with hexdump.

3. Remoteproc / TEE Behavior

The STM32MP257 board reports:

cat /sys/class/remoteproc/remoteproc0/fw_format

Output:

TEE

When attempting to boot the firmware through remoteproc, we observe:

tee_remoteproc ... TA_RPROC_FW_CMD_LOAD_FW invoke failed
TEE err: ffff0006
Boot failed: -5

and in another case:

loading /lib/firmware/<firmware>.bin failed with error -22
request_firmware failed: -22
Boot failed: -22

This indicates the firmware is being validated through the TEE path and is rejected before execution.

4. Ethernet Investigation

Following your recommendations, we also investigated the Ethernet configuration.

Findings:

• ETH2 (end0) is detected correctly.
• Link status is UP.
• PHY negotiation succeeds at 100 Mbps Full Duplex.
• Carrier status reports 1.
• We assigned a static IP address:

192.168.1.200/24

and configured a default route.

However:

• The board cannot resolve ARP entries for the PC.
• ip neigh shows FAILED entries.
• Ping requests fail with "Destination Host Unreachable".

This appears to be a separate network configuration issue and not directly related to the M33 firmware loading problem.

Current Status

At this stage:

1. The board successfully reaches the TEE remoteproc loading stage.
2. The firmware is rejected by the TEE firmware loading mechanism.
3. The rejection occurs even after rebuilding and verifying the transferred firmware image.
4. We are unable to determine whether the failure is caused by:
   • an image-signing issue,
   • a key mismatch,
   • a TEE configuration issue,
   • or a remoteproc firmware format requirement specific to STM32MP257.