Step 1: I made a small but real mistake first
Step 2: Configure and build U-Boot
configuration written to .config
Step 3: RecoveryMode was confirmed by USB enumeration
Step 4: Inject U-Boot into RAM
Step 5: The serial console gave the final proof Before changing permanent storage, I first used USB RecoveryMode and RAM Boot to prove that my own bootloader could take control. In this level, my goal was not to flash eMMC. This is safer than modifying permanent storage too early. 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. This was not a compiler problem.I was simply in the wrong directory. Then I moved into the real bootloader source tree: I applied the board configuration: make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- mx6ull_14x14_ddr512_emmc_defconfig The important output was: Then I built the image: make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -j$(nproc) The key build evidence was: That means u-boot.imx was really generated. Before the injection, I checked USB devices: the SoC was in RecoveryModethe CH340 serial adapter was also present At one point I also saw: So the serial node was not always ready immediately.
That is why checking lsusb was important. This showed that the host was really sending u-boot.imx to the chip. After the RAM boot, I opened the serial console and saw: This is the strongest evidence of the whole level. This message looks scary, but it does not mean this level failed. For this level, the main goal was to prove: That already happened. So this error means the problem has moved forward to the Linux image stage. Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to ? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- distclean
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- distclean
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- distclean
make: *** 没有规则可制作目标“distclean”。 停止。
make: *** 没有规则可制作目标“distclean”。 停止。
make: *** 没有规则可制作目标“distclean”。 停止。
cd ~/imx6ull-porting/bsp/bootloader
cd ~/imx6ull-porting/bsp/bootloader
cd ~/imx6ull-porting/bsp/bootloader
lsusb
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
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
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
FATAL: cannot open /dev/ttyUSB0: No such file or directory
FATAL: cannot open /dev/ttyUSB0: No such file or directory
FATAL: cannot open /dev/ttyUSB0: No such file or directory
sudo uuu -b spl u-boot.imx The important output was: SDP: boot -f u-boot.imx
[=================100%=================]
sudo uuu -b spl u-boot.imx The important output was: SDP: boot -f u-boot.imx
[=================100%=================]
sudo uuu -b spl u-boot.imx The important output was: SDP: boot -f u-boot.imx
[=================100%=================]
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!
=>
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!
=>
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!
=> - 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 - 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 - my U-Boot can be built
- USB RecoveryMode works
- uuu can inject the image
- the serial console shows my bootloader running
