Reflashing closed colibri imx7d

Technical Support
, , , ,
1

Hi,

I’m currently working with the secure boot features introduced in the meta-toradex-security layer for Torizon OS 6.7.0. I successfully managed to close a Colibri iMX7 eMMC device, and now I’m trying to test the full secure boot flow, including recovery scenarios in case of corrupted updates or tampered-with devices.

To do this, I attempted to reflash the device using NXP’s uuu tool, since I know that Toradex Easy Installer doesn’t support closed devices out of the box, mainly because it lacks secure boot signing.

What I’ve Done So Far:

I created a custom signed u-boot.imx based on the colibri-imx7-emmc configuration, that boots and immediately enables fastboot mode. I signed it using the NXP CST tool (v4.0.1), and verified that it boots correctly on the closed device.

During the testing process, something went wrong and my MMC storage got wiped. Now the device doesn’t recognize the expected partitions.

On my pc:
U>CFG: FB: -vid 0x1b67 -pid 0x4027
Start Cmd:CFG: FB: -vid 0x1b67 -pid 0x4027
Okay
U>FB: flash -raw2sparse all recovery/colibri-imx7-emmc.wic
Start Cmd:FB: flash -raw2sparse all recovery/colibri-imx7-emmc.wic
New USB Device Attached at 1:4
0x07000000Variable not implementedinvalid partition or device1:4>Fail invalid partition or device(1.013s)
invalid partition or device

On the imx7 (u-boot):
Colibri iMX7 # fastboot 0
USB EHCI 1.00
Starting download of 16769064 bytes
…
…
downloading of 16769064 bytes finished
** Bad device specification mmc all **
** Bad device specification mmc all **
Couldn’t find partition mmc all

clearly the partitions are not correct anymore, also after trying to reinitialize them:

$ setenv partitions 'uuid_disk=${uuid_gpt_disk};name=boot,start=1MiB,size=64MiB,uuid=${uuid_gpt_boot};name=rootfs,size=100%,uuid=${uuid_gpt_rootfs}'
$ gpt write mmc 0 $partitions

And:

$ gpt repair mmc 0




Long story short:

I’m looking for guidance on how to reinitialize the MMC storage and flash a fresh Torizon image onto the closed device. Specifically:

  • Is it possible to use a .wic image to flash the MMC? If so, how?
  • If not, what specific files from my BitBake build output can I use to manually flash the device?
  • (what are the correct configurations for adding a .wic as artifact in local.conf?)
  • Are there any recommended steps or scripts for flashing a closed device using uuu?

Any help or pointers would be greatly appreciated!

Thanks in advance,
Jippe

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.

Did you like my answer? :+1: :-1:

Recovery for Closed Devices with Secure Boot

Based on the Toradex documentation, here’s guidance for your secure boot recovery scenario:

Understanding Closed Device Limitations

For NXP i.MX devices like your Colibri iMX7, once a device is closed, it will only run software signed with the key(s) associated with the programmed fuse values (1). This is why standard Toradex Easy Installer won’t work on closed devices - it lacks secure boot signing (1).

Alternative Recovery Methods

The documentation recommends the Universal Update Utility (uuu) for U-Boot development on i.MX-based modules (2). This tool (also known as mfgtools 3.0) is provided by NXP and is used to load U-Boot into the RAM of the module for recovery purposes (2).

Key Requirements for Closed Devices

When working with closed devices, remember that:

  • Electronic fuses can only be programmed once – the fusing operations cannot be undone (1)
  • Once a device is closed, it will only run software signed with the key(s) associated with the programmed fuse values (1)
  • A Secure Boot image built for a device in the closed state will only run on a device in that particular state (1)

Recovery Approach

Since you’ve successfully created a signed u-boot.imx that boots on your closed device, you’re on the right track. For your MMC recovery:

  1. Partition Recovery: Your approach with gpt write and gpt repair commands is correct for reinitializing the partition table
  2. Image Flashing: The .wic image format should be compatible, but the partition recognition issues suggest the MMC needs proper initialization first

Key Management Warning

Critical: Ensure you maintain secure access to your signing keys. If you lose the private keys you created to sign your images, you won’t be able to install or update the software on devices that are closed (1). Keep your keys in a safe and secure place, and consider having one or more backups in physically different locations (1).

Additional Resources

For detailed uuu setup and usage examples, the documentation references the official NXP documentation, which provides comprehensive guidance (2).

