How ARM Systems are Booted: An Introduction to the ARM Boot Flow

Im ersten unserer Vorträge auf der ELC-E gab Rouven Czerwinski am Dienstag einen Überblick über den Bootprozess auf der ARM64 Plattform. Der Vortrag war Teil der neuen "Embedded Essentials"-Serie: Die Idee dabei war, gerade neuen Teilnehmern einen Überblick über mehr allgemeinere und nicht so hoch spezialisierte Themenbereiche zu geben. Das Konzept scheint aufzugehen - der Vortragssaal war gut gefüllt.

Im Gegensatz zu ARM32, wo am Bootprozess im Wesentlichen der Bootloader und der Kernel beteiligt sind und nur zwei Exception-Level relevant sind, sind auf ARM64 weitere Komponenten involviert.

Die erste Stufe besteht aus dem ROM-Code (BL1), dessen Aufgabe das Laden der weiteren Stufen vom Massenspeicher ist; dieser Teil ist weiterhin herstellerspezifisch. Hier gibt es für Entwicklungszwecke einen Mechanismus zum Laden über serielle Schnittstellen. Die zweite Stufe (BL2) besteht dann entweder aus einem U-Boot SPL, einem barebox PBL oder einer TF-A.

Die ARM Trusted Firmware (TF-A) implementiert eine Reihe von standardisierten Firmware Runtime Services, z.B. PSCI oder SCMI. Leider ist die TF-A unter der MIT Lizenz lizensiert, was die Hersteller nicht dazu zwingt, ihren Sourcecode auch immer zu veröffentlichen oder durch ein etabliertes Review-Verfahren (wie z.B. beim Kernel üblich) qualitätszusichern. Neben dem Secure Boot-Mechanismus stellt die TF-A auch das DDR Link Training, das Frequency Scaling und das Power State Coordination Interface (PSCI) zur Verfügung.

SCMI, das System Control and Memory Interface, kümmert sich um das An- und Abschalten von CPU Cores sowie um die Takte; diese Dienste müssen in der TF-A implementiert werden, da es z.B. passieren kann, dass Linux einen Takt nicht benötigt, die Secure World jedoch schon.

Der eigentliche Bootloader startet dann in Exception Level 2 und wertet dann in der Regel den Open Firmware Devicetree aus und stellt die bootloaderüblichen Mechanismen bereit, um einen Kernel zu beschaffen und zu starten.

Im Gegensatz zu ARM32 gibt es keinen standardisierten Dekompressor im Kernel, so dass der Bootloader diese Aufgabe übernehmen muss. Im Anschluss werden die Interrupts maskiert, der Standard Timer initialisiert und der Kernel an eine definierte Adresse geladen. Die MMU und die Data Caches werden abgeschaltet, die Adresse des Devicetrees in Register 0 geladen und der Kernel angesprungen.

All Attendees Reception

Wie in 2015 (als die ELC-E zum letzten Mal in Dublin war), fand die Teilnehmer-Party im Guiness Storehouse statt. Das Gebäude ist eine nette Location, allerdings ist es aufgrund der Tatsache, dass durch die gemeinsame Veranstaltung mit dem Open Source Summit auch viele Entwickler aus komplett anderen Themenfeldern wie Cloud, Kubernetes und Hyperledger dabei sind, immer etwas schwierig, neue Embedded-Leute auf der Veranstaltung zu finden.

In jedem Fall war der Abend eine nette Gelegenheit, Kontakte zu pflegen und herauszufinden, was die anderen Embedded Linux Entwickler in den Corona-Jahren so alles getrieben haben, während ein persönliches Treffen nicht möglich war.