Flash u-boot on colibri imx8x

Technical Support
, ,
1

Hello,

I have done some change into u-boot source and rebuild using yocto scrathgap-7.4.0.

the I have tried to flash the mmc0 with the new object using the u-boot command.

First I wrote the file deploy/images/colibri-imx8x/imx-boot-colibri-imx8x-sd.bin-flash into a SDcard into a /boot/colibri-imx8x/imx-boot-colibri-imx8x-sd.bin-flash.

Then on the u-boot console i have done this command:

mmc dev 1

load mmc 1:1 ${loadaddr} /boot/imx-boot-colibri-imx8x-sd.bin-flash

echo ${filesize} ==>1192960 bsz ==>0x91B

crc32 ${loadaddr} ${filesize} ==> 3b9a972a

setexpr blks ${filesize} + 0x1FF

setexpr blks ${blks} / 0x200

mmc dev 0

mmc partconf 0 1 1 1

mmc write ${loadaddr} 0x0 ${blks}

mmc read ${loadaddr} 0x0 ${blks}

crc32 ${loadaddr} ${filesize} ==> 3b9a972a

But when I have rebooted the board get this message:

U-Boot 2024.04-7.4.0-devel+git.cf50ed467107 (Aug 05 2025 - 15:22:26 +0000)

CPU: NXP i.MX8QXP RevC A35 at 1200 MHz at 37C

DRAM: 2 GiB
Core: 249 devices, 24 uclasses, devicetree: separate
MMC: FSL_SDHC: 0, FSL_SDHC: 1
Loading Environment from MMC… OK
In: serial
Out: serial
Err: serial
Model: Toradex 0050 Colibri iMX8QXP 2GB IT V1.0D
Serial#: 14791387
Boot: MMC0
Reset cause: POR

BuildInfo:

  • SCFW 83624b99, SECO-FW c9de51c0, IMX-MKIMAGE 81fca643, ATF lf-6.6.
  • U-Boot 2024.04-7.4.0-devel+git.cf50ed467107

flash target is MMC:0
Net: eth0: ethernet@5b040000 [PRIME]
Fastboot: Normal
Normal Boot
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:1…
Found U-Boot script /boot.scr
7045 bytes read in 4 ms (1.7 MiB/s)

Executing script at 83200000

Now Try to run New boot.scr new
variable upgrade_requested :
Loading DeviceTree: imx8qxp-colibri-eval-v3.dtb
73888 bytes read in 5 ms (14.1 MiB/s)
14 bytes read in 2 ms (6.8 KiB/s)
Working FDT set to 83100000
8280043 bytes read in 191 ms (41.3 MiB/s)
Uncompressed size: 20255232 = 0x1351200
Bootargs: irqaffinity=0,1,2 isolcpus=3 nohz_full=3 rcu_nocbs=3 root=PARTUUID=076c4a2a-02 ro rootwait console=tty1 console=ttyLP3,11520

Flattened Device Tree blob at 83100000

Booting using the fdt blob at 0x83100000
Working FDT set to 83100000
Loading Device Tree to 00000000fd63a000, end 00000000fd66ffff … OK
Working FDT set to fd63a000
/bus@59000000/dma-controller@591f0000, 19876
/bus@59000000/dma-controller@599f0000, 23908
/bus@5a000000/dma-controller@5a1f0000, 30916
/bus@5a000000/dma-controller@5a1f0000, 30916
/bus@5a000000/dma-controller@5a9f0000, 37172

Starting kernel

And the boot stop.

Please what is wrong.

Thank you

Best regards

Flavio Gobber

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’d be glad to help troubleshoot your U-Boot flashing issue! To provide the most accurate guidance, could you specify which OS and version you’re running on the device? Also, please run the tdx-info command to get detailed information about your hardware setup and share the output. You can find more information about this command at https://developer.toradex.com/software/development-resources/tdx-info/.

Initial Analysis

