UUU Android Flashing on i.MX95 Verdin EVK Fails During SDPS Boot (SW2=1,0,0,1 Confirmed)

Technical Support
1

Hello Toradex Support Team,

I am trying to flash the official NXP Android BSP onto an i.MX95 (B0) Verdin Evaluation Kit, but the flashing process consistently fails during the SDPS (USB Download) boot stage.

NXP Support advised that:

  • The board must be set to Download Mode (SDPS) before flashing

  • Boot switch / DIP switch configuration for Verdin EVK is not provided by NXP, and should be confirmed with Toradex

Therefore, I am contacting Toradex for board-specific guidance.

Please note that the SDPS mode configuration has already been applied and verified, as described below.

Environment

  • Board: i.MX95 Verdin Evaluation Kit

  • SoC: i.MX95 (B0)

  • OS Image: Android 16.0.0_1.2.0 (official NXP release)

  • Flashing Tool: UUU (Universal Update Utility)

  • Script: uuu_imx_android_flash.sh (from NXP Android BSP)

  • UUU Version:

    • Script validated for: 1.5.201

    • Actual binary used: 1.5.233

  • Flash Target: Verdin

  • Connection: USB (SDPS)

  • microSD card: not inserted

SDPS (Download) Mode Configuration (Already Applied)

The SW2 DIP switch on the Verdin EVK is configured as follows : SW2 = 1, 0, 0, 1

With this setting:

  • The board enters SDPS (USB Download) mode

  • The USB device is detected correctly by the host PC

  • UUU successfully reaches the SDPS phase

Therefore, this issue is not caused by missing or incorrect SDPS mode configuration.

Commands Executed

Based on NXP Support recommendations, I have already tested both commands below:

sudo ./uuu_imx_android_flash.sh -f imx95 -u verdin-uuu -c 13

sudo ./uuu_imx_android_flash.sh -f imx95 -a -e -u trusty-verdin-dual -c 13

The issue occurs consistently with both commands.

Linux Host Result

uuu (Universal Update Utility) for nxp imx chips – libuuu_1.5.233-0-g79ce7d2 Success 0 Failure 1 [HID(W): LIBUSB_ERROR_NO_DEVICE (-4)] SDPS: boot -f u-boot-imx95-verdin-uuu.imx

During SDPS: boot, the USB device disconnects and flashing aborts.

Windows Host Result

uuu (Universal Update Utility) for nxp imx chips – libuuu_1.5.233-0-g79ce7d2 Success 0 Failure 1 [HID(W): LIBUSB_ERROR_PIPE (-9)] SDPS: boot -f u-boot-imx95-verdin-uuu.imx.link

The failure occurs at the same SDPS boot stage, with a different USB error code.

Observations

  • The issue occurs on multiple Verdin EVK boards

  • Reproducible on both Linux and Windows hosts

  • USB cable and port changes do not resolve the issue

  • The USB device briefly disconnects during SDPS boot

  • The failure always occurs at: SDPS: boot -f u-boot-imx95-verdin-uuu.imx

Summary of NXP Support Feedback

  • Android flashing requires Download Mode (SDPS)

  • Boot switch configuration for Verdin EVK is handled by Toradex

  • UUU version 1.5.233 should be compatible

  • Recommended command:

    sudo ./uuu_imx_android_flash.sh -f imx95 -a -e -u trusty-verdin-dual

    (already tested, no improvement)

  • Advised to contact Toradex Support

Questions for Toradex

  1. Is the SW2 = 1,0,0,1 setting the correct and complete configuration to enter SDPS mode on the i.MX95 Verdin EVK?
    Are there any additional board-specific requirements?

  2. Are there any known USB / SDPS stability issues on i.MX95 Verdin during the transition from SDPS to U-Boot execution?

  3. Is a microSD card required or recommended when flashing Android to onboard storage on Verdin EVK?

  4. For Android flashing on i.MX95 Verdin, is uuu_imx_android_flash.sh the recommended procedure, or should fastboot_imx_flashall.sh be used instead?

  5. Are there any power-up sequencing, reset timing, or USB connection best practices recommended for reliable SDPS flashing on Verdin EVK?

Any guidance on the correct flashing procedure or required hardware/software setup would be greatly appreciated.

Thank you very much for your support.

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.

I understand you’re trying to flash Android onto the i.MX95 Verdin EVK and encountering SDPS boot failures. While I can see you’ve done thorough testing, I need to clarify our support scope for this specific use case.

Android Support Status

The i.MX95 Verdin EVK currently shows “Coming Soon” for Android support (1). While the hardware specifications indicate Android will be “Supported via Partners” (1), this suggests that direct Android flashing support may not be fully available yet through standard Toradex procedures.

Boot Configuration Information

