There are three vital components that are required to successfully boot Linux on ARM:

• Kernel image: This should be self-evident :P
• Flattened Device Tree: A blob (.dtb) of compiled hierarchical data that the kernel parses to identify hardware elements;
• RootFS: A file system that can be mounted at / in order to load the init executable. Here, we will use a ramdisk image (which will be **surprise pause** stored in RAM!).

Although these components can be manually loaded and configured for boot from U-Boot, it's preferable to package them together in a Flattened μImage Tree (FIT). Similarly to how bl1 and bl2 know how to load the binaries that comprise the FIP we generated in the previous lab, so does bl33 know how to boot the system from a FIT.

In the following tasks we will create each individual component and package them together. Finally, we will create a partition table (with one FAT partition) on the board's eMMC and store the FIT only to then load it and boot it from the bl33 shell.

Clone the kernel from the official GitHub repo, using the v6.12 tag. We recommend you to use this git cloning technique to avoid fetching the entire git history (requiring several GBs of disk space!).

Since you've built U-Boot previously, you should be somewhat familiar with the Kbuild system. Start by generating the build configuration from its default configuration. Optionally, run a menuconfig to inspect the Linux kernel options available.

In order to build the kernel image, simply make with the required variables (setting ARCH=? – see the warning above!).

While waiting for the build, explore the Linux source using your favorite code editor (especially the device trees)!

Note that the kernel image you will be including in the FIP is called Image. Unlike vmlinux which is an ELF file (it contains some useless-for-now sections like .debuginfo if you want to debug the kernel), Image is a boot executable image, made specifically for the CPU to jump straight in and start executing code from RAM. After the build process finishes, find the Image file within the <linux-src-dir>/arch/arm64/boot/ output directory.

./scripts/clang-tools/gen_compile_commands.py

Luckily, the Flattened Device Tree (FDT – .dtb file) for our platform is also included in Linux. It's name should be imx93-11x11-evk.dtb (generated from its source counterpart, imx93-11x11-evk.dts).

If for some reason it wasn't built alongside the kernel Image, you can always use the make … dtbs command to [re]compile them.

The kernel alone does NOT make a useable Operating System. It needs some userspace applications to at least supply a command-line interface for the human users (we won't be building a graphical UI, as it was to be expected). This means we have to find a way to build a root filesystem containing such programs and their required dependencies (shared libraries, configuration files etc.).

Usually there are two approaches to generating the root filesystem: bootstrapping from a source of pre-compiled binaries (e.g.: debootstrap, pacstrap, etc.) or building them yourself from source (e.g.: Yocto, Buildroot.) The former is usually preferred when working on desktop environments. The latter allows you to fine tune everything that is installed on your system and obtain much less disk space consumption!

Between Yocto and Buildroot, we generally opt for Buildroot. While Yocto has many advantages (e.g.: wide industry adoption, extensive device support, etc.), it also has a very steep learning curve and consumes significant amounts of resources (i.e.: ~50-100GB storage space for a build). Although it has a layer-based build customization feature (think Dockerfiles extending base images), we argue that this makes it more difficult to comprehend the contents of what is being built.

Buildroot on the other hand is geared towards simplicity and ease of use. Being based on Kbuild and Makefile (same as Linux and U-Boot) makes it instantly familiar to most developers. And even if you are new to this, while Yocto requires you to read entire books in order to utilize it properly, Buildroot can be summed up in a 1k LoC Makefile.

Clone the official Buildroot repo. We used the latest release, 2025.05.x, so make sure to fetch that branch (master should also work, but it is in continuous development and may break at any time! use the versioned branch if you want a hassle-free experience).

You can find all KConfig files inside <buildroot-src>/configs/ directory. There is even one for our imx93 platform, but we won't use it!

Buildroot also integrates the bootloader & kernel into its build system. However, such configurations won't work for our specific board and keeping the components separate makes it easier to appply patches and debug problems.

What we want from Buildroot is a minimal root filesystem and nothing more. So we'll start from a basic defconfig (that's it!), then proceed with menuconfig and make the following changes:

• Target Options → Aarch64 Little Endian;
  • To optimize: Model → Corted-A55;
