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

Goal

Create a clean project workspace and capture the board’s current boot baseline through the serial console.

Problem

This level looked simple at first:

1. create folders


2. initialize Git


3. connect the serial cable


4. save the boot log

But the real system was not 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 another problem:

my CH340 serial adapter was detected by Linux, but the serial port disappeared almost immediately.

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 output, 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 matters 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 remove brltty

After that, /dev/ttyUSB0 became stable.

Then I hit another issue:

Permission denied

This was not a driver problem.

It was a user permission problem.

My user was not yet effectively using the dialout group in the current shell session, so I used:

sudo picocom -b 115200 /dev/ttyUSB0

to keep the main workflow moving.

Step 5: Capture the current board baseline

With the serial console working, I rebooted the board and saved the output as:

logs/current_board_boot_baseline.log

The log showed important real facts:

U-Boot 2016.03

Board: I.MX6U ALPHA|MINI

DRAM:  512 MiB

Net:   FEC1

It also showed that the 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!

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

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

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 planned to clean up 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:

1. Always record the real board state before trusting any boot log


2. When serial devices behave strangely on Linux, check dmesg first

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