Regarding DIP switch configurations for boot modes, our documentation covers U-Boot console access where U-Boot waits up to 3 seconds before continuing with the boot process (2), and there are examples of using DIP switches to modify boot processes (3). However, the specific SDPS mode configuration you’re using (SW2 = 1,0,0,1) isn’t detailed in the available documentation.

Recommended Next Steps

Given that you’re working with:

  • An evaluation kit with Android support still listed as “Coming Soon” (1)
  • Official NXP Android BSP (not Toradex software)
  • SDPS flashing procedures outside our standard workflow

I’d recommend:

  1. Verify Android readiness: Confirm with our sales team if Android support is fully available for the i.MX95 Verdin EVK
  2. Partner network consultation: Since Android is listed as “Supported via Partners” (1), consider connecting with our partner network for specialized Android integration support
  3. Alternative approach: Consider starting with Torizon OS, which has full support, then evaluating Android migration once official support is confirmed

Contact Information

For hardware-specific questions about the i.MX95 Verdin EVK and Android readiness, I’d suggest:

  • Visiting our Community for peer discussions
  • Checking our GitHub repositories for any Android-related updates

The SDPS boot failures you’re experiencing may be related to the current Android support status rather than hardware configuration issues.

Best regards, Toradex AI Assistant.

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

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

3

Hi Toradex AI Assistant,

Thank you for your response. I’d like to clarify the point about the SDPS mode (SW2 = 1,0,0,1) not being documented.

We referenced the Toradex i.MX 95 Verdin EVK Datasheet, specifically Section 2.3 Boot Configuration / Table 16: SW2 Boot Modes, which states that SW2 = 1 0 0 1 corresponds to “M33 Serial downloader USB1/2 (SDPS)”. This is why we attempted flashing in SDPS (serial download) mode.

In addition, our flashing procedure follows the NXP Android Quick Start Guide (UG10157), specifically the installation steps for the i.MX 95 Verdin EVK described on page 67.

All steps and switch settings described from that page onward have been executed exactly as documented, including:

  • Setting the board to SDPS (serial download) mode

  • Connecting the USB Type-C cable to the host PC

  • Following the documented power-on sequence

  • Running uuu_imx_android_flash.sh using the documented options

Therefore, the flashing process was carried out strictly according to the official documentation, without introducing any undocumented or custom procedures.

However, during the SDPS boot stage, we consistently observe the following message on the host side, and it coincides with the USB disconnection:

disabled by hub (EMI?), re-enabling…

This suggests that the USB port is being temporarily disabled and re-enabled by the host USB hub (possibly due to EMI or a bus reset), rather than being a simple software-level UUU issue. The main concern appears to be the USB disconnection occurring during the transition from SDPS to U-Boot.

As you mentioned, the boot switch configuration and board-specific behavior of the Verdin EVK are managed by Toradex. With that in mind, we would appreciate further investigation or guidance on this issue—especially regarding the USB disconnect during SDPS → U-Boot transition, including whether this is a known issue and if any recommended settings or workarounds exist.

References:

Best regards,

4

Thank you for the clarification and for providing the specific documentation references. I appreciate you pointing out the official Toradex datasheet section and the NXP Android Quick Start Guide details.

Current Documentation Status

Based on the available information sources, the i.MX95 Verdin EVK documentation appears to be under restricted access. As mentioned in our community discussions, “the iMX95 EVK documentation is under NDA so you will need to request that on the NXP site” (1). This explains why the specific boot configuration details you’re referencing from the datasheet aren’t available in my current documentation set.

Android Support Status

The current status shows Android as “Coming Soon” for the i.MX95 Verdin EVK (2). While the hardware specifications indicate Android will be “Supported via Partners” (2), this suggests the Android implementation may still be in development or requires specialized partner support.

USB Disconnection During SDPS Transition

The USB disconnection issue you’re experiencing during the SDPS to U-Boot transition, particularly the “disabled by hub (EMI?), re-enabling…” message, suggests a hardware-level USB enumeration problem rather than a software configuration issue. This type of behavior often occurs when:

  • The USB device changes its configuration during boot transitions
  • Power consumption spikes during the boot process
  • EMI interference affects USB communication
  • The host USB controller resets the connection

Recommended Next Steps

Given the NDA-restricted documentation and the specialized nature of Android flashing on the i.MX95 EVK:

  1. Access NDA Documentation: Follow the process to Sign an NDA with NXP to access the complete i.MX95 EVK documentation (1)

  2. Early Access Community: Once you have a valid NDA, you’ll be given access to the “iMX95 EVK Early Access Toradex community” (1) where you can get specialized support for this specific hardware

  3. Partner Network: Since Android is listed as “Supported via Partners” (2), consider engaging with our partner network for Android-specific integration support

  4. Hardware Investigation: For the USB disconnection issue, you might want to try:

    • Different USB cables and ports
    • External powered USB hubs
    • Different host machines to isolate EMI issues

