Hi,
i get the following warning when booting - and it seems that i cant access sdp on another module where i locked the secure boot.
Colibri iMX7 # sdp
## WARNING: Command execution WOULD BE DENIED in closed state (blocked by category) for `s dp`.
sdp - Serial Downloader Protocol
Its Yocto build for imx7D 1G with eMMC meta-toradex-security.
I have tried setting
TDX_SECBOOT_WL_ALLOW_CLOSED_CATEG = "CMD_CAT_ALL_SAFE"
Are there other CMD_CAT_xxx to be set ?
Any suggestions how to be sure the next module does not get blocked ?
(I also have problems to get EasyInstaller to work with my signed bootloader - but thats another story)
Best Regards Paul
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? 
Hello Paul,
You’re observing expected behavior related to secure boot on your Colibri iMX7. When the device is in the closed (secure) state, access to certain commands—including SDP (Serial Downloader Protocol)—is deliberately blocked for security reasons. This restriction is intended to prevent unauthorized access to the boot process once secure boot is enforced and the closing fuse is set. The warning you see during boot confirms that the command would be denied when the fuses are actually closed.
A few key points to consider:
-
The variable TDX_SECBOOT_WL_ALLOW_CLOSED_CATEG = "CMD_CAT_ALL_SAFE" sets which bootloader command categories are permitted in closed state, but SDP falls into a category that is generally not allowed for security. There are no additional CMD_CAT_xxx values you can configure to enable SDP in closed state because this protocol is specifically restricted once secure boot is finalized.
-
This behavior is by design and listed as a key secure boot feature: after fuses are closed, only properly signed bootloaders and verified images will be accepted, and specific low-level interfaces like SDP are irreversibly disabled (1).
To avoid getting further modules blocked:
- Test Before Closing Fuses: Always thoroughly validate your secure boot implementation, signed bootloaders, and overall system configuration before setting the irreversible closing fuses. Use test boards or enable secure boot in “open” state to verify everything.
- Sign All Images Correctly: Ensure all bootloader images and other components used in the boot chain are properly signed according to your secure boot process.
- Familiarize Yourself With Locked State Limitations: Once a module is in the closed state, interfaces like SDP and custom unsigned bootloaders will not be available. It’s also not possible to use tools like Easy Installer, since it requires loading its own bootloader—which cannot occur on a locked device (1).
Summary: There is no configuration or CMD_CAT_xxx value that will allow SDP after the device is closed for secure boot. Be sure to complete all testing and provisioning prior to closing fuses. After that, only signed images and a locked boot chain are permitted by design.
If you need more in-depth guidance on secure boot flow for Colibri iMX7, please let me know.
Best regards,
Toradex AI Assistant.
If the AI is correct i dont really understand this
cannot-use-toradex-easy-installer-with-closed-device
What am i missing here?
Greetings @BDSKPEF,
I believe you want to do:
TDX_SECBOOT_WL_ALLOW_CLOSED_CATEG = "CMD_CAT_ALL_SAFE CMD_CAT_GADGETSDP "
Notice the sdp command has the CMD_CAT_GADGETSDP group assigned to it: meta-toradex-security/recipes-bsp/u-boot/files/0001-toradex-common-add-shared-hardening-modules.patch at 8646da8e4686fdfcb54eb7abfea2d7489fd48303 · toradex/meta-toradex-security · GitHub
Do you require the sdp command in production by the way? This is a potentially unsafe command to allow in a secure configuration.
What am i missing here?
If you close your device by setting the secure-boot fuses including the final closing fuse, then Toradex Easy Installer will no longer work out of the box. This is because Easy Installer will try to load an unsigned bootloader, but since the device is closed it will no longer accept such unsigned bootloaders.
Best Regards,
Jeremias
Hi Jeremias,
getting the patch and adding CMD_CAT_GADGETSDP does the first part of the trick.
I am aware that a signed bootloader is needed.
For my next problem i can chose either
-
that after uuu has downloaded the signed bootloader from my normal YOCTO project USB still has Vendor ID 0x1b67 but Product ID is 0x4027 in stead of 0x4000. It is not enough to change the uuu.auto file because Windows wont change the driver for the device to “ADB device” .
-
if i build a separate signed bootloader according to the link the console output is
U-Boot 2016.11-00004-g0ed64e49e55 (Jun 12 2025 - 07:42:09 +0200)
CPU: Freescale i.MX7D rev1.3 996 MHz (running at 792 MHz)
CPU: Extended Commercial temperature grade (-20C to 105C) at 41C
Reset cause: POR
DRAM: 512 MiB
PMIC: RN5T567 LSIVER=0x01 OTPVER=0x0d
MMC: FSL_SDHC: 0
Using default environment
In: serial
Out: serial
Err: serial
Model: Toradex Colibri iMX7S/D
Model: Toradex Colibri iMX7D
Serial Downloader recovery mode, using sdp command
Net: FEC0
Error: FEC0 address not set.
Hit any key to stop autoboot: 0
SDP: initialize...
SDP: handle requests...
and - windows output is
Downloading Toradex Easy Installer...
uuu (Universal Update Utility) for nxp imx chips -- libuuu_1.5.165-0-g7347a80
Success 0 Failure 1
1:1324 1/ 7 [Bulk(W):LIBUSB_ERROR_NOT_FOUND ] FB: download -f ../overlays.txt
ECHO is off.
Downloading Toradex Easy Installer failed...
Press any key to continue . . .
event though the PID in this case is 0x4000
For my next problem i can chose either
Okay, so now we’re talking about a new topic correct? The ability to re-flash a device that has been closed by secure boot.
At the moment this is something we haven’t invested time into investigating yet. It’s a bit of a controversial topic. Since essentially it’d be like creating a way to get around the security provided by secure-boot to re-flash a device. We’re still discussing internally if there is a more secure way to go about this, or if it’s even something that should be practically done.
For your use-case do you imagine you’ll be re-flashing devices after they have been closed? If so for what reasons, or purposes do you imagine this occurring?
Best Regards,
Jeremias
Yes, but part of the same goal - to have a “fail safe” update/recovery method that both our service technichians and production can use independant of the module state.
I hav 3 sessions with your colleagues the next 14days so the plan might change 
and the “new” topic might be solved through the difference in u-boot config CONFIG_G_DNL…
#
# USB peripherals
#
CONFIG_USB_STORAGE=y
# CONFIG_USB_KEYBOARD is not set
CONFIG_USB_GADGET=y
# CONFIG_USB_GADGET_ATMEL_USBA is not set
# CONFIG_USB_GADGET_BCM_UDC_OTG_PHY is not set
# CONFIG_USB_GADGET_DWC2_OTG is not set
CONFIG_CI_UDC=y
CONFIG_USB_GADGET_VBUS_DRAW=2
CONFIG_USB_GADGET_DUALSPEED=y
CONFIG_USB_GADGET_DOWNLOAD=y
CONFIG_USB_FUNCTION_SDP=y
CONFIG_G_DNL_MANUFACTURER="Toradex"
CONFIG_G_DNL_VENDOR_NUM=0x1b67
CONFIG_G_DNL_PRODUCT_NUM=0x4000
So for now i’ll mark your first reply which is the solution to the topic headline.
Thanks!
So for now i’ll mark your first reply which is the solution to the topic headline.
Very well then. Glad I was able to assist.
Best Regards,
Jeremias
