# Booten von Blobs zwischen U-Boot und Linux > [! hinweis]- > Der Inhalt dieser Seite ist durch Audio/Video-Transkribtion und Text-Transformation aus dem Inhalt und Links dieser Quelle generiert. Quelle: [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> ## Zusammenfassung & Highlights: Zusammenfassung: Die Session 'Booting blobs between U-Boot and Linux' behandelt die Herausforderungen und Lösungen bei der Reihenfolge von Bootloader-Blobs, um volle Ressourcenzugänglichkeit und sichere Updates zu ermöglichen. **Einführung in die Bootloader-Stack-Problematik** Der Vortrag beginnt mit einer Einführung in die Problematik der Bootloader-Stacks, die aus verschiedenen Softwarekomponenten bestehen. Traditionell war der Bootloader ein einzelnes Programm, das direkt mit der Hardware interagierte. Mit der Zeit wurde das System komplexer und besteht nun aus mehreren Komponenten, die auf verschiedenen CPU-Kernen laufen. **Reihenfolge und Zugänglichkeit der Blobs** Es wird erläutert, wie Blobs wie PSCI und TEE zwischen BootROM und U-Boot gestartet werden und welche Nachteile dies mit sich bringt. U-Boot kann als Debug-Tool eingeschränkt sein, wenn es nicht vollen Zugriff auf alle Systemressourcen hat. Durch das Starten von U-Boot vor den meisten Blobs kann es uneingeschränkten Zugriff auf die Plattform erhalten. **Lösungen für ABI-Probleme** Ein wesentlicher Teil der Diskussion dreht sich um die ABI-Problematik (Application Binary Interface) und wie inkompatible Änderungen vermieden werden können. Durch das Neuanordnen der Reihenfolge der Blobs kann U-Boot als PSCI-Anbieter fungieren und die Blobs sicher aktualisiert werden. **Praktische Umsetzung mit fitImage** Der Vortrag beschreibt die Nutzung von fitImage, einem Multi-Komponenten-Image-Format, das eine sichere Aktualisierung der Blobs ermöglicht. U-Boot kann fitImages booten, die Kernel, Gerätebäume und TFA BL31 enthalten, um ABI-Konflikte zu vermeiden. **Abschluss und Fragen** Zum Abschluss wird die Bedeutung dieser Änderungen für die Systemstabilität und Update-Sicherheit hervorgehoben. Fragen aus dem Publikum werden beantwortet, um die Praxisrelevanz der vorgestellten Lösungen zu unterstreichen. ## Bedeutung für eine öko-soziale Transformation Diese Session hat eine hohe Relevanz für die ökosoziale Transformation, da sie die Aktualisierungssicherheit und Systemstabilität in offenen Hardwareprojekten verbessert. Dies ist besonders wichtig für nachhaltige Technologien, die auf langfristigen Support angewiesen sind. Eco-Social Designer können von den vorgestellten Methoden profitieren, indem sie sicherstellen, dass ihre Systeme auch nach Updates zuverlässig funktionieren. Herausforderungen bestehen in der Komplexität der Implementierung und der Notwendigkeit, proprietäre Blobs durch offene Alternativen zu ersetzen, um vollständige Transparenz und Kontrolle zu gewährleisten. ## Slides: | | | | --- | --- | | ![[FOSDEM 2025/assets/Booting-blobs-between-UBoot-and-Linux/preview_001.jpg\|300]] | Die erste Folie stellt das Thema 'Booting blobs between U-Boot and Linux' vor und nennt den Sprecher Marek Vasut. Das Datum des Vortrags ist der 1. Februar 2025. | ![[FOSDEM 2025/assets/Booting-blobs-between-UBoot-and-Linux/preview_002.jpg\|300]] | Diese Folie erläutert die Entwicklung des Bootloader-Stacks von der Vergangenheit bis zur Zukunft. Der Bootloader ist eine Software, die zwischen dem Einschalten des Systems und dem Start des Betriebssystemkerns läuft. Über die Jahre hat sich der Bootloader-Stack zu einer komplexen, mehrkomponentigen Software entwickelt, die auf mehreren Kernen läuft. | ![[FOSDEM 2025/assets/Booting-blobs-between-UBoot-and-Linux/preview_003.jpg\|300]] | In der Vergangenheit war der Bootloader ein einziges Programm, das direkt im Speicher abgebildet war und bei Systemstart ausgeführt wurde. Der Bootloader führte Hardware-Initialisierungen durch und lud den Kernel, der dann ebenfalls Hardware-Interaktionen übernahm. | ![[FOSDEM 2025/assets/Booting-blobs-between-UBoot-and-Linux/preview_004.jpg\|300]] | Heute besteht der Bootloader-Stack aus mehreren Programmen mit unterschiedlichen Lizenzen. Der BootROM ist im SoC integriert und geschlossen, während andere Komponenten wie TFA und U-Boot Open Source sind. Verschiedene Bootloader-Stufen können direkt mit der Hardware interagieren und diese initialisieren. | ![[FOSDEM 2025/assets/Booting-blobs-between-UBoot-and-Linux/preview_005.jpg\|300]] | In der Zukunft werden Bootloader-Stufen auf verschiedenen CPU-Kernen laufen. Sicherheitskerne wie Cortex-M oder Cortex-R sind immer aktiv und übernehmen die Kontrolle über sichere Hardwareblöcke. Anwendungskerne steuern unsichere Hardware. Der Bootloader interagiert über ABI mit Sicherheitskernen, um auf sichere Hardware zuzugreifen. | ![[FOSDEM 2025/assets/Booting-blobs-between-UBoot-and-Linux/preview_006.jpg\|300]] | Bootloader-Stufen laufen in verschiedenen Exception Levels (EL). EL3 hat uneingeschränkten Zugriff, während EL2 für Hypervisor und EL1 für virtualisierte Betriebssysteme reserviert ist. Der Wechsel zwischen diesen Levels erfolgt über spezielle Befehle. Diese Architektur ermöglicht es, Zugriffsrechte und Schutzmechanismen zu definieren. | ![[FOSDEM 2025/assets/Booting-blobs-between-UBoot-and-Linux/preview_007.jpg\|300]] | Bootloader-Stufen können verschiedene Dienste bereitstellen, die über feste Adressaufrufe oder spezielle Schnittstellen wie SMC/HVC aufgerufen werden. Diese Dienste umfassen PSCI für Energieverwaltung und SCMI für Systemsteuerung. Die Schnittstellen zu diesen Diensten sind ein ABI, das durch nicht standardisierte Erweiterungen in Anbieterpaketen oft gebrochen wird. | ![[FOSDEM 2025/assets/Booting-blobs-between-UBoot-and-Linux/preview_008.jpg\|300]] | Ein stabiles Firmware-ABI ist entscheidend, um Systemupdates ohne Bootfehler durchführen zu können. Ein Kernel-Update kann fehlschlagen, wenn das neue ABI nicht unterstützt wird. Im schlimmsten Fall kann ein System unbrauchbar werden, wenn das Bootloader-Update ebenfalls fehlschlägt und keine Rückfalloption verfügbar ist. | ![[FOSDEM 2025/assets/Booting-blobs-between-UBoot-and-Linux/preview_009.jpg\|300]] | Bootloader-Stufen können Ressourcen schützen, indem sie Zugriffsbeschränkungen auf Peripheriegeräte und Speicherbereiche einrichten. Während dies den Debugging-Funktionen von U-Boot entgegenwirken kann, bietet es auch die Möglichkeit, durchdachtes Debugging und Fehlerbehandlung zu ermöglichen, wenn die Schutzmechanismen offen und verständlich sind. | ![[FOSDEM 2025/assets/Booting-blobs-between-UBoot-and-Linux/preview_010.jpg\|300]] | Der Plan sieht vor, die Reihenfolge der Bootloader-Stufen neu zu ordnen, um U-Boot in EL3 laufen zu lassen. Dadurch erhält U-Boot vollen Zugriff auf die Plattform, bevor TFA und TEE gestartet werden. Dies ermöglicht es, die Blobs sicher zu aktualisieren und den Kernel in einem konsistenten Zustand zu starten. | ![[FOSDEM 2025/assets/Booting-blobs-between-UBoot-and-Linux/preview_011.jpg\|300]] | Es gibt zwei plattformspezifische Probleme zu lösen: U-Boot könnte von PSCI/SCMI-Aufrufen abhängen, und TFA BL31/TEE könnte vor U-Boot gestartet werden. Diese Abhängigkeiten müssen gelöst werden, um die Reihenfolge der Stufen zu ändern. | ![[FOSDEM 2025/assets/Booting-blobs-between-UBoot-and-Linux/preview_012.jpg\|300]] | Die Entfernung der U-Boot-Abhängigkeit von PSCI/SCMI-Diensten ist machbar, es sei denn, der Anbieter ist geschlossen. U-Boot kann in EL3 laufen und direkt auf Register zugreifen, um Dienste wie Taktung und Pin-Multiplexing zu steuern, ohne PSCI/SCMI-Dienste aufzurufen. | ![[FOSDEM 2025/assets/Booting-blobs-between-UBoot-and-Linux/preview_013.jpg\|300]] | Auf ARM64 ist PSCI obligatorisch, SCMI optional. U-Boot kann in EL3 als PSCI-Anbieter fungieren, bis der Benutzer einen eigenen Anbieter startet. Die vollständige PSCI-Implementierung ist SoC-spezifisch, aber eine grundlegende Implementierung kann generisch sein. | ![[FOSDEM 2025/assets/Booting-blobs-between-UBoot-and-Linux/preview_014.jpg\|300]] | Es gibt zwei Möglichkeiten, TFA BL31 von U-Boot in EL3 zu starten: direkt über die U-Boot-Shell für die Entwicklung oder durch direkten Sprung zu Linux über ein fitImage, das TFA BL31, Linux und Gerätebäume enthält. | ![[FOSDEM 2025/assets/Booting-blobs-between-UBoot-and-Linux/preview_015.jpg\|300]] | fitImage ist ein Multi-Komponenten-Image-Typ, der auf dem Device Tree basiert und mehrere Images in einem Container bündeln kann. U-Boot kann fitImages booten, und OpenEmbedded Core kann sie generieren. Es wird für alle modernen Systeme empfohlen, die U-Boot verwenden. | ![[FOSDEM 2025/assets/Booting-blobs-between-UBoot-and-Linux/preview_016.jpg\|300]] | U-Boot kopiert die in der ausgewählten fitImage-Konfiguration referenzierten Images an ihre Zieladressen im Speicher und führt für jedes Image eine loadable handler-Funktion aus. Anbieter-spezifische TFA BL31-Forks können zusätzliche Einrichtung erfordern. | ![[FOSDEM 2025/assets/Booting-blobs-between-UBoot-and-Linux/preview_017.jpg\|300]] | Ein neuer Bildtyp für TFA BL31 wurde in die fitImage-Unterstützung integriert. Diese Änderung ermöglicht es, TFA BL31 als Teil eines fitImage zu laden und zu starten, wobei der Bootprozess durch spezifische Handler gesteuert wird. | ![[FOSDEM 2025/assets/Booting-blobs-between-UBoot-and-Linux/preview_018.jpg\|300]] | Der Loadable Handler wird aufgerufen, nachdem das TFA BL31-Firmware-Blob vom fitImage an die Zieladresse im Speicher geladen wurde. Es kann Übergabetabellen oder Parameter für die Firmware einrichten und ist für jeden Bildtyp mit einem Makro definierbar. | ![[FOSDEM 2025/assets/Booting-blobs-between-UBoot-and-Linux/preview_019.jpg\|300]] | Der Jump Handler Prep wird kurz vor dem Start des Linux-Kernels aufgerufen und läuft in EL3. Er führt die endgültige Einrichtung durch und springt zu einem Einstiegspunkt, der der TFA BL31-Einstiegspunkt sein kann. TFA BL31 kehrt zu U-Boot zurück, aber in EL2. | ![[FOSDEM 2025/assets/Booting-blobs-between-UBoot-and-Linux/preview_020.jpg\|300]] | Die Integration von TFA BL31 in die fitImage ITS-Quelle erfolgt als Firmware-Knoten. Das fitImage wird mit dem Befehl mkimage erstellt und kann verschiedene Komponenten wie Kernel, FDT und TFA BL31 enthalten. | ![[FOSDEM 2025/assets/Booting-blobs-between-UBoot-and-Linux/preview_021.jpg\|300]] | Das Beispiel zeigt, wie U-Boot ein fitImage lädt, das TFA BL31 enthält. Der Bootprozess wird detailliert beschrieben, einschließlich der Überprüfung der Hash-Integrität und der Ladeadressen für Kernel und Gerätebaum. | ![[FOSDEM 2025/assets/Booting-blobs-between-UBoot-and-Linux/preview_022.jpg\|300]] | Beim Start von Linux meldet das System die Erkennung der PSCI-Version und die Aktivierung mehrerer CPU-Kerne. Dies zeigt, dass die Integration von TFA BL31 erfolgreich war und alle CPU-Kerne gestartet wurden. | ![[FOSDEM 2025/assets/Booting-blobs-between-UBoot-and-Linux/preview_023.jpg\|300]] | Das A/B-Update von TFA BL31, das in fitImage gebündelt ist, ist einfach. Mehrere fitImages können im Dateisystem gespeichert sein, und U-Boot kann eines zum Booten auswählen. Diese Methode vermeidet ABI-Mismatches zwischen Kernel und Firmware. | ![[FOSDEM 2025/assets/Booting-blobs-between-UBoot-and-Linux/preview_024.jpg\|300]] | Der Vortrag endet mit einem Dank an das Publikum und der Möglichkeit, Fragen zu stellen. Marek Vasut steht für weitere Diskussionen zur Verfügung. ## 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 (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)