• Enter System Configuration menu.
  • You can change the System Banner to your own liking;
  • Make sure you have Busybox as the Init System;
  • Enable root login with password, then set your desired password on the config below…
  • Choose bash as the default shell instead of sh;.
• Include a text editor PACKAGE (e.g.: search for PACKAGE_<PAKCKAGE_NAME>, VIM or nano)!
• You can optionally choose the python3 package!
• Generate an uncompressed CPIO image from the output file system (enable the TARGET_ROOTFS_CPIO option, see the Note below).

cd /path/to/rootfs
find . | cpio -o > /path/to/ramdisk.cpio

Feel free to add / remove anything else you want. Anything goes as long as you end up with a functioning system. After completing Step 3, maybe return and see if there's anything left to trim down to speed up the build process.

Not much to it, really, simply invoke make -j <NUM.CPUS> (no other parameters are required for Buildroot, no ARCH like the Linux Kernel). Once everything's done, check out the output/ directory. What does it contain? Where is your CPIO archive?

Like the flash.bin firmware package, we need to pack the kernel, FDT and rootfs together in a single file for convenience in booting.

Create a staging/ directory somewhere in your work dir and copy everything that we've obtained from the previous three tasks (see below for the files to be included inside the FIT). Then, create an Image Tree Source (ITS) file. We'll be referring to it as linux.its but the name doesn't really matter. What matters is the content:

/dts-v1/;

/ {
    description = "Linux FIT image for FRDM iMX93";
    #address-cells = <1>;

    images {
        kernel {
            description = "Linux kernel";
            data = /incbin/("Image");
            type = "kernel";
            arch = "arm64";
            os = "linux";
            compression = "none";
            /* load + entrypoint address (e.g., <0x12340000>), MUST BE VALID DRAM REGION!
             * also, do NOT ommit the '<>' characters!) */
            load = <XXX>;
            entry = <XXX>;
        };
        fdt {
            description = "Device tree";
            data = /incbin/("imx93-11x11-evk.dtb");
            type = "flat_dt";
            arch = "arm64";
            compression = "none";
            /* compute the next available DRAM address (e.g., add 64MB to the previous one) */
            load = <YYY>;
        };
        initrd {
            description = "Ramdisk";
            data = /incbin/("rootfs.cpio");
            type = "ramdisk";
            arch = "arm64";
            os = "linux";
            compression = "none";
            /* same, compute a valid next address (FDT is pretty small, couple of kilos) */
            load = <ZZZ>;
        };
    };

    configurations {
        default = "normal-boot";

        normal-boot {
            description = "Normal boot config";
            kernel = "kernel";
            fdt = "fdt";
            ramdisk = "initrd";
        };
    };
};

Let's analyze this:

• The file starts with /dts-v1/;, identifying it as a Device Tree Source.
• Next, we have a root / node with two child nodes: images and configurations.
  • images contains the description of each binary that will need to be loaded by U-Boot when processing the FIT.
    • Each image entry contains an incbin directive that tells mkimage to copy paste the contents of the specified file into the output DTB.
    • Each image also contains a load property, specifying the address where the data will be placed.
    • In addition to load, the kernel image also has an entry property specifying where U-Boot will jump when relinquishing control to the Linux kernel.
  • configurations contains sets of image configurations that can be chained.
    • The only configuration we have is also the default: normal-boot.
    • Notice how it has pre-defined attributes for kernel, fdt, ramdisk. These are not simple binary blobs; instead, they each have a role to play in the boot sequence. E.g., U-Boot will know to take the load address of the fdt image and pass it via a certain register (decided by convention) to the kernel, informing it where in memory to look for the FDT.

Note how we replaced the load and entry addresses with placeholders such as XXX. Replace these with whatever addresses you want such as the binaries do not overlap once U-Boot starts loading them.

Once all the addresses are filled in, generate the Image Tree Blob (ITB) using mkimage. Best not to use the imx-mkimage; instead, install mkimage using your distro's package manager (or find it pre-compiled by U-Boot at <uboot-src-path>/tools/mkimage).

../<path-to-uboot>/tools/mkimage -f linux.its linux.itb