This content originally appeared on DEV Community and was authored by Zhou Jiang
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.
This content originally appeared on DEV Community and was authored by Zhou Jiang
Zhou Jiang | Sciencx (2026-03-22T02:42:50+00:00) i.MX6ULL Porting Log 02: Project Layout, a Serial Port Trap, and the Current Board Baseline. Retrieved from https://www.scien.cx/2026/03/22/i-mx6ull-porting-log-02-project-layout-a-serial-port-trap-and-the-current-board-baseline/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.