The i.MX93 family of processors can boot from multiple sources: eMMC, SD card, etc. Our board lacks an SD card so this method can be discarded right off the bat. Although booting from eMMC is possible, it would require us to overwrite its persistent storage with a disk image every single time. We will do this at some point later in our workshop but, for now, the most convenient solution is using SDP (Serial Download Protocol) to download flash.bin via our USB connection to the board directly into the chip's SRAM (and execute it there!).

In order to select Serial Download as the preferred method of boot, you will need to set four DIP switches on the board. Find the BOOT label and configure them according to the figure below:

The Universal Update Utility (UUU) is an image deployment tool created by NXP for it's i.MX architecture. For more information about its usage, scripting interface and supported protocols, check out the documentation.

Grab the source code from here and compile uuu. The project uses the cmake build system for the sake of portability. If you haven't encountered it yet, follow these setup steps:

# currently in the mfgtools repo root
mkdir build
cd build
cmake ..
make -j $(nproc)

First things first, connect the three USB-C cables (Power to the AC adapter, Debug and USB_C labeled ports to your PC). While the former will be used to power on the board, the latter will expose two Serial Devices and a USB Bootloader communication line with your computer. The one used for console I/O by the bootloaders should appear to you as /dev/ttyACM0.

Connect to this device using a serial terminal emulation tool of your choice. We recommend picocom. The default baud rate of i.MX devices (actually, most embedded Linux devices) is 115200 by convention. But don't trust us on this: check the manual ;)

Note that nothing will be printed on the console yet, but you need to stay connected to receive the messages that will follow!

Ever since the USB-C cable was plugged in, BL1 has been waiting for the FIP data over serial, thanks to our jumper configuration. Now we can finally provide this data using uuu and it's SDP implementation.

# basic syntax: scp <source> <destination>
# either source or destination MUST be a remote SSH with the form:
# username@host:/path/to/file
# Note: -P specifies the port (your VM index!)
# example (destination is "./" -- your current directory):
scp -P 220X your-user@arm2026.root.sx:path/to/flash.bin ./

# paths for uuu and flash.bin truncated
uuu -b spl flash.bin

About now you should see some debug messages in your serial console tool.

Finally, when everything is in working condition, you should see a Run fastboot … message, press Ctrl + C and you should get the u-boot=> prompt.

You might be wondering: but we don't have an OS installed yet… is this all we can do now?

Don't worry, we'll now get to see why u-boot is the most popular choice for embedded devices (here's another fact: most Android phones also use it, although it's not popular anymore since most manufacturers migrated to proprietary ones).

Now that we finally have access to the interactive shell (we've stopped at BL33), try to run bdinfo for some generic board information. Run help to see what other commands are available to you, and help <command> for detailed information of said command. Note that this may not be an exhaustive list of commands; some may not have been compiled into the final binary, depending on your .config.

Try to perform the following:

• Print the available environment (env u-boot command).
• Check out the vendor and System on Chip (SOC) values.
• Print the available eMMC devices, as well as their partition tables (if any are available).
• Perform a memory test on the first GB of DRAM. Note that U-Boot relocates itself toward the end of the DRAM bank during its initialization phase (check bdinfo for the exact address). Stay away from that region unless you want to overwrite BL33 itself with your test pattern.

Finally, let's test the USB Mass Storage emulation of the eMMC using u-boot (which will allow us to access the board's internal flash memory direcrly from our ;laptops / PCs via USB-C). Try the ums command (use Google/LLMs for its arguments ;) ).