Since your specific recovery scenario involves complex interactions between secure boot, partition management, and custom tooling, you may need to combine the partition recovery steps with your signed bootloader approach systematically.

Best regards, Toradex AI Assistant.

3

Hello @jippeheijnen,

I would say that the best way to go is to generate a .wic image with Yocto.
This may not be super straight-forward as some customizations could be needed to properly enable this image type with Torizon OS.
The starting point would be to add the .wic image type:

IMAGE_FSTYPES:append = " .wic"

However, I do expect that you will have some errors in a standard Torizon build.
If that is the case, please raise them here so I can support you with that.

Another, less advisable, alternative would be to build a signed version of the Toradex Easy Installer.
This would require less work, but means that you are signing a Linux image which could be used for other purposes other than your application software.

Best Regards,
Bruno

4

Hi Bruno,

Thank you for your reply. I have succesfully generated a .wic image using the yocto / bitbake pipeline. Could you help me with the specific steps on how to flash this file to the imx7d?

Thanks in advance,

Jippe

5

Hello @jippeheijnen,

I expect that the following command should work, provided that you use the bootloader with fastboot enabled:

./uuu -b emmc_all bootloader rootfs.wic

Best Regards,
Bruno

6

Hi @bruno.tx,

I was mistaken actually, the .wic file I had was left over from a previous (manual) attempt.

Whenever I try to put “.wic” in the conf/local.conf I get errors concerning a missing IMAGE_CMD:

ERROR: /home/builduser/yocto/yocto-build-dir/build/conf/../../layers/meta-security/recipes-core/images/security-build-image.bb: No IMAGE_CMD defined for IMAGE_FSTYPES entry '.wic' - possibly invalid type name or missing support class
ERROR: /home/builduser/yocto/yocto-build-dir/build/conf/../../layers/meta-freescale/recipes-fsl/images/fsl-image-mfgtool-initramfs.bb: No IMAGE_CMD defined for IMAGE_FSTYPES entry '.wic' - possibly invalid type name or missing support class
ERROR: Parsing halted due to errors, see error messages above

When I put it as " wic" I don’t get errors anymore, but there are also no wic artifacts.
I read something about the tdx-signed-dmverity.bbclass which removes the wic image_fstype because of a circular dependency, could that be the reason that no files are generated?

furthermore; the wic creation maybe needs a kickstart file, can you tell me more on what this should look like for building a wic compatible with a colibri imx7 emmc?

I tried this for now (located at ../layers/meta-freescale/wic/imx-uboot.wks):

part u-boot --source rawcopy --sourceparams="file=u-boot.imx" --ondisk mmcblk --no-table --align 1
part / --source rootfs --ondisk mmcblk --fstype=ext4 --label root --align 4096

bootloader --ptable msdos

then:

$ wic create imx-uboot -e torizon-core-docker -o output/
...
INFO: Creating image(s)...

INFO: The new image(s) can be found here:
  output/imx-uboot-202509290844-mmcblk.direct

The following build artifacts were used to create the image(s):
  ROOTFS_DIR:                   /home/builduser/yocto/yocto-build-dir/build/tmp/work/colibri_imx7_emmc-tdx-linux-gnueabi/torizon-core-docker/1.0-r0/rootfs
  BOOTIMG_DIR:                  /home/builduser/yocto/yocto-build-dir/build/tmp/work/colibri_imx7_emmc-tdx-linux-gnueabi/torizon-core-docker/1.0-r0/recipe-sysroot/usr/share
  KERNEL_DIR:                   /home/builduser/yocto/yocto-build-dir/build/deploy/images/colibri-imx7-emmc
  NATIVE_SYSROOT:               /home/builduser/yocto/yocto-build-dir/build/tmp/work/armv7at2hf-neon-tdx-linux-gnueabi/wic-tools/1.0-r0/recipe-sysroot-native

INFO: The image(s) were created using OE kickstart file:
  /home/builduser/yocto/yocto-build-dir/build/conf/../../layers/meta-freescale/wic/imx-uboot.wks

which generates the following files:

$ l output/
imx-uboot-202509290844-mmcblk.direct     imx-uboot-202509290844-mmcblk.direct.p1
imx-uboot-202509290844-mmcblk.direct.p0

Then, I have some more progress and questions about the flashing progress:

  • when trying your command the process hangs here:
recovery\uuu -b emmc_all u-boot-signed.imx imx-uboot-202509290819-mmcblk.direct
uuu (Universal Update Utility) for nxp imx chips -- libuuu_1.5.165-0-g7347a80

