This package will contain BL2, BL31 and BL33. The Secure OS (BL32) is outside the scope of this lab; even if we did bother to include it, it would just be there, doing nothing.

Following this exercise, we should be able to reach the first step of the booting sequence that can be interactive; meaning that we'll be able to interact with a shell implemented in BL33.

Never mind the fact that we begin with BL31, you can consider it a warmup.

For this, we'll be using the Trusted Firmware-A project. Although it contains reference implementations for the other bootloader components as well, we are going to use it strictly for BL31. The others have more complete and widely recognized alternatives available.

We recommend reading the documentation before moving forward. Also use the build options as reference.

In particular, search for the keys to specifying the platform, cross compiler, the secure payload dispatcher (we will need to tell it that we need none, also read below); additionally, controlling logging levels and specifying console device (UART) is always useful for when you run into problems!

Following a successful build process, you should obtain a bl31.bin file (take note if its location, for you will need it later).

With BL31 out of the way, we are going to tackle BL2 next (of course, BL1 is the first one to be loaded, but, fortunately, it comes carved inside our chip – into Read Only Memory).

BL1 is actually loaded from the SoC's ROM in the first half of the available Static RAM (the On-Chip RAM). This SRAM is just 128KB in size (remember, SRAM is quite expensive, similar to a cache memory), so there's not much space left for loading additional software.

Afterwards, BL1 loads BL2 in the upper half of SRAM and it stops here! the remainder of the firmware image is ignored. At this point it's up to BL2 to enable the rest of the memory (2GB of DRAM) and finish loading the rest of the FIP in main memory.

However, . So BL2 is to initialize the hardware using the proprietary firmware offered by the chip manufacturer. Without this firmware, we don't even have access to the DRAM memory.

Simply go here and download the self-extracting archive. After this, run it and accept the license agreement in order for it to extract its contents (oh, and since we're on Linux, don't forget to apply to executable bit – chmod +x <filename>).

What we're actually interested in are the following files:

• lpddr4_pmu_train_1d_dmem.bin
• lpddr4_pmu_train_1d_imem.bin
• lpddr4_pmu_train_2d_dmem.bin
• lpddr4_pmu_train_2d_imem.bin
• signed_hdmi_imx8m.bin

For the last two components of our Firmware Package we'll be using U-Boot (clone it!). Each of them has a very specific purpose.

At first, BL1 will start downloading the FIP (Firmware Image Package, which we'll generate later) using the Serial Download Protocol, running on top of a USB connection. Once it finishes receiving BL2 (together with the firmware binaries from Task B), it cedes control to it instead. BL2 will initialize the DRAM using said firmware and then continue where BL1 left off, finishing the download of the FIP.

When BL31 runs its course, BL33 will be called upon. During this phase we'll finally have an interactive shell and multiple drivers to help interact with the board. With this, we can investigate the board's hardware, read and potentially override the partitions in the persistent storage and most importantly, boot Linux from any number of sources.

Alright, let's get to it! U-Boot is based on the same build system as the Linux kernel, namely Kbuild. To get an idea of what functionality it provides, try to run:

$ make help

If you check the configs/ directory, you will find a number of board-specific configuration files. These serve as templates, containing the minimal necessary configuration. By running make some_defconfig the Kbuild system will determine what other unspecified options need to be enabled in order for these features to be functional. The result will be saved in a file called .config.

Generate a .config for your board by running the make <board's name>_defconfig.

Also, don't forget the CROSS_COMPILE variable from BL31 (you've exported it, right? if not, pass it as KEY=VALUE' argument to make). It's very common across such projects and Kbuild will actually complain if it sees that you're trying to use a x86 compiler.

The default configuration that you chose (correctly, hopefully) contains a few erroneous values for the USB driver. Normally these would take some time to dig up from the board's / processor's documentation / source code; we took them from the debug prints of the firmware that was pre-configured on the eMMC :P

Open a ncurses-based interface for editing the .config file:

$ make CROSS_COMPILE=... menuconfig

The interface should be fairly intuitive. Use the Arrow keys to navigate the entries, Space to toggle options on or off, Enter to dive into a submenu or open a prompt, and the ? key to get more information about the currently selected entry. If you see a letter highlighted in a different color, pressing the corresponding key will take you to that option. Note that multiple options can have the same keybind; pressing it will cycle you through to the next occurrence.

The search function for a specific option (by name) is the exact same as in less or vim: /[CONFIG_]MY_OPTION <Enter>. This will generate a list of potential matches, each bearing a numeric index. Press the key corresponding to that index in order to jump to the search result.

For now, change the following config variables and save the changes to .config:

• USB_GADGET_MANUFACTURER: ASS
• USB_GADGET_VENDOR_NUM: 0x1fc9
• USB_GADGET_PRODUCT_NUM: 0x012b

Run the make command (again, don't forget the cross compiler argument, if you haven't exported it already)!

The three files you should obtain are:

• spl/u-boot-spl.bin: aka. BL2.
• u-boot-nodtb.bin: aka. BL33.
• arch/arm/dts/imx8mq-pico-pi.dtb: a Device Tree Blob (DTB) which we'll also require; see details below.

# press Q to exit the paginator :p
$ dtc -I dtb -O dts imx8mq-pico-pi.dtb | less

Now that we have all necessary binaries either downloaded or compiled ourselves, all that is left is to combine them in a manner that can be understood by the processor's first boot stage (BL1).

Since 2022, U-Boot's tool of choice for this task is binman. This tool uses a platform-specific config file that specifies what components should be included and where they should be placed in memory. For our platform (i.e.: i.MX8M Quad) this file would be arch/arm/dts/imx8mq-u-boot.dtsi.

However, since the U-Boot version that we are using is older and the board manufacturer did not add proper support for binman, we are going to use the older method, based on mkimage (part of the U-Boot repo or as a package on most distros). In order to spare ourselves some pain, we are going to use NXP's imx-mkimage implementation which knows the proper offsets where the images should be loaded.

In their source tree you will find a number of subdirectories corresponding to different versions of the i.MX platform. Select the one which corresponds to our board (remember, the base model is called iMX8M). When you get there, you will have to copy all the bootloaders you compiled so far, as well as the downloaded firmware (trust us here: make a script to do this automatically! you'll need to do it tens – probably hundreds – of times!).

In addition to these, you will have to copy the base mkimage tool (generated in the U-Boot directory, see if you can find it ;) ); rename it as mkimage_uboot.

Once you have all these, run make with the flash_evk target, while specifying the platform in the SOC= make argument, and the name of the DTB copied over from U-Boot in the dtbs= argument. The output firmware image should be called flash.bin.

$ dtc -I dtb -O dts u-boot.itb | less