FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows Hello NXP Support, I am requesting help recovering an FRDM-i.MX93 board. The board consistently stops during early SPL boot immediately after “M33 prepare ok” and does not continue to BL31 or full U-Boot. UUU recovery also fails during SDPS boot with a timeout. Board details: Board: FRDM-i.MX93 SoC shown in serial log: 0xa1009300 LC shown in serial log: 0x2040010 PMIC: PCA9451A DDR: 3733MTS Typical serial output: U-Boot SPL 2024.04+gde16f4f1722+p0 (Sep 02 2024 - 10:44:35 +0000) SOC: 0xa1009300 LC: 0x2040010 PMIC: PCA9451A PMIC: Over Drive Voltage Mode DDR: 3733MTS DDR: 3733MTS M33 prepare ok The same stop point also occurs with a rebuilt 2025 SPL: U-Boot SPL 2025.04 (Apr 26 2026 - 16:21:54 +0000) PMIC: PCA9451A PMIC: Over Drive Voltage Mode DDR: 3733MTS DDR: 3733MTS M33 prepare ok Hardware setup used: P1 = external power supply, tested with 45 W USB-C wall adapter P16 = debug serial console P13 = microSD card slot P2 = USB-C connection for UUU / serial downloader mode I also tested powering from a wall adapter instead of PC USB power. The behavior did not change. Host systems tested: Linux Mint / Ubuntu host Windows host UUU versions tested: uuu 1.5.141 uuu 1.5.243 The main issue is that the board reaches SPL, initializes PMIC and DDR, and prints “M33 prepare ok”, then nothing else happens. It never reaches “Normal Boot”, “Trying to boot from BOOTROM”, “NOTICE: BL31”, or full U-Boot. This happens when booting from both SD and eMMC. In USB Serial Downloader mode, the board is detected by UUU: sudo ./uuu -lsusb Connected Known USB Devices Path Chip Pro Vid Pid BcdVersion 5:2 MX93 SDPS: 0x1FC9 0x014E 0x0001 However, UUU fails during SDPS boot. The command used was: sudo ./uuu -V -b emmc_all imx-boot-imx93frdm-sd.bin-flash_singleboot imx-image-full-imx93frdm.rootfs.wic.zst On Linux, the failure is: Start Cmd:SDPS: boot -scanterm -f imx-boot-imx93frdm-sd.bin-flash_singleboot -scanlimited 0x800000 Fail HID(W):LIBUSB_ERROR_TIMEOUT On Windows, the failure is: Start Cmd:SDPS: boot -scanterm -f .\imx-boot-imx93frdm-sd.bin-flash_singleboot -scanlimited 0x800000 14% Fail HID(W): LIBUSB_ERROR_TIMEOUT (-7) This was tested on both Linux and Windows, with the same result. Images tested: I tested the official NXP FRDM-i.MX93 Rev 4.0 demo image package: LF_v6.6.36-2.1.0_images_FRDM_4.0_IMX93 The boot image hash is: 7aba6102e5ec64add632cd6667e77fa3f6886fd72c314e4c01f2964c0fc56a5f imx-boot-imx93frdm-sd.bin-flash_singleboot I also tested my own Yocto image for imx93frdm, which uses the same boot image hash. I verified that SD boot selection works. In SD boot mode with no SD card inserted, there is no serial output. In SD boot mode with an SD card inserted, SPL starts and stops at “M33 prepare ok”. So the SD boot switch appears to be working. I also verified that the official NXP .wic image contains the boot image at the expected 32 KiB / 0x8000 offset. Commands used: WIC=nxp.wic BOOT=imx-boot-imx93frdm-sd.bin-flash_singleboot xxd -l 64 -s $((32*1024)) "$WIC" xxd -l 64 -s 0 "$BOOT" cmp -n "$(stat -c%s "$BOOT")" -i $((32*1024)):0 "$WIC" "$BOOT" && echo "NXP WIC contains boot image at 32K" || echo "NXP WIC does NOT contain boot image at 32K" Result: NXP WIC contains boot image at 32K So the SD image appears to contain the boot container correctly. To rule out only the 2024.04 SPL image being the issue, I built a newer boot image using Flexbuild/U-Boot. The SPL inside the built image shows: U-Boot SPL 2025.04 (Apr 26 2026 - 16:21:54 +0000) NXP FRDM-IMX93 I wrote this new flash.bin to the SD card at 32 KiB offset using: sudo dd if=flash-imx93frdm-2025.bin of=/dev/sdX bs=1K seek=32 conv=fsync sync The board then printed the new SPL banner, confirming it was executing the new SD boot image: U-Boot SPL 2025.04 (Apr 26 2026 - 16:21:54 +0000) PMIC: PCA9451A PMIC: Over Drive Voltage Mode DDR: 3733MTS DDR: 3733MTS M33 prepare ok However, it still stopped at the same point and did not continue to BL31/full U-Boot. eMMC status: Originally, the eMMC booted far enough to reach Linux login, but root login was broken because /bin/sh was missing in the root filesystem. During recovery attempts, the eMMC was rewritten from SD Linux using a .wic image. After that, eMMC boot also stops after “M33 prepare ok”. However, the same stop point occurs from SD boot using the official NXP image and also with the rebuilt 2025 SPL, so the current issue appears to be earlier than Linux/rootfs. What I believe has been ruled out: Wrong serial port: serial works and shows SPL output. Bad PC power: tested with external 45 W wall adapter. Wrong SD boot switch: SD boot mode with no SD card gives no output. Missing boot image in SD image: verified boot image exists at 0x8000 / 32 KiB in the official NXP WIC. Linux/rootfs issue: the failure happens before BL31/full U-Boot/Linux. Host OS issue for UUU: UUU SDPS boot timeout occurs on both Linux and Windows. Only the old 2024 SPL being bad: a rebuilt 2025.04 SPL also stops after “M33 prepare ok”. Could you please help determine whether this is a known FRDM-i.MX93 early boot issue? Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows Are you using the BSP version we released?
Embedded Linux for i.MX Applications Processors | NXP Semiconductors
Which version BSP are you using and choose?
I will try to test on our board when I back from Labor holiday, I will back to office on Next Wednsday then will test, then give you reply my test result.
Wish you have a nice day
Best Regards
Rita Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows I'm using the LF_v6.6.36-2.1.0_images_FRDM_4.0_IMX93 image Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows I am back to office and will test on our board, then tell you the result. Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows Did you figure it out? Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows @Rita_Wang Having the same issue... I have never seen the BL31 to start booting with my imx-image-full-imx93frdm.rootfs-20260705225501.wic.zst scarthgap build. Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows Hi, I'm currently having the same issue. May I ask if you've figured out the solution yet? Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows Same issue here. Is there any update what's needed to allow the imx93 to boot from SD or alternatively let UUU work properly? Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows We noticed there's a difference in the memory chip on the board in respect to other frdm-imx93 boards. Perhaps this helps finding the issue. Working board has micron and faulty board has a brand I don't recognize. Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows I am having the same issue. This should be marked as HIGH PRIORITY as the only working image is the one factory supplied on the eMMC! If that's re-flashed, I'll have a bricked FRDM-IMX93 until a solution is found, which I suspect is related to DDR memory timings. I too hang at "M33 prepare ok" which indicates DDR config/timing issues and my board also has the same 'no-name' DDR IC as @SynchronicIT post above (manufacturer logo with a 'J'). How is it that these boards can be shipped out with a working image on eMMC but none of the available images from NXP work? When I boot via (factory loaded) eMMC - which WORKS - the u-boot version is: U-Boot SPL 2025.04-g99518e6b6f20 (Feb 02 2026 - 05:52:54 +0000) whereas the LATEST download from NXP (LF_v6.6.36-2.1.0_images_FRDM_4.0_IMX93.zip), the "imx-boot-imx93frdm-sd.bin-flash_singleboot" file is u-boot version: U-Boot SPL 2024.04+gde16f4f1722+p0 (Sep 02 2024 - 10:44:35 +0000) Below is the full output from working factory image eMMC and also from non-working SD flashed image and UUU uploaded u-boot. * WORKING (factory loaded eMMC) * U-Boot SPL 2025.04-g99518e6b6f20 (Feb 02 2026 - 05:52:54 +0000) PMIC: PCA9451A PMIC: Over Drive Voltage Mode DDR: 3733MTS found DRAM 2CS_2GB DRAM matched M33 prepare ok Normal Boot Trying to boot from BOOTROM Boot Stage: Primary boot image offset 0x8000, pagesize 0x200, ivt offset 0x0 Load image from 0x57800 by ROM_API NOTICE: TRDC init done NOTICE: BL31: v2.12.0(release):lf-6.18.2-1.0.0 NOTICE: BL31: Built : 07:53:18, Feb 10 2026 U-Boot 2025.04-g99518e6b6f20 (Feb 02 2026 - 05:52:54 +0000) Reset Status: POR CPU: NXP i.MX93(52) Rev1.2 A55 at 1700 MHz CPU: Industrial temperature grade (-40C to 105C) at 24C Model: NXP FRDM-IMX93 DRAM: 2 GiB BOARD: V1.0(ADC2:684,ADC3:271) TCPC: Vendor ID [0x1fc9], Product ID [0x5110], Addr [I2C2 0x52] SNK.Power3.0 on CC1 PDO 0: type 0, 5000 mV, 3000 mA [E] PDO 1: type 0, 9000 mV, 3000 mA [] PDO 2: type 0, 12000 mV, 3000 mA [] PDO 3: type 0, 15000 mV, 3000 mA [] PDO 4: type 0, 20000 mV, 3250 mA [] PDO 5: type 3, undefined Requesting PDO 4: 20000 mV, 750 mA Source accept request PD source ready! tcpc_pd_receive_message: Polling ALERT register, TCPC_ALERT_RX_STATUS bit failed, ret = -62 TCPC: Vendor ID [0x1fc9], Product ID [0x5110], Addr [I2C2 0x50] Core: 229 devices, 32 uclasses, devicetree: separate MMC: FSL_SDHC: 0, FSL_SDHC: 1 Loading Environment from MMC... Reading from MMC(0)... *** Warning - bad CRC, using default environment Fail to setup video link In: serial Out: serial Err: serial BuildInfo: - ELE firmware version 2.0.5-7a34cee switch to partitions #0, OK mmc0(part 0) is current device UID: 4a7ff07fa81b46d8b2b59146dfa5af84 flash target is MMC:0 Net: eth0: ethernet@42890000, eth1: ethernet@428a0000 [PRIME] Fastboot: Normal Normal Boot Hit any key to stop autoboot: 0 u-boot=> * NOT WORKING * U-Boot SPL 2024.04+gde16f4f1722+p0 (Sep 02 2024 - 10:44:35 +0000) SOC: 0xa1009300 LC: 0x2040010 PMIC: PCA9451A PMIC: Over Drive Voltage Mode DDR: 3733MTS DDR: 3733MTS M33 prepare ok -- HANG -- Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows I've got the same issue. I was not able to flash any image via uuu.exe, with the same "HID(W): LIBUSB_ERROR_TIMEOUT (-7)" error output. The memory chip on my board is also the "J" branded one, not Micron. Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows Adding another data point with the specific DDR part information, since I think the substituted memory is the key to this and I haven't seen the exact part numbers posted yet. **Board:** FRDM-IMX93, SCH-94611 REV B2 (board label DRQ30063390) **SoC:** i.MX93(52) Rev1.2, SOC 0xa1009300, LC 0x2040010 **PMIC:** PCA9451A **DDR:** The schematic and User Guide specify LPDDR4x Micron MT53E1G16D1FW-046. The chip actually fitted on my board is marked **JSL4BAG167ZAMF** — not Micron. This matches what others in this thread have reported (the "J"-branded DDR on failing boards vs Micron on working ones). **The failure is at DDR training/validation, not M33/ELE.** Comparing the working factory eMMC boot against the failing public BSP boot makes this clear: Working (factory eMMC, U-Boot SPL 2025.04, BL31 lf-6.18.2-1.0.0): ``` DDR: 3733MTS found DRAM 2CS_2GB DRAM matched M33 prepare ok Normal Boot ... ``` Failing (LF_v6.6.36-2.1.0 public release, U-Boot SPL 2024.04 Sep 02 2024): ``` DDR: 3733MTS DDR: 3733MTS M33 prepare ok -- hang -- ``` The `found DRAM ... DRAM matched` line is present on the working bootloader and absent on the failing one. The board hangs at exactly the point where DDR validation would complete, before BL31 / Normal Boot. So this looks like the 6.6.36 DDR configuration/timings not matching the substituted DDR part, rather than anything downstream. The working eMMC bootloader also reports **ELE firmware version 2.0.5-7a34cee**, which is newer than what ships in the 6.6.36 package — noting in case the fix depends on both the DDR timings and the ELE version. **What I've been able to rule out**, to save cycles: - Build: my own Yocto imx93frdm build produces a byte-identical imx-boot to the factory package (sha256 7aba6102e5ec64add632cd6667e77fa3f6886fd72c314e4c01f2964c0fc56a5f), so this is not a build issue. - SD flashing: verified the boot container at 32 KiB (0020 0287 magic), valid MBR (55aa), and two FIT magics in the bootloader region. - Boot switch: SD mode with no card gives no serial output; with a card, SPL runs — so USDHC2/SD selection is correct. - Power: same result on multiple USB-C supplies. - Host/USB: UUU SDPS boot fails with HID(W): LIBUSB_ERROR_TIMEOUT at the same point on two different Linux hosts. - Hardware itself is good: the board boots its factory eMMC image to Linux, so the DDR *can* be trained by the correct bootloader. **Questions:** 1. Is the corrected DDR configuration for the REV B2 boards with the non-Micron (JSL4BAG167ZAMF) DDR available in any current public BSP — e.g. 6.6.52-2.2.0 or the 6.12.x releases — or is it only in the newer bootloader (lf-6.18.2) currently shipped on eMMC? 2. If it's not yet in a public release, would it be possible to publish the updated FRDM-IMX93 DDR timing headers (or the lf-6.18.2 FRDM bootloader) so SD boot works on these boards? I'm happy to run diagnostics or test candidate bootloaders/timing configs on this board if that would help narrow it down. Thanks, jjudk Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows Following up with a working resolution, in case it helps others on this thread with the same board/DDR combination. Summary: the failure is a DDR training issue in the public LF6.6.36-2.1.0 BSP on the newer FRDM-IMX93 boards that ship with substituted (non-Micron) LPDDR4X. Moving to the **LF6.18.2 (Whinlatter) BSP** resolves it — the board trains its DDR and boots cleanly from SD. Board / DDR (for reference): - FRDM-IMX93, SCH-94611 REV B2 - Schematic specifies Micron MT53E1G16D1FW; chip actually fitted is marked JSL4BAG167ZAMF (non-Micron substitute) What confirmed the root cause: the factory eMMC image (which boots fine) uses a newer bootloader — U-Boot SPL 2025.04, BL31 lf-6.18.2, kernel 6.18.2 — and its SPL prints `found DRAM 2CS_2GB DRAM matched` before `M33 prepare ok`. The public LF6.6.36 SPL (U-Boot 2024.04) does not print `DRAM matched` and hangs at `M33 prepare ok`. So the 6.6.36 DDR configuration does not train this substituted memory, while the 6.18.2 one does. The working path — build and boot the LF6.18.2 BSP: mkdir imx-bsp-6.18.2 && cd imx-bsp-6.18.2 repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-whinlatter -m imx-6.18.2-1.0.0.xml repo sync DISTRO=fsl-imx-xwayland MACHINE=imx93-11x11-lpddr4x-frdm source sources/meta-imx/tools/imx-setup-release.sh -b build-frdm bitbake imx-image-core Note the machine name is `imx93-11x11-lpddr4x-frdm` (native to this BSP — no separate meta-imx-frdm layer needed, unlike 6.6.36). Then flash the resulting `.wic.zst` to SD (decompress and dd to the whole card device), set the boot switch to SD (SW1 = 1 1 0 0), and boot. Result on the REV B2 / JSL DDR board: DDR: 3733MTS found DRAM 2CS_2GB DRAM matched M33 prepare ok Normal Boot ... NXP FRDM-IMX93 login: `free -h` confirms the full 2GB is trained and available. Still open for NXP: is there any plan to backport the updated FRDM DDR configuration to the LF6.6.36-2.1.0 branch, for anyone who needs to stay on 6.6.36? For those able to move to 6.18.2, the above works. Hope this saves someone the debugging. jjudk Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows Hi Rita, Do you have any update on this? We are stuck on this. Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows I have test on our 93FRDM REV B version board with the demo images images LF_v6.6.36-2.1.0_images_FRDM_4.0_IMX93，
Using the UUU uuu tool Release uuu_1.5.243
Try both on the SD Card and emmc, download and boot up success, do not reproduce the error you met.
.\uuu.exe -b emmc_all imx-boot-imx93frdm-sd.bin-flash_singleboot imx-image-full-imx93frdm.rootfs.wic.zst
Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows Seems like the issue is with the REV B2 boards. Please try it on a REV B2
View full article
