This is an old revision of the document!
01. [??p] Preparing the Flattened μImage Tree
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 structured binary blob of data that the kernel parses to identify hardware elements.
- RootFS: A file system that can be mounted at
/in order to load init. Here, we will use a ramdisk image.
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, bl33 also knows 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.
[??p] Task A - Linux kernel
Clone the kernel from the official github repo. Since you've built U-Boot previously, you should be somewhat familiar with the Kbuild system. Generate the default ARM configuration file and compile the kernel.
Note that the kernel image you will be including in the FIP is called Image. Unlike vmlinux which is an ELF file (i.e.: contains useless sections, including .debuginfo if you want to debug the kernel), Image is a boot executable image, made specifically for you to jump straight in and start executing. After the build process finalizes, find the Image file within the Linux repo.
make -j, unless you want to waste an hour for Linux to build. Do not forget about the
CROSS_COMPILE argument. Set the
ARCH argument to the appropriate architecture. Check out the subdirectories in linux/arch/ for possible values.
./scripts/clang-tools/gen_compile_commands.py
This will generate a compile_commands.json file that contains the gcc invocation cmdline. Any half decent language server will be able to (automatically) parse this file and deduce the include paths and definitions used. This will enable features like go-to-definition between different source files and much more.
Note that this script only works on Linux. For a more generic tool, try bear. Be warned though that its LD_PRELOAD hooking of exec() calls (needed to extract the cmdargs) interferes with the Automake configuration stage.
[??p] Task B - Flattened Device Tree
Luckily, the FDT for our platform is also included in Linux. It's name should be imx8mq-pico-pi.dtb.
If for some reason it wasn't built alongside the kernel Image, check out the dtbs make target.
[??p] Task C - Root Filesystem
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 (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. For example, the OpenSSH package available via pacstrap will come with a default build of sshd (the SSH server). On some critical infrastructure however, you might want to harden the SSH server binary by using a custom dynamic loader instead of ld-linux which allows LD_PRELOAD hooks.
Between Yocto and Buildroot, we generally opt for Buildroot. While Yocto has its 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.: ~50G 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.
Step 1: Download Buildroot
Clone the official Buildroot repo.
Step 2: Create the configuration
Find an existing defconfig for our platform (the imx8mq) and take a look at what it contains. Notice how the following config options are enabled:
BR2_LINUX_KERNEL=y BR2_TARGET_ARM_TRUSTED_FIRMWARE=y BR2_TARGET_UBOOT=y
Yes, Buildroot also integrates the bootloaders into its build system. However, 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, after generating .config, enter menuconfig and make a few changes:
- Disable all components that we've already integrated in our build environment (starting with the ones above).
- Use an external, custom, pre-installed toolchain.
- Use systemd as the init system instead of BusyBox.
- Use bash as the default shell instead of sh.
- Set “root” as password for the root user.
- Include a text editor package (e.g.: vim or nano).
- Generate an uncompressed CPIO image from the output file system (see the Note below).
$ cd /path/to/rootfs $ find . | cpio -o > /path/to/ramdisk.cpio
