DEV Community: Zhou Jiang

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

Zhou Jiang — Sun, 22 Mar 2026 07:45:11 +0000

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

and got:

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

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

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

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

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

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%=================]

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!
=>

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.

i.MX6ULL Porting Log 02: Project Layout, a Serial Port Trap, and the Current Board Baseline

Zhou Jiang — Sun, 22 Mar 2026 02:42:50 +0000

The Goal

Build a clean project structure and capture the current board boot baseline through the serial console.

The Problem

At first, this level looked simple:

create folders initialize Git connect the serial cable save the boot log

But the real system was not that simple.

This board is not in confirmed factory-default state.
Its serial output already contains traces from a previous project.
So I could not call this log a factory baseline.
I had to treat it as a current board baseline.

I also hit a second problem:
my CH340 serial adapter was detected by Linux, but the serial port disappeared immediately.

The Fix

Step 1: Build the project layout

I created a clean working structure:

mkdir -p ~/imx6ull-porting/{src,build,out,logs,docs}
cd ~/imx6ull-porting
git init

This keeps source code, build output, final output, logs, and documents separated.

Step 2: Record the board state first

Before trusting the serial log, I wrote down the truth:

the board is not in confirmed factory-default state
the current boot output contains traces from an older project
this log must be treated as a current board baseline

This was important because future debugging must compare against the real current state, not an imagined clean state.

Step 3: Find the serial trap

I checked lsusb and confirmed the CH340 adapter was detected.

But the kernel log showed the real problem:

ch341-uart converter now attached to ttyUSB0 usbfs: interface 0 claimed by ch341 while 'brltty' sets config #1 ch341-uart ttyUSB0: ch341-uart converter now disconnected from ttyUSB0

So the problem was not the cable.
It was brltty, a background accessibility service in Ubuntu.
It hijacked the CH340 device and disconnected it.

Step 4: Remove the conflicting service

I fixed it by removing brltty:

sudo apt-get remove --purge -y brltty

After that, /dev/ttyUSB0 became stable.

Step 5: Open the serial console and capture the baseline

I used picocom and rebooted the board.

The captured log showed important real facts:

U-Boot 2016.03 Board: I.MX6U ALPHA|MINI DRAM: 512 MiB Net: FEC1

It also showed that the current board still had an old network boot path:

FEC1 Waiting for PHY auto negotiation to complete......... TIMEOUT ! TFTP from server 169.254.82.125 Filename 'zImage' ARP Retry count exceeded; starting again Filename 'imx6ull-alientek-emmc.dtb' Bad Linux ARM zImage magic!

That means the board is currently trying to boot by TFTP, but the path is not working correctly.

The Test

This level passes if:

the project folders exist
board_state.md exists
current_board_boot_baseline.log exists
the serial console works
the current board state is clearly documented
The Debug Log
Issue 1: The CH340 device was detected, but /dev/ttyUSB0 was unstable Fix: Found that brltty hijacked the device, then removed it Issue 2: Normal user access gave Permission denied Fix: Used sudo picocom first, then prepared to fix group permissions later Issue 3: The board was not in clean factory state Fix: Recorded that truth first, and saved the log as a current board baseline instead of a factory baseline

What I Learned

This level was not about code.
It was about discipline.

I learned two important things:

Always record the real board state before trusting any boot log
When serial devices behave strangely on Linux, check dmesg first

In low-level work, the real system state is always more important than assumptions.

i.MX6ULL Porting Log 01: How I Fixed a 404 Error and Set Up the ARM Cross-Compiler

Zhou Jiang — Sat, 21 Mar 2026 16:46:38 +0000

The Goal

Set up the ARM cross-compiler for the i.MX6ULL bring-up project.

This project will later test a more modern Ubuntu 22.04 userland on an old i.MX6ULL BSP flow.
But before that, I first needed a working ARM compiler on my Ubuntu 22.04 host.

The Problem

My host machine is x86, but the target board is ARM.
So I need a cross-compiler to build ARM binaries.

At first, this looked simple.
But the real work started with an old download link and a 404 error.

The Fix
Step 1: Install the basic packages

I first installed the common build tools and libraries:

sudo apt-get update
sudo apt-get install -y make gcc g++ build-essential libncurses5-dev bison flex libssl-dev lzop git wget libusb-1.0-0-dev net-tools

This step completed normally.

Step 2: The old Linaro link was dead

I tried this old toolchain link first:

sudo wget https://releases.linaro.org/components/toolchain/binaries/8.3-2019.03/arm-linux-gnueabihf/gcc-linaro-8.3.0-2019.03-x86_64_arm-linux-gnueabihf.tar.xz

The result was:

404 Not Found

So the problem was not my command.
The old resource was no longer available.

Step 3: Download from the ARM official site

Then I switched to the ARM official download URL:

sudo wget https://developer.arm.com/-/media/Files/downloads/gnu-a/8.3-2019.03/binrel/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf.tar.xz

This worked.

Step 4: I made a real naming mistake

After the download, I still used the old gcc-linaro... name in my extract command.

That failed because the real file name was already changed to gcc-arm....

So I checked the directory with ls -l, then used the real file name:

sudo xz -d gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf.tar.xz
sudo tar -xvf gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf.tar
Step 5: The PATH was wrong at first

I also wrote the wrong path in ~/.bashrc at first.
I used the old gcc-linaro... folder name.

Because of that, this command failed:

arm-linux-gnueabihf-gcc -v

The real reason was simple:

the compiler was extracted
but my PATH pointed to a folder that did not exist

Then I fixed the PATH:

export PATH=$PATH:/usr/local/arm/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin

Step 6: Remove one extra shell noise

I also saw this message when running source ~/.bashrc:

/home/zhou/.openclaw/completions/openclaw.bash: No such file or directory

This was not the main compiler problem, but it added noise.
So I commented it out first and kept the shell clean.

The Test

After fixing the PATH, I ran:

source ~/.bashrc
arm-linux-gnueabihf-gcc -v

The result was:

gcc version 8.3.0 (GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36))

That means the cross-compiler was ready.

The Debug Log
Issue 1: The old Linaro download link returned 404 Not Found
Fix: Switched to the ARM official toolchain download URL
Issue 2: I still used the old gcc-linaro... name in the extract command
Fix: Checked the real file name with ls -l and used gcc-arm...
Issue 3: The PATH in ~/.bashrc pointed to the wrong folder
Fix: Updated the PATH to the real extracted directory
Issue 4: One unrelated shell completion file was missing
Fix: Commented it out to reduce shell noise
What I Learned

This level was not only about installing a compiler.

It taught me one important lesson:

In low-level work, a wrong path name can stop the whole chain.

Sometimes the big problem is not the theory.
It is just that one real thing in the system does not match the real state on the machine.