# Booting Blobs between U-Boot and Linux using fitImage > [! note]- > The content of this page is generated by audio/video transcription and text transformation from the content and links of this source. Source: [https://fosdem.org/2025/schedule/event/fosdem-2025-6084-booting-blobs-between-u-boot-and-linux/](https://fosdem.org/2025/schedule/event/fosdem-2025-6084-booting-blobs-between-u-boot-and-linux/) <video src="https://video.fosdem.org/2025/h1302/fosdem-2025-6084-booting-blobs-between-u-boot-and-linux.av1.webm" controls></video> ## Summary & Highlights: In this session, Marek Vasut presents a method to reorder bootloader blobs, allowing U-Boot to run before other blobs and gain full access to system resources before booting Linux. This approach helps avoid issues with updating blobs and ensures the system remains debuggable. **Introduction to Bootloader Blobs** Bootloader blobs, such as PSCI and TEE, are traditionally started between BootROM and U-Boot. These blobs can restrict U-Boot's access to system resources, complicating updates and debugging. Marek Vasut proposes starting U-Boot before these blobs to circumvent these issues. **Reordering the Bootloader Stack** The session explains the process of reordering the bootloader stack, where U-Boot runs in EL3, allowing it unrestricted access to the platform. This setup enables U-Boot to start other blobs, like TFA BL31, ensuring compatibility with Linux. **Implementation and Benefits** The talk covers the implementation details, including using fitImage to bundle components and manage updates. This method supports safe A/B updates, avoiding ABI mismatches and ensuring stable system updates. The approach enhances system reliability and debugging capability. ## Importance for an eco-social transformation This session's relevance to eco-social transformation lies in its potential to improve the sustainability and reliability of embedded systems, which are key components in various eco-friendly technologies. By enhancing system debugging and update processes, this method can reduce electronic waste and improve the longevity of devices. Eco-social designers can apply these techniques to develop more robust and sustainable hardware solutions. Challenges include overcoming proprietary restrictions and ensuring open-source compatibility across different hardware platforms. ## Slides: | | | | --- | --- | | ![[FOSDEM 2025/assets/Booting-blobs-between-UBoot-and-Linux/preview_001.jpg\|300]] | The first slide introduces the session 'Booting blobs between U-Boot and Linux' presented by Marek Vasut on February 1st, 2025. It sets the stage for a discussion on improving bootloader processes to enhance system access and update capabilities. | ![[FOSDEM 2025/assets/Booting-blobs-between-UBoot-and-Linux/preview_002.jpg\|300]] | This slide outlines the evolution of the bootloader stack from a simple software running between power on and OS kernel to a complex multi-component system operating across multiple cores. It highlights the growing complexity and the need for new approaches. | ![[FOSDEM 2025/assets/Booting-blobs-between-UBoot-and-Linux/preview_003.jpg\|300]] | The slide describes the past state of bootloaders as single programs like U-Boot stored in direct-mapped memory. It details how CPUs executed NOR content on power-up, directly interacting with hardware for initialization and kernel loading. | ![[FOSDEM 2025/assets/Booting-blobs-between-UBoot-and-Linux/preview_004.jpg\|300]] | The present state of bootloaders involves multiple stages from various projects with different licenses. BootROM, TFA, TEE, and U-Boot are stored in various memory devices, with CPUs executing BootROM on power-up and handling hardware interactions. | ![[FOSDEM 2025/assets/Booting-blobs-between-UBoot-and-Linux/preview_005.jpg\|300]] | Future bootloader stages will run on different CPU cores, with safety cores always on and application cores as needed. Safety cores will control secure hardware blocks, while non-secure hardware may be managed by application cores via ABI. | ![[FOSDEM 2025/assets/Booting-blobs-between-UBoot-and-Linux/preview_006.jpg\|300]] | Bootloader stages operate at different exception levels, with EL3 having unrestricted access. Switching between levels involves exception returns and instructions, allowing for layered hardware access and control. | ![[FOSDEM 2025/assets/Booting-blobs-between-UBoot-and-Linux/preview_007.jpg\|300]] | Bootloader stages provide services like PSCI and SCMI, accessed via function calls or exceptions. These services form an ABI, but non-standard extensions and broken changes across vendor packages can cause issues. | ![[FOSDEM 2025/assets/Booting-blobs-between-UBoot-and-Linux/preview_008.jpg\|300]] | The firmware ABI must remain stable to avoid system update failures. A mismatch between kernel and bootloader ABIs can lead to boot failures, but recovery is possible if the old ABI is still supported. | ![[FOSDEM 2025/assets/Booting-blobs-between-UBoot-and-Linux/preview_009.jpg\|300]] | Bootloader stages can protect resources by configuring TrustZone and MMU tables. While resource protection is beneficial, it can hinder U-Boot's debugging capabilities if higher EL blobs block access. | ![[FOSDEM 2025/assets/Booting-blobs-between-UBoot-and-Linux/preview_010.jpg\|300]] | The plan involves reordering the bootloader stack to allow U-Boot to run in EL3, giving it full access to the platform. This change enables U-Boot to start other blobs and improve system debugging and updates. | ![[FOSDEM 2025/assets/Booting-blobs-between-UBoot-and-Linux/preview_011.jpg\|300]] | Implementation challenges include removing U-Boot's dependency on PSCI/SCMI calls and ensuring TFA BL31/TEE starts after U-Boot. Solutions involve running U-Boot in EL3 and managing blob dependencies. | ![[FOSDEM 2025/assets/Booting-blobs-between-UBoot-and-Linux/preview_012.jpg\|300]] | Removing U-Boot's PSCI/SCMI dependency is feasible unless the provider is closed source. Implementing direct register access in U-Boot running in EL3 can bypass the need for PSCI/SCMI services. | ![[FOSDEM 2025/assets/Booting-blobs-between-UBoot-and-Linux/preview_013.jpg\|300]] | U-Boot can act as a PSCI provider, mandatory for ARM64. A basic implementation can be generic, but a full implementation is SoC-specific. U-Boot can serve as a fallback PSCI provider until the user one starts. | ![[FOSDEM 2025/assets/Booting-blobs-between-UBoot-and-Linux/preview_014.jpg\|300]] | Two methods for starting TFA BL31 from U-Boot in EL3 are direct via U-Boot shell or using fitImage. The latter bundles TFA BL31 with Linux and other components, streamlining the boot process. | ![[FOSDEM 2025/assets/Booting-blobs-between-UBoot-and-Linux/preview_015.jpg\|300]] | fitImage is a multi-component image type that bundles various images into a single container. U-Boot and OpenEmbedded can boot and generate fitImage, recommended for contemporary systems. | ![[FOSDEM 2025/assets/Booting-blobs-between-UBoot-and-Linux/preview_016.jpg\|300]] | U-Boot copies images from fitImage to memory, running loadable handlers for each. Vendor-specific TFA BL31 forks may require extra setup, but handlers for Renesas R-Car V4H have been added. | ![[FOSDEM 2025/assets/Booting-blobs-between-UBoot-and-Linux/preview_017.jpg\|300]] | The fitImage TFA BL31 image type involves adding entries to U-Boot's image loader to recognize and handle TFA BL31 images, enabling seamless integration into the boot process. | ![[FOSDEM 2025/assets/Booting-blobs-between-UBoot-and-Linux/preview_018.jpg\|300]] | The loadable handler for TFA BL31 sets up parameters for the firmware and caches the load address. It is defined using a macro for any image type, facilitating integration into the boot process. | ![[FOSDEM 2025/assets/Booting-blobs-between-UBoot-and-Linux/preview_019.jpg\|300]] | The kernel jump prep handler is called before the Linux kernel starts, performing final setup and jumping to TFA BL31. It ensures U-Boot re-enters at the correct point to continue the boot process. | ![[FOSDEM 2025/assets/Booting-blobs-between-UBoot-and-Linux/preview_020.jpg\|300]] | fitImage integration involves defining a firmware node in the ITS source, specifying TFA BL31 as a loadable. The image is built using mkimage and includes configurations for booting Linux. | ![[FOSDEM 2025/assets/Booting-blobs-between-UBoot-and-Linux/preview_021.jpg\|300]] | An example of booting a fitImage with TFA BL31 shows the process of loading kernel, FDT, and loadables. The example demonstrates the successful boot of Linux with all components integrated. | ![[FOSDEM 2025/assets/Booting-blobs-between-UBoot-and-Linux/preview_022.jpg\|300]] | During the Linux boot process, PSCI is detected and used to bring up secondary CPUs. The example highlights successful CPU activation and feature detection, ensuring a smooth boot process. | ![[FOSDEM 2025/assets/Booting-blobs-between-UBoot-and-Linux/preview_023.jpg\|300]] | A/B updates of TFA BL31 bundled in fitImage are straightforward, allowing multiple copies and selection based on criteria like boot counter. This approach avoids ABI mismatches and enhances update reliability. | ![[FOSDEM 2025/assets/Booting-blobs-between-UBoot-and-Linux/preview_024.jpg\|300]] | The session concludes with a thank you from Marek Vasut, inviting questions and discussions on the presented method for managing bootloader blobs. ## Links [Slides](https://fosdem.org/2025/events/attachments/fosdem-2025-6084-booting-blobs-between-u-boot-and-linux/slides/237946/fosdem-20_yAbxn8f.pdf) [Video recording subtitle file (VTT)](https://video.fosdem.org/2025/h1302/fosdem-2025-6084-booting-blobs-between-u-boot-and-linux.vtt) [Video recording (AV1/WebM)](https://video.fosdem.org/2025/h1302/fosdem-2025-6084-booting-blobs-between-u-boot-and-linux.av1.webm) [Video recording (MP4)](https://video.fosdem.org/2025/h1302/fosdem-2025-6084-booting-blobs-between-u-boot-and-linux.av1.mp4)