DEV Community

Zhou Jiang
Zhou Jiang

Posted on

i.MX6ULL Porting Log 04: I Did Not Touch eMMC First — I Loaded My Own U-Boot into RAM

#linux #ubuntu

Subtitle

Before changing permanent storage, I first used USB RecoveryMode and RAM Boot to prove that my own bootloader could take control.

Goal

In this level, my goal was not to flash eMMC.

My goal was:

  • build my own u-boot.imx
  • enter USB RecoveryMode
  • send U-Boot into RAM with uuu
  • confirm from the serial console that my U-Boot had taken control

This is safer than modifying permanent storage too early.

Real Starting Point

The board already had an older boot path from previous work.

So I did not want to trust the stored boot chain first.
I wanted temporary control before permanent flashing.

Step 1: I made a small but real mistake first

I first ran:

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- distclean
Enter fullscreen mode Exit fullscreen mode

and got:

make: *** 没有规则可制作目标“distclean”。 停止。
Enter fullscreen mode Exit fullscreen mode

This was not a compiler problem.
I was simply in the wrong directory.

Then I moved into the real bootloader source tree:

cd ~/imx6ull-porting/bsp/bootloader
Enter fullscreen mode Exit fullscreen mode

Step 2: Configure and build U-Boot

I applied the board configuration:

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- mx6ull_14x14_ddr512_emmc_defconfig

The important output was:

configuration written to .config

Then I built the image:

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -j$(nproc)

The key build evidence was:

MKIMAGE u-boot.imx

That means u-boot.imx was really generated.

Step 3: RecoveryMode was confirmed by USB enumeration

Before the injection, I checked USB devices:

lsusb
Enter fullscreen mode Exit fullscreen mode

The key output was:

Bus 001 Device 019: ID 15a2:0080 Freescale Semiconductor, Inc. i.MX 6ULL SystemOnChip in RecoveryMode
Bus 001 Device 020: ID 1a86:7523 QinHeng Electronics CH340 serial converter
Enter fullscreen mode Exit fullscreen mode

This proved that:

the SoC was in RecoveryMode
the CH340 serial adapter was also present

At one point I also saw:

FATAL: cannot open /dev/ttyUSB0: No such file or directory
Enter fullscreen mode Exit fullscreen mode

So the serial node was not always ready immediately.
That is why checking lsusb was important.

Step 4: Inject U-Boot into RAM

Then I used:

sudo uuu -b spl u-boot.imx

The important output was:

SDP: boot -f u-boot.imx
[=================100%=================]
Enter fullscreen mode Exit fullscreen mode

This showed that the host was really sending u-boot.imx to the chip.

Step 5: The serial console gave the final proof

After the RAM boot, I opened the serial console and saw:

U-Boot 2016.03 (Mar 22 2026 - 12:20:06 +0800)
Board: I.MX6U ALPHA|MINI
DRAM:  512 MiB
Boot from USB for mfgtools
Use default environment for mfgtools
Run bootcmd_mfg: run mfgtool_args;bootz ${loadaddr} ${initrd_addr} ${fdt_addr};
Bad Linux ARM zImage magic!
=>
Enter fullscreen mode Exit fullscreen mode

This is the strongest evidence of the whole level.

It proves that:

  • my U-Boot image is running
  • the board is now following the USB mfgtools path
  • the bootloader has already taken control
  • the next failure point is the Linux image stage
  • What Bad Linux ARM zImage magic! really means

This message looks scary, but it does not mean this level failed.

For this level, the main goal was to prove:

  • my U-Boot can be built
  • USB RecoveryMode works
  • uuu can inject the image
  • the serial console shows my bootloader running

That already happened.

So this error means the problem has moved forward to the Linux image stage.

Top comments (0)