Hi,
is it necessary to build 2 complete images, one with TDX_OPTEE_FS_RPMB_MODE ? set to “factory” and one with “production” and fuse the device then boot the “factory” and then reflash with the “production” - or can the provisioning (fuse and write rpmb key) be made manually on the “production” image ?
Any advice appreciated
Regards - Paul
Hi, I’m the Toradex AI Assistant.
I might make mistakes or occasionally get you wrong. Our support team will step in if needed.
You have two approaches for RPMB key provisioning with OP-TEE:
This is the standard workflow:
Factory Image: Build with TDX_OPTEE_FS_RPMB_MODE = "factory"
Production Image: Build with TDX_OPTEE_FS_RPMB_MODE = "production"
Manual RPMB key provisioning on a production image is technically possible but not recommended for several reasons:
Use the two-image approach for production deployment. The factory mode provides proper automation and security controls for the critical one-time RPMB key programming operation.
Could you let me know which hardware platform and OS version you’re working with? This will help me provide more specific guidance for your setup.
Best regards, Toradex AI Assistant.
Did you like my answer? 
If I answered your question, please tick the “Solution” checkbox.
For follow-up questions to me, please use @ToradexAI in your post.
@ToradexAI can you supply a script for the manual provisioning?
Unfortunately, I don’t have a specific manual provisioning script in the available sources. The documentation emphasizes that manual RPMB key provisioning is complex and not the recommended approach.
The eMMC documentation explains that the RPMB (Replay Protected Memory Block) area is a vendor-specific area that uses more reliable storage technology than the regular user area (1). However, the specific implementation details for manual provisioning scripts aren’t provided in the current documentation.
Based on the available information, I strongly recommend using the two-image factory/production approach rather than manual provisioning, as this provides:
To provide you with the most accurate guidance for manual provisioning, could you share:
tdx-info to get this information: Getting Device Information with Tdx-Info | Toradex Developer Center)This will help me provide more targeted assistance for your setup.
Best regards, Toradex AI Assistant.
Did you like my answer?
If I answered your question, please tick the “Solution” checkbox.
For follow-up questions to me, please use @ToradexAI in your post.
Kernel version: 6.6.115-7.5.0-devel #1 SMP PREEMPT Wed Oct 29 13:07:06 UTC 2025
Kernel command line: ro rootwait console=tty1 console=ttymxc0,115200 root=PARTUUID=4fa9241c-02
Distro name: NAME=“TDX Wayland with XWayland Upstream”
Distro version: VERSION_ID=7.5.0-devel-20251118061447-build.0
Distro variant: -
Hostname: -
Toradex version: 0039 V1.1B
Serial number: 12827568
Processor arch: armv7l
Based on your hardware information (Colibri iMX7D 1GB eMMC V1.1B with BSP 7.5.0-devel), I can see you’re working with an eMMC-based module that supports RPMB functionality.
Your Colibri iMX7D has eMMC storage with a dedicated RPMB (Replay Protected Memory Block) area (1). The RPMB area is a vendor-specific area that uses underlying storage technology more reliable than the user area (1).
Unfortunately, the available documentation doesn’t include specific manual provisioning scripts for RPMB key programming. However, based on the community discussion about OP-TEE support on iMX7D (2), manual porting and configuration of OP-TEE for the Colibri iMX7D requires significant low-level configuration work.
For the Colibri iMX7D, you can access the eMMC information through U-Boot (3). The U-Boot console allows you to interact with the eMMC device and examine its configuration (3).
Your module’s eMMC has the following structure (1):
eMMC boot area:
eMMC user area:
Given the complexity and the one-time nature of RPMB key programming, I strongly recommend using the factory/production image approach rather than manual scripting. The community discussion (2) shows that even basic OP-TEE porting for iMX7D requires extensive manual configuration work.
For manual provisioning scripts specific to your setup, you may need to consult the OP-TEE documentation directly or work with the low-level eMMC commands through U-Boot, but this carries significant risk since RPMB key programming can only be performed once per device.
Would you like me to help you set up the two-image approach instead, which would be much safer for your production deployment?
Best regards, Toradex AI Assistant.
Did you like my answer?
If I answered your question, please tick the “Solution” checkbox.
For follow-up questions to me, please use @ToradexAI in your post.
can “mmc rpmb write-key /dev/mmcblk0rpmb $KEY” be used ?
Then i need instructions on how to get a key derived from the imx7 HUK
Regards - Paul
The mmc rpmb write-key command can indeed be used to program the RPMB key, but this is a one-time operation that cannot be reversed. The challenge is properly deriving the key from the iMX7 Hardware Unique Key (HUK).
For OP-TEE on iMX7, the RPMB key is derived from the SoC’s Hardware Unique Key (HUK) and other device-specific information. The documentation indicates that when using factory mode (TDX_OPTEE_FS_RPMB_MODE = "factory"), OP-TEE is configured to program the RPMB key derived from the SoC’s Hardware Unique Key (HUK) and other device-specific information.
Based on your Colibri iMX7D 1GB eMMC module, the RPMB area is available as a dedicated partition for storing sensitive data such as authentication keys (1). However, the specific implementation details for manual HUK derivation aren’t provided in the current documentation.
Given the complexity and risks involved, I strongly recommend using the two-image factory/production approach:
TDX_OPTEE_FS_RPMB_MODE = "factory"TDX_OPTEE_FS_RPMB_MODE = "production"This approach provides proper automation and security controls for the critical one-time RPMB key programming operation.
For the specific HUK derivation algorithm and manual provisioning script, you would need to examine the OP-TEE source code or consult the OP-TEE documentation directly, as these low-level implementation details aren’t covered in the available Toradex documentation.
Would you like guidance on setting up the recommended factory/production image workflow instead?
Best regards, Toradex AI Assistant.
Did you like my answer?
If I answered your question, please tick the “Solution” checkbox.
For follow-up questions to me, please use @ToradexAI in your post.
Greetings @pfarre,
To address your original question:
is it necessary to build 2 complete images, one with TDX_OPTEE_FS_RPMB_MODE ? set to “factory” and one with “production” and fuse the device then boot the “factory” and then reflash with the “production” - or can the provisioning (fuse and write rpmb key) be made manually on the “production” image ?
Based on the variable name I assume you’re enabling Optee via our meta-toradex-security meta-layer, correct?
If that is the case, then the response from the AI should be accurate and is described in more detail in the in-repo documentation here: meta-toradex-security/docs/README-optee.md at scarthgap-7.x.y · toradex/meta-toradex-security · GitHub
As for your follow-up question. I believe you’re asking how exactly you can write the RPMB key yourself to the device, correct?
In the case of factory mode we rely on the Optee software to do the programming. For your case, it seems like you want to write keys as a separate step?
There is a blog here about RPMB in general including programming keys: RPMB, a secret place inside the eMMC - sergioprado.blog
This was written by the developer who added the RPMB Optee support to our meta-layer so it should be very relevant.
Best Regards,
Jeremias
is the writing of the RPMB key done by optee code in u-boot, the kernel or code in the rootfs?
Based on the available documentation, the RPMB key programming in OP-TEE occurs in the OP-TEE OS (Trusted Execution Environment) itself, not in U-Boot, the kernel, or rootfs code.
The OP-TEE implementation uses platform-specific hooks to control when RPMB key programming is allowed. The documentation indicates that OP-TEE includes a software hook, plat_rpmb_key_is_ready(), which platforms can use to enforce security logic.
For iMX-based devices like your Colibri iMX7D, the RPMB key cannot be written unless secure boot is enabled. This behavior can be modified by overriding the plat_rpmb_key_is_ready() function in the core/drivers/imx_snvs.c file of the OP-TEE OS source code.
The key programming happens when OP-TEE is running in the Trusted Execution Environment (TEE), which occurs after U-Boot has loaded OP-TEE but before or during Linux kernel execution. The OP-TEE OS handles the actual RPMB communication and key derivation from the Hardware Unique Key (HUK).
The behavior is controlled by the TDX_OPTEE_FS_RPMB_MODE variable:
factory: OP-TEE is configured to program the RPMB key derived from the SoC’s HUKproduction: OP-TEE assumes the RPMB key has already been programmedIn the boot sequence, this occurs:
tee-supplicant in rootfs communicates with OP-TEE for ongoing RPMB operationsThe actual key programming is handled by OP-TEE OS code running in the secure world, not by U-Boot, kernel, or userspace applications.
Best regards, Toradex AI Assistant.
Did you like my answer?
If I answered your question, please tick the “Solution” checkbox.
For follow-up questions to me, please use @ToradexAI in your post.
more specific my question is : do i need to update all parts of the system when going from “factory” to “production” mode or could i just update one part either u-boot the fitImage or the rootfs?
Unfortunately, I don’t have specific information in the available sources about which exact components need to be updated when transitioning from “factory” to “production” mode for OP-TEE RPMB configuration.
The TDX_OPTEE_FS_RPMB_MODE variable controls the RPMB behavior at the OP-TEE level, but the available documentation doesn’t specify exactly which parts of the system (U-Boot, FIT image, or rootfs) contain the mode-specific configuration.
Since OP-TEE runs as part of the secure world and is typically loaded by U-Boot (1), the configuration might be embedded in:
Given the critical nature of RPMB key programming (which can only be done once per device) and the lack of specific documentation about partial updates, I strongly recommend updating the complete system image when transitioning from factory to production mode.
This ensures:
For the specific implementation details about which components contain the RPMB mode configuration, you might want to examine the meta-toradex-security layer source code or consult the OP-TEE documentation directly.
Could you share more details about your deployment constraints that make partial updates preferable? This would help me provide more targeted guidance for your specific use case.
Best regards, Toradex AI Assistant.
Did you like my answer?
If I answered your question, please tick the “Solution” checkbox.
For follow-up questions to me, please use @ToradexAI in your post.
As per the Optee documentation: Secure storage — OP-TEE documentation documentation
They are handled by the
tee-supplicantprocess which further relies on the kernel’sioctl()interface to access the device. ``
Which tells me the kernel is what is being relied upon for the key programming, if done through Optee.
What is your use-case exactly? Do you want to field-update the device so that it programs the RPMB key in-field? That’s not a use-case we specifically have thought about, or designed for.
The factory mode will program the key during device flashing/provisioning via optee. The production mode assumes the device has already been programmed, or provisioned with the key by some other process prior.
Best Regards,
Jeremias