Based on your description, you’ve successfully flashed the new U-Boot binary to the eMMC boot partition, but the kernel boot process is hanging after the “Starting kernel” message. This suggests the U-Boot portion is working correctly, but there may be an issue with the kernel or device tree configuration.

Common Issues to Check

1. U-Boot Binary Verification

Your CRC32 verification shows the binary was written correctly (both read and write operations show 3b9a972a), which is good (1).

2. Boot Process Analysis

The boot log shows U-Boot is loading properly and finding the boot script. The kernel loading process appears to start but hangs at “Starting kernel” (1).

3. Potential Causes

  • Device Tree Issues: The device tree (imx8qxp-colibri-eval-v3.dtb) may not be compatible with your U-Boot changes
  • Kernel Arguments: The bootargs show specific CPU isolation parameters that might conflict with your modifications
  • Memory Layout: Your U-Boot changes might have affected memory mapping

Recommended Steps

  1. Verify your build configuration matches the requirements in the U-Boot version information table (2)
  2. Check if your U-Boot modifications affect memory layout or device initialization
  3. Test with a known working kernel and device tree to isolate whether the issue is in U-Boot or the kernel/DT combination

Once you provide the platform details and tdx-info output, I can give you more specific troubleshooting steps for your exact hardware configuration.

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

In order to identify the reason after the first test i have changed the u-boot source changing only a string. With the old u-boot and the image of Linux the board boot without any problem. Then I do not think that the problem is into the Linux and also into the change of u-boot. The problem could be into the binary of u-boot that I have written in Flash.

Could you help me to solve the problem.

Thank you

4

I understand you’ve narrowed down the issue to the U-Boot binary itself. Since your minimal string change causes the boot failure, there are several potential causes related to the binary format or flashing process for the Colibri iMX8X.

Binary Format Verification

For i.MX8X modules, the correct binary format is crucial. Your use of imx-boot-colibri-imx8x-sd.bin-flash suggests you’re using the correct binary, but let’s verify the flashing process (1).

Potential Issues with Your Flashing Method

1. Boot Partition Configuration

Your command sequence shows:

mmc partconf 0 1 1 1

This sets the eMMC boot partition configuration. However, for i.MX8X, the boot process is more complex and involves multiple components (1).

2. Offset and Size Considerations

You’re writing to offset 0x0, but i.MX8X may require specific offset handling. The boot process involves multiple stages including SCFW, SECO-FW, and ATF as shown in your boot log (1).

Recommended Troubleshooting Steps

1. Verify Binary Integrity

Check if your Yocto build produced the correct binary format:

# Check the file size and format
ls -la deploy/images/colibri-imx8x/imx-boot-colibri-imx8x-sd.bin-flash
file deploy/images/colibri-imx8x/imx-boot-colibri-imx8x-sd.bin-flash

2. Compare with Working Binary

Compare your modified binary with the original working one:

# Compare file sizes
ls -la original_binary modified_binary
# Compare checksums if sizes match
md5sum original_binary modified_binary

3. Alternative Flashing Method

Instead of manual MMC commands, consider using the Toradex Easy Installer or uuu tool for more reliable flashing (2).

4. Boot Partition Analysis

The i.MX8X boot process is complex. Your boot log shows:

  • SCFW 83624b99
  • SECO-FW c9de51c0
  • IMX-MKIMAGE 81fca643
  • ATF lf-6.6

These components must be properly integrated in your binary (1).

Next Steps

  1. Verify your Yocto build configuration - ensure all components are properly included
  2. Test with recovery mode flashing using uuu tool for more controlled deployment (2)
  3. Check if your string change affects any critical boot parameters or memory layout

The fact that only a string change causes this issue suggests the binary layout or size might be affected by your modification, potentially disrupting the complex boot chain required for i.MX8X.

Could you share the exact string change you made and verify the file sizes of both the working and non-working binaries?

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.