Abstract

This presentation will talk about how SoCs can leverage Binman to simplify the overall boot-loader build flow. We use Texas Instruments (TI) K3 family of SoCs as an example, which, like many other SoCs today, use custom tools to build and sign their boot-loader binaries. However, U-Boot contains a powerful and flexible packaging tool Binman and this can be extended to sign and package even complex boot-loader images.

The session outlines the challenges in maintaining and shipping custom tools for any sort of build, highlighting its limitations in scaling, maintaining consistency and accommodating evolving system requirements. This presentation shows the effort in leveraging Binman, moving towards a completely open-source solution that also simplifies the build using K3 devices as an example. We also aim to present how we can make Binman the standard when it comes to the developing boot-loaders for any OS. A few platforms such as Kontron i.MX8M and Renesas RZ/N1 already use Binman to package their boot-loader binaries but we see that there is a larger scope of pulling all platform packaging to the standard.

Description

The boot loader images involved in booting a TI K3 device to Linux are: - tiboot3.bin: containing SPL (Secondary Program Loader) for the R5 core, may include system firmware for certain devices - sysfw.itb: containing system firmware and board configuration binaries - u-boot.img: containing the U-Boot image that can load the final Linux kernel image

In addition to the complexity of the K3 boot flow, each boot-loader image is packaged differently according to the whether the device: - is a High-Security Field Securable (HS-FS), High-Security Enforced (HS-SE) or General Purpose (GP) - follows Combined or Legacy boot flow - contains system firmware (SYSFW) split into Texas Instruments Foundational Security (TIFS) and Device Manager (DM) or not split

This leads to four similar yet unique boot flows. Since the image must account for a combination of the three choices, packaging the boot-loader is a complex process that involves signing as well.

This was earlier achieved using TI custom solution repositories, k3-image-gen and core-secdev-k3. k3-image-gen was responsible for generating and packaging board configuration data and system firmware binaries into tiboot3.bin or sysfw.itb while core-secdev-k3 was used for signing the required binaries in the case of HS devices. The flow looked like this.

The upstreaming effort proposed a flow that embedded the functionalities of k3-image-gen and core-secdev-k3 using Binman shown here.

Now by migrating the boot-loader generation to Binman, complex shell scripts that stitched boot images together are no longer needed. Instead, the generation is standardized to creation using the binman node in the DTS, for example: tiboot3 { filename = "tiboot3.bin"; ti-secure-rom { content = <&u_boot_spl>, <fw1>, <fw2> ...; keyfile = "key.pem"; load = <LOAD_ADDR>; load-fw1 = <LOAD_ADDR_FW1>; load-fw2 = <LOAD_ADDR_FW2>; ... }; u_boot_spl: u-boot-spl { }; fw1: fw1 { filename = fw1.bin; }; fw2: fw2 { filename = fw2.bin; }; ... }; An example of a proper application of the Binman node for K3 devices can be seen here. You can view the entire patch series that was submitted and has been accepted in the resources or here.

This presentation will provide an overview of the tool, understanding how to migrate your custom tools and platforms to Binman with K3 as an example and finally discuss current challenges and limitations while expanding to other platforms in U-Boot. Attendees will obtain insights into a practical implementation of Binman, its integration within existing workflows and best practices to leverage this tool to optimize U-Boot boot-loader development.