The fact that you’re following the official NXP documentation precisely suggests this may be a known limitation or require specific workarounds that are documented in the NDA-protected materials.

Best regards, Toradex AI Assistant.

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

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

5

Dear @kubota , sorry for the delay. Let me answer your questions

This is not correct. Please check: 4.2 Installing NXP’s Full Reference Image in the Verdin iMX95 EVK Getting started guide (V0.8). It could be that the system is entering into SDPS mode but failing to load the complete system because of this setting.

If your goal is to flash the OS: The DIP Switch SW2 should be already correctly configured to boot from the eMMC. Please make sure it’s setup as 1010. Then press the Recovery Button B8 while powering on the board.

While there are no known USB / SDPS stability issues for the i.MX95 EVK, there are some general recommendations:

  • You are using a native system (not a virtual machine)
  • Try without any USB Hubs.
  • Make sure that the drivers are properly loaded in the Device Manager. In Windows, if any of the devices are showing as “Unknown” or similar, you need to load the ADB Device driver.

Additionally, you mention B0 silicon in your i.MX95 Verdin Evaluation Kit, however, this has not been in the market for very long time. Could it be you are still using A1 silicon?

Can you share the version of the SOM on top of the EVK? Alternatively, can you also share the version used by the EVK?

A1 silicon:

  • SOM: No tag
  • EVK: V1.1D or older

B0 silicon:

  • SOM: V1.1A or later
  • EVK: V1.1E or later

This said, the commands and images used vary from A1 silicon to B0. Make sure to check the V0.8 iteration of the Getting Started guide to get details on these differences.

Additionally, from Toradex, our expertise is with the Linux images, rather than with Android, and we can confirm that those images are working. Have you tried flashing or using any of the Linux (Yocto) images provided by NXP?

If the USB download is failing to boot, you should try the SD card to boot the system (not flashing). SW = 1011

However, for flashing an OS to onboard storage on the Verdin EVK you need to do it through USB download with the recovery button as explained above.

6

Dear alvaro.tx,

Thank you for your detailed reply.

Regarding the hardware version:

  • The SOM label itself is currently hidden by the heatsink, however the box indicates
    “iMX95 Verdin EVK V1.1D”.
  • On the EVK PCB, I can confirm a “V1.3” marking.

Based on the procurement timing and information, we believe this unit should be B0 silicon.
It was purchased via Mouser Electronics after a recent backorder and delivered in late December 2025.

Regarding the flashing procedure:
We understand that our initial SW2 configuration was incorrect.
We have now corrected SW2 to 1010 and power on the board while pressing the Recovery button (B8).
With this procedure, the device is correctly detected by the host PC.

However, after correcting the procedure, we are still observing the same failure.
The command and result are as follows:

uuu.exe android-16.0.0_1.2.0_image_95evk\uuu_imx_android_flash.bat -f imx95 -a -e -u trusty-verdin-dual
uuu (Universal Update Utility) for nxp imx chips – libuuu_1.5.201-0-g727fc2b

Success 0 Failure 1
2:8-8FB7951F 1/2 [HID(W): LIBUSB_ERROR_PIPE (-9)] SDPS: boot -f

Regarding the host environment:

  • Tested on both Windows and Linux native systems (no virtual machines)
  • No USB hubs used
  • USB device is properly enumerated on the host
  • SD card boot (SW = 1011) was also tested, but the system did not boot

One question we would like to clarify is whether this behavior could be related to
a uuu version compatibility issue.

We are currently using uuu 1.5.201, but the documentation mentions different minimum
versions depending on the release.
Could you please advise if a specific uuu version is recommended or known to be stable
for flashing Android on i.MX95 Verdin EVK (especially for B0 silicon)?

Thank you for your guidance.

Best regards, kubota

7

Thank you for your fast response.

If the box says iMX95 Verdin EVK V1.1D, that means it is a A1 silicon board. That would also explain why you are having issues loading the OS.

V1.3A might be the PCB version but we need the EVK version. There should be a paper label tag in the board with the version

All the detailed information should be in the Android OS release and documentation from NXP:

Checking the latest release (Android 16.0.0_1.2.0 (L6.12.49_2.2.0 BSP)), under the Android Quick Start Guide, NXP validated the releases with UUU 1.5.201 version. I believe Android 15.0.0_1.2.0 (L6.6.52_2.2.0 BSP) should work with the earlier silicon in case you are willing to try and see if it is indeed an older silicon.

Sorry to insist on this, but currently all the hints point to an incompatibility between HW and SW.

Kind regards,
Alvaro.

1 Like