Success 0    Failure 0


1:4      1/ 1 [=================100%=================] SDP: boot -f u-boot-signed.imx -scanlimited 0x800

But when I manually enter the commands one by one, I get the following error on the device:

** Bad device specification mmc all **
** Bad device specification mmc all **
Couldn't find partition mmc all

This suggests that the mmc is not partitioned correctly, maybe you can help me with the steps to reset the mmc to the partitions uuu expects?

Thanks in advance,

kind regards,
Jippe

7

Hello @jippeheijnen,

Sorry for the mistake, as you used " wic" is correct.

One thing that I can mention is that the .wic file should only contain the partitioning for the rootfs.
The bootloader is defined in imx-uboot.wks and this could be causing the problems.

We need to look into this topic in more detail to provide direct steps.
I will be unavailable in the middle of this week, so I will ask for one of my colleagues to take a look at this.

Best Regards,
Bruno

8

Thank you very much for your help so far @bruno.tx,

Looking forward to hearing from your colleague.

Kind regards,

Jippe

9

Hi @jippeheijnen,

Since Bruno is currently unavailable, I will share some information I gathered from our R&D team. The first solution they pointed out is to get a wic image from your build. I see that you have already tried that out and facing some issues. I think Bruno will be able to give help you unblock on that topic when he is back.

The other thing is, a workaround: using a signed bootloader to load Toradex Easy Installer and then just flash signed images as normal. This is a thread that explains the procedure: Toradex Easy installer downloading failed on closed device (HAB)- Colibri-i.MX7
Do you think that could be a solution for you?

10

Hi @rudhi.tx,

Thanks for your suggestion! I tried to follow the steps at an earlier date, and that is how I got my signed u-boot bootloader (u-boot-signed.imx).

However, that post dates back to 2020, and the proposed defconfig (colibri_imx7_tezi_recovery_defconfig) is not present in the 2024.07 branch.

What defconfig should I use instead?

Thanks in advance,

Jippe

12

[edit]
The article you suggested uses (I think) HABv3 that has the “security Configuration = Open”. It seems like this isn’t supported anymore by the HABv4 since that is the eFuses’ job now.

So building a Yocto project with the meta-toradex-tezi layer would seem to be the only way forward now.. Maybe you can help me get started with that?

Thanks in advance!

Jippe

13

Hi @jippeheijnen,

Before we get too much into the topic of loading the Toradex Easy Installer.
Did you try to look into this direction?

Best Regards,
Bruno

14

Hello @jippeheijnen,

Were you able to get this resolved?
Or do you still need support with this topic?

Best Regards,
Bruno

15

Hi @bruno.tx,

Maybe you could help me with the easy installer method? It would seem that implementing the secure boot into the easy installer would be easier than all the manual u-boot steps.
correct me if I’m wrong
Jippe

16

Hello @jippeheijnen,

Sure, that would be an alternative.
To build the Toradex Easy Installer Image, you need to follow a very similar setup as when using our Yocto BSP.
Here is an example for Toradex Easy Installer 7.4.0:

  • Get the source code:
repo init -u git://git.toradex.com/toradex-manifest.git -b refs/tags/7.4.0 -m tezi/default.xml
repo sync
  • Source the environment script:
. export
  • Run the build:
MACHINE=colibri-imx7 bitbake tezi-run

To sign this image so that it can be loaded to a closed device, you will need to add meta-toradex-security and do the setup at least for a basic chain of trust using HAB.

If you face any issues, please feel free to reach out.

Best Regards,
Bruno

17

@bruno.tx,

Unless primary boot image doesn’t use DCD, meta-toradex-security as is won’t help. On colibri-imx7d DCD is used to setup DDR RAM. And since DCD is used, you need specially signed image to boot using uuu/imxusb. Image for native boot, image for uuu, and image for imxusb need to use different csf files, in addition imxusb needs to clear DCD pointer prior to signing, sign image and restore DCD pointer in it.

You may sign/resign already compiled U-Boot image, no matter was it signed already or not, no matter what were U-Boot config settings. You need HAB certificates, which match your closed device fuses. All required size and address settings for csf file may be read from already compiled U-boot image IVT table, which is easy to find at standard offsets 0/0x400/0x1000. Script for such re-sign could take required addresses and sizes from existing image, create csf, perhaps cut image at the end to overwrite old zero-pad area or old csf data and put the new signing data there.