Interrupts (PI4)

Interrupts sind Signale, die den normalen Ablauf eines Prozessors unterbrechen, um spezielle Routineabläufe auszuführen. Sie spielen eine wichtige Rolle bei der Steuerung und Kommunikation in Echtzeitsystemen und bei der Handhabung von Hardware-Ereignissen.

Definition von Interrupts

Ein Interrupt ist ein Signal, das den CPU dazu veranlasst, den aktuell ausgeführten Befehlssatz zu unterbrechen und eine Interrupt Service Routine (ISR) oder Interrupt-Handler auszuführen.

Auslöser für Interrupts

Interrupts können durch verschiedene Ereignisse ausgelöst werden:

Externe Hardware-Ereignisse

• Tastatureingaben: Wenn eine Taste gedrückt wird.
• Mausbewegungen: Wenn die Maus bewegt wird oder eine Taste gedrückt wird.
• Timer: Timer können so konfiguriert werden, dass sie periodische Interrupts auslösen.

Interne Hardware-Ereignisse

• Peripheriegeräte: Ereignisse von Geräten wie Netzwerkadaptern, Festplatten, usw.
• Signale von Sensoren: Daten von Temperatursensoren, Beschleunigungssensoren, usw.

Betriebssystem-Ereignisse

• Systemaufrufe: Bestimmte Anfragen von Software an das Betriebssystem.
• Fehlermeldungen: Wenn Fehler wie Division durch Null oder Speicherzugriffsfehler auftreten.

Typen von Interrupts

Interrupts können auch kategorisiert werden in:

• Maskierbare Interrupts: Diese können vom CPU vorübergehend ignoriert oder maskiert werden.
• Nicht maskierbare Interrupts (NMI): Diese können nicht ignoriert werden und haben höchste Priorität.

---

Ja, der Raspberry Pi 4 muss sich in einem bestimmten Betriebsmodus befinden, um Interrupts effizient zu handhaben. Besonders wichtig sind die Interrupt-Freigabe (globale Interrupts) und der Modus des Prozessors.

Betriebsmodi und Interrupts

Der ARM-Cortex-A72-Prozessor, der im Raspberry Pi 4 verwendet wird, unterstützt verschiedene Ebenen und Modi, die sich auf das Verhalten von Interrupts auswirken können:

Interrupt Enable Stufe (EL1 und niedrigere Ebenen):

Der Prozessor muss sich in einem Modus befinden, in dem Interrupts erlaubt sind (EL1 oder niedriger). Dies bedeutet, dass die globalen Interrupts nicht deaktiviert sein dürfen. Dies wird durch das Setzen bestimmter Bits im Program Status Register (PSTATE) kontrolliert.

DAIF-Flags (erlauben Interrupts):

D: Debug-Exceptions A: SError-Interrupts I: IRQ-Interrupts F: FIQ-Interrupts Diese Flags können im DAIF-Register eingestellt werden. Um IRQ-Interrupts zu ermöglich, sollte das I-Flag gelöscht werden. Wichtige Befehle und Register

Hier ein Überblick über die relevanten Register und Befehle:

Programmstatusregister (PSTATE): Kontrolliert u.a. die globalen Interrupts. Beispiel (ARM-Assembly) zur Aktivierung von Interrupts

Folgender Code zeigt, wie man die IRQ-Interrupts explizit zulässt:

.global enable_interrupts

enable_interrupts:

   mrs x0, DAIF           // DAIF Register lesen
   bic x0, x0, #(1<<7)    // IRQ-Freigabe (Setze I-Flag auf 0)
   msr DAIF, x0           // DAIF Register zurückschreiben
   ret

Setup und Initialisierung

Stack Pointer setzen: Stelle sicher, dass der Stack Pointer korrekt initialisiert ist, bevor Interrupts aktiviert werden.

Setzen des Vektortabellenpointers: Leitet den Prozessor zu der richtigen Vektortabelle, welche die Adressen der ISR enthält.

.global _start _start:

   // Setup Stack Pointer und andere Initialisierungen hier
   //...

   // Set Vector Base Address Register (VBAR)
   LDR   x0, =vector_table
   MSR   VBAR_EL1, x0       // VBAR auf die Vektortabelle setzen

   // Interrupts aktivieren
   BL enable_interrupts

   // Hauptprogrammschleife

main_loop:

   //...
   B main_loop

.section .vectors .align 11 vector_table:

   b   irq_handler          // IRQ Interrupt Handler Adresse
   // Weitere Vektoren je nach Bedarf

Zusammenfassung Der Raspberry Pi 4 muss sich auf einem Berechtigungslevel (EL1 oder niedriger) befinden, in dem Interrupts (speziell IRQs) erlaubt sind. Die DAIF-Register müssen so eingestellt werden, dass Interrupts zugelassen werden. Eine korrekte Initialisierung der Vektortabelle und des Stack-Pointers sind essentiell, bevor Interrupts zugelassen werden.

Der ARM Cortex-A72 Prozessor, der im Raspberry Pi 4 verwendet wird, unterstützt ein hierarchisches Berechtigungslevel-System, das als Exception Levels (EL) bekannt ist. Jedes Level hat unterschiedliche Berechtigungsstufen und Verwendungszwecke. Hier sind die verschiedenen Exception Levels und ihre typischen Verwendungen:

Exception Levels (ELs):

EL0:

User Mode Läuft im nicht-privilegierten Modus. Dieser Level ist für Anwendungen und Benutzerprogramme vorgesehen. Hier laufen die nicht-privilegierten Aufgaben des Betriebssystems oder der Anwendungen.

EL1:

Kernel Mode Läuft im privilegierten Modus. Wird von Betriebssystemkernen oder hypervisorischen Dienstprogrammen verwendet. Hier findet die Hauptverwaltung der Hardware und des Speichers statt. Dieser Level hat Zugriff auf alle Systemressourcen und kann Interrupts verwalten.

EL2:

Hypervisor Mode Ebenfalls als Virtualization Exception Level bekannt, das für die Ausführung eines Hypervisors verwendet wird, der virtuelle Maschinen verwaltet. Es ermöglicht die Erstellung und Verwaltung mehrerer EL1-Umgebungen (z. B. verschiedene Betriebssysteme auf einer Hardware).

EL3:

Secure Monitor Mode Das höchste privilegierte Level, das für sichere Anwendungen und das TrustZone-Sicherheits-Monitor-Firmware verwendet wird. Hier können sicherheitskritische Funktionen ausgeführt werden, die von den anderen Levels abgeschottet sind. Zustände, die Interrupts betreffen: Normalerweise laufen Betriebssystem-Kernel und ihre ISRs auf EL1. Benutzeranwendungen laufen auf EL0 und machen Systemaufrufe, um in EL1-Privilegienstufe zu wechseln. Beispiel zur Entscheidung des Berechtigungslevels:

Beim Initialisieren des Raspberry Pi 4 sollten folgende Schritte durchgeführt werden, um sicherzustellen, dass sich das System im korrekten Level befindet:

.global _start

_start:

   // Initialisierung der Exception Levels (wenn notwendig)

   // Setze SP für EL1
   LDR x1, =stack_top_el1
   MSR SP_EL1, x1

   // Wechsel zu EL1
   MRS x0, CurrentEL          // Aktuelles Exception Level lesen
   CMP x0, #4                 // Prüfen ob aktuell ELx ist (gesetzt bei EL3)
   B.LE init_el               // Wenn bei EL1 oder niedriger, Initialisierung fortführen

   // Wechsel von EL3 zu EL1
   BL switch_to_el1

init_el:

   // EL1 Initialisierungslogik (z.B. VBAR, Stack, Interrupts etc.)
   ADR x0, vector_table       // Lade Adresse der Vektortabelle
   MSR VBAR_EL1, x0           // Setze VBAR_EL1 auf die Vektortabelle

   // Aktiviere Interrupts
   BL enable_interrupts

   // Hauptprogrammschleife

main_loop:

   B main_loop

// Funktion um von EL3 zu EL1 zu wechseln switch_to_el1:

   MSR SCR_EL3, #0x6          // Konfiguriere Secure Configuration Register (SCR) für EL1
   MRS x0, SPSR_EL3           // Sichere aktuelle SPSR_EL3
   BIC x0, x0, #(0xF << 6)    // Setze EL1
   ORR x0, x0, #0xD3          // Maskiere IRQ und FIQ und setze EL1h
   MSR SPSR_EL3, x0           // Schreibe das veränderte Register zurück
   ADR x0, el1_entry_point    // Lade Einstiegspunkt für EL1
   MSR ELR_EL3, x0            // Setze ELR_EL3 auf Einstiegspunkt
   ERET                       // Ausnahme zurückgeben über Exception Return

el1_entry_point:

   // Hier beginnt die Ausführung auf EL1
   RET
   

.section .vectors, "a" vector_table:

   B irq_handler              // IRQ Adresse
   // Weitere Vektoren für verschiedene Interruptarten

// Dummy-Interrupt-Handler irq_handler:

   // Interrupt Service Routine Logik hier
   RET

// Speicherplatz für Stack (zum Beispiel bei EL1) .section .bss .stack_area:

   .skip 0x1000               // Speicherplatz reservieren

stack_top_el1:

In diesem Ansatz wird sichergestellt, dass das System im passenden Berechtigungslevel (EL1) gesetzt wird, in dem Interrupts verwaltet werden können.

Wenn du keinen speziellen Berechtigungslevel in deinem Bare-Metal-Kernel angibst und dein Raspberry Pi 4 direkt nach dem Einschalten startet, hängt der anfängliche Berechtigungslevel davon ab, in welchem Modus der Prozessor von der Firmware initialisiert wurde.

Beim Raspberry Pi ist der typische Ablauf wie folgt:

Der Bootloader (z. B. der von der GPU initialisierte Bootcode) lädt die Firmware und deinen Kernel. Nach der Initialisierung durch die Firmware (häufig start.elf), wird die CPU in EL2 (Hypervisor Mode) gestartet, wenn du keinen speziellen Wechsel zu einem bestimmten Berechtigungslevel vorgibst.

Dies ist der Default-Startmodus des Raspberry Pi 4 nach der Initialisierung durch die Firmware.

Vorgehensweise nach dem Start

Typischerweise möchtest du jedoch direkt auf EL1 (Kernel Mode) wechseln, da dies der übliche Modus ist, in dem Betriebssystem-Kernel und Bare-Metal-Kernel laufen und der Zugriff auf alle notwendigen Systemressourcen erlaubt.

Standardmäßiger Start in EL2

Hier sind die Schritte, um sicherzustellen, dass du zu EL1 wechselst, falls dies nicht schon passiert:

Beispielcode für den Wechsel von EL2 zu EL1: .global _start

_start:

   // Lese aktuelles Exception Level
   MRS x0, CurrentEL
   CMP x0, #0x8           // Check if in EL2
   B.NE el1_entry_point   // If already at EL1, jump to EL1 entry

   // Wenn im EL2, switch zu EL1
   MOV x1, #0x3C5         // Prepare function value for EL1, with interrupt masked.
   MSR SPSR_EL2, x1       // Set Status Register for entry to EL1
   ADR x1, el1_entry_point // Load address of EL1 entry point
   MSR ELR_EL2, x1        // Set exception link register for EL1 entry
   ERET                   // Switch to EL1

el1_entry_point:

   // EL1 Initialisierung
   ADR x0, vector_table   // Lade Adresse der Vektortabelle
   MSR VBAR_EL1, x0       // Set VBAR_EL1 zum Zeiger auf die Vektortabelle

   // Setze Stack Pointer für EL1
   LDR x1, =stack_top_el1
   MSR SP_EL1, x1

   // Interrupts aktivieren
   BL enable_interrupts

   // Hauptprogrammschleife

main_loop:

   B main_loop

.vector_table:

   B irq_handler          // IRQ Adresse
   // Additional vectors for different interrupts

// Dummy Interrupt Handler irq_handler:

   // Interrupt Service Routine Logik hier
   RET

// Speicherplatz für Stack .section .bss .stack_area:

   .skip 0x1000           // Reserviere Speicherplatz

stack_top_el1:

Wichtige Punkte: Initialisierungslogik in EL1: Es ist wichtig, dass du Initialisierungen für Interrupts, Vektortabellen und den Stack Pointer in EL1 korrekt durchführst. Interrupt-Freigabe: Aktivierung von Interrupts, wenn notwendig. Zusammenfassung

Wenn du keine besonderen Maßnahmen triffst, startet dein Bare-Metal-Kernel auf dem Raspberry Pi 4 standardmäßig in EL2 nach der Initialisierung durch die Firmware. Es ist gängige Praxis, dann direkt auf EL1 zu wechseln und dort den Kernel fortzusetzen. EL1 ist für die meisten bare-metal Anwendungen und Betriebsystem-Kernel der bevorzugte Modus.

Ja, Vektortabellen müssen einer bestimmten Struktur und Reihenfolge entsprechen, damit sie korrekt funktionieren. Dies ist wichtig, um sicherzustellen, dass der Prozessor bei einem Interrupt den richtigen Handler anspringt.

Struktur einer Vektortabelle

Die ARMv8-Architektur, die im Raspberry Pi 4 verwendet wird, verfügt über eine spezielle Vektortabelle für verschiedene Arten von Ausnahmen. Die Tabelle enthält Adressen für die folgenden Ausnahmen:

Synchronous Exception - Lower Level IRQ (Normal Interrupt) - Lower Level FIQ (Fast Interrupt) - Lower Level SError (System Error) - Lower Level Synchronous Exception - Current Level IRQ (Normal Interrupt) - Current Level FIQ (Fast Interrupt) - Current Level SError (System Error) - Current Level Beispiel einer Vektortabelle

Hier ist ein Beispiel, wie eine Vektortabelle für EL1 aussehen könnte:

.align 11 .section .vectors, "a" vector_table:

   // Vektoren für EL1 (Current Level)
   b sync_exception_el1     // Synchronous Exception
   b irq_handler_el1        // IRQ - Normal Interrupt
   b fiq_handler_el1        // FIQ - Fast Interrupt
   b serror_handler_el1     // SError - System Error

   // Vektoren für EL0 (Lower Level)
   b sync_exception_el0     // Synchronous Exception
   b irq_handler_el0        // IRQ - Normal Interrupt
   b fiq_handler_el0        // FIQ - Fast Interrupt
   b serror_handler_el0     // SError - System Error

Konfiguration der Vektortabelle

Die Vektortabelle muss dem Prozessor mitgeteilt werden, indem die Basisadresse der Tabelle in das VBAR_ELx-Register geschrieben wird:

.global _start

_start:

   // Setze Stack-Pointer für EL1
   LDR x1, =stack_top_el1
   MSR SP_EL1, x1

   // Lade Adresse der Vektortabelle
   ADR x0, vector_table
   MSR VBAR_EL1, x0          // Setze VBAR_EL1 auf die Adresse der Vektortabelle

   // Initialisiere Interrupts
   BL enable_interrupts

   // Hauptprogrammschleife

main_loop:

   B main_loop

// Dummy-Handler sync_exception_el1:

   // Handler-Code für synchrone Ausnahmen in EL1
   RET

irq_handler_el1:

   // Handler-Code für IRQ-Interrupts in EL1
   RET

fiq_handler_el1:

   // Handler-Code für FIQ-Interrupts in EL1
   RET

serror_handler_el1:

   // Handler-Code für Systemfehler in EL1
   RET

sync_exception_el0:

   // Handler-Code für synchrone Ausnahmen in EL0/EL1
   RET

irq_handler_el0:

   // Handler-Code für IRQ-Interrupts in EL0
   RET

fiq_handler_el0:

   // Handler-Code für FIQ-Interrupts in EL0
   RET

serror_handler_el0:

   // Handler-Code für Systemfehler in EL0
   RET

.section .bss .stack_area:

   .skip 0x1000               // Speicherplatz reservieren

stack_top_el1:

Wichtige Punkte zur Vektortabelle Ausrichtung: Die Vektortabelle muss auf eine bestimmte Weise ausgerichtet sein, typischerweise 2^11 Byte (2048 Byte, align 11), um den Anforderungen des ARM-Prozessors zu entsprechen. Reihenfolge: Die Reihenfolge der Einträge ist fix und muss den Spezifikationen entsprechend sein. Jeder Vektor muss die korrekte Entsprechung der Ausnahme-Adressen haben. Handlers: Jeder Eintrag in der Vektortabelle verweist auf einen spezifischen Handler für jede Art von Ausnahme. Zusammenfassung

Eine korrekt strukturierte Vektortabelle ist essentiell für die korrekte Handhabung von Interrupts und Ausnahmen. Stelle sicher, dass alle Einträge in der richtigen Reihenfolge vorliegen und dass die Ausrichtung der Tabelle korrekt ist. Setze die Basisadresse der Tabelle im entsprechenden VBAR-Register und implementiere die entsprechenden Handler für jede Ausnahmeart.

Um zu verhindern, dass während der Bearbeitung einer Ausnahme (Interrupt Handling) eine weitere Ausnahme auftritt und zu unerwünschten Zuständen führt, gibt es mehrere Mechanismen, die verwendet werden können. Diese Mechanismen beinhalten das Maskieren von Interrupts, das Setzen von Flags und das Sicherstellen einer richtigen Reihenfolge und Priorität von Ausnahmebehandlungen.

Mechanismen zur Verhinderung von Ausnahmen während der Ausnahmebehandlung

Maskieren von Interrupts:

Beim Eintritt in einen Ausnahme-Handler kannst du alle weiteren Interrupts maskieren. Dies bedeutet, dass andere Interrupts so lange blockiert werden, bis der aktuelle Handler vollständig abgeschlossen ist. Die ARM-Architektur stellt dafür spezielle Register (DAIF, CPSR) zur Verfügung, mit denen Interrupts individuell oder global maskiert werden können.

DAIF-Register:

Das DAIF-Register enthält Flags, um Debug-, SError-, IRQ- und FIQ-Interrupts zu maskieren. Um alle Interrupts zu maskieren, wird das DAIF-Register mit den entsprechenden Bits gesetzt. Beispielcode für das Maskieren von Interrupts in einem Ausnahme-Handler .global exception_handler

exception_handler:

   // Maskiere alle Interrupts
   MRS x0, DAIF       // Lese DAIF Register
   ORR x0, x0, #0x3C0 // Setze die Bits zum Maskieren: D, A, I, F
   MSR DAIF, x0       // Schreibe zurück zum DAIF Register

   // Ausgangszustände retten
   PUSH {x0-x30, lr}

   // Handler Code hier

   // Ausgangszustände wiederherstellen
   POP {x0-x30, lr}

   // Entmaske alle Interrupts
   MRS x0, DAIF       // Lese DAIF Register
   BIC x0, x0, #0x3C0 // Lösche die Bits zum Entmaskieren: D, A, I, F
   MSR DAIF, x0       // Schreibe zurück zum DAIF Register

   RET

Schritt-für-Schritt Erklärung

Maskieren von Interrupts:

MRS x0, DAIF liest den aktuellen Zustand des DAIF-Registers und speichert ihn in x0. ORR x0, x0, #0x3C0 setzt die Bits 8 (D), 9 (A), 6 (I), und 7 (F) auf 1, um Debug, SError, IRQ und FIQ Interrupts zu maskieren. MSR DAIF, x0 schreibt den modifizierten Wert zurück in das DAIF-Register und maskiert somit alle diese Interrupts.

Ausführung des Handlers:

Speicherungen der Registersätze (x0-x30, lr), um das Rückkehren nach der Ausnahme sicherzustellen. Ausführen der eigentlichen Ausnahmebehandlung.

Wiederherstellen Ausgangszustände und Entmaske Interrupts:

POP {x0-x30, lr} stellt die gespeicherten Register wieder her. MRS x0, DAIF liest den aktuellen Zustand des DAIF-Registers. BIC x0, x0, #0x3C0 löscht die Bits 8 (D), 9 (A), 6 (I), und 7 (F), um die Interruptmaskierung aufzuheben. MSR DAIF, x0 schreibt den modifizierten Wert zurück in das DAIF-Register, um die Interrupts wieder zu erlauben. Priority und Reihenfolge von Ausnahmen

Zusätzlich zum Maskieren von Interrupts können auch Priorisieren und die richtige Verwaltung der Reihenfolge helfen:

Priorisieren von Interrupts: Bestimmte Interrupts können kritisch und hoch-priorisierter sein, während andere niederpriorisiert behandelt werden. Der interrupt controller kann verwendet werden, um Prioritäten der Interrupts zu verwalten. Zusammenfassung

Interrupt-Maskierung und richtige Priorisierung sind die Schlüssel, um zu verhindern, dass während des Ausnahme-Handlings weitere Ausnahmen auftreten. Das Maskieren der Interrupts kann über das DAIF-Register erfolgen und sollte vor Austritt aus dem Ausnahme-Handler aufgehoben werden. Diese Mechanismen stellen sicher, dass die Ausnahmebehandlung ohne Störungen abgeschlossen werden kann.

Ja, es gibt Unterschiede im Aufbau der Vektortabellen, insbesondere wenn verschiedene Betriebsmodi und Ausnahmelevel berücksichtigt werden. In der ARMv8-Architektur werden normalerweise 16 Einträge verwendet, um den verschiedenen Ausnahmebedingungen innerhalb der verschiedenen Exception Levels gerecht zu werden. Dies bezieht sich sowohl auf 64-Bit- als auch auf 32-Bit-Modi und auf die verschiedenen Zustände eines Exception Levels.

Erklärung der 16 Einträge

Die ARMv8-Architektur teilt die Exception Level Vektortabelle in vier verschiedene Ausnahmearten und zwei verschiedene Zustände jeder Ausnahmeart (z. B. EL1t und EL1h), und dies sowohl für 64-Bit- als auch für 32-Bit-Modi. Hier ist die detaillierte Aufschlüsselung:

Ausnahmearten und Zustände: Synchronous: Sorgt für synchrone Ausnahmen, z.B. Software-Fehler. IRQ: Normaler Interrupt Request. FIQ: Schneller Interrupt Request. SError: System Error.

Diese Ausnahmen haben jeweils einen Zustand für:

Current Exception Level with SP_el0 (_el1t) Wenn der Stack Pointer SP_el0 verwendet wird. Current Exception Level with SP_elx (_el1h) Wenn der Stack Pointer von SP_elx verwendet wird (z.B. SP_el1).

Zusätzlich dazu müssen die Einträge sowohl für 64-Bit als auch 32-Bit-Untermodi der Ausnahmebehandlung berücksichtigt werden. Dies kommt typischerweise bei der Arbeit in der 64-Bit-Arbeitsumgebung vor. Im Allgemeinen:

64-Bit Mode EL0 (_el0_64) 32-Bit Mode EL0 (_el0_32) Beispiel einer vollständigen 16-Eintrag-Vektortabelle: .align 11 .section .vectors, "a"

vector_table:

// Einträge für EL1t (Current Exception Level SP_el0) ventry sync_invalid_el1t // Synchronous EL1t ventry irq_invalid_el1t // IRQ EL1t ventry fiq_invalid_el1t // FIQ EL1t ventry error_invalid_el1t // Error EL1t

// Einträge für EL1h (Current Exception Level SP_el1) ventry sync_invalid_el1h // Synchronous EL1h ventry handle_el1_irq // IRQ EL1h ventry fiq_invalid_el1h // FIQ EL1h ventry error_invalid_el1h // Error EL1h

// Einträge für EL0 64-bit Modus ventry sync_invalid_el0_64 // Synchronous EL0 (64-bit) ventry irq_invalid_el0_64 // IRQ EL0 (64-bit) ventry fiq_invalid_el0_64 // FIQ EL0 (64-bit) ventry error_invalid_el0_64 // Error EL0 (64-bit)

// Einträge für EL0 32-bit Modus ventry sync_invalid_el0_32 // Synchronous EL0 (32-bit) ventry irq_invalid_el0_32 // IRQ EL0 (32-bit) ventry fiq_invalid_el0_32 // FIQ EL0 (32-bit) ventry error_invalid_el0_32 // Error EL0 (32-bit)

.macro ventry label b \label .endm

Erläuterungen zu den Einträgen: sync_invalid_*: Diese Handler werden für synchrone Ausnahmen verwendet, wie z.B. system calls oder undefinierte Instruktionen. irq_invalid_*: Diese Handler werden für normale Interrupt-Anfragen verwendet. fiq_invalid_*: Diese Handler werden für schnelle Interrupt-Anfragen verwendet. error_invalid_*: Diese Handler werden für Systemfehler verwendet. Verwendung und Initialisierung der Vektortabelle:

Die Registerzüge VBAR_EL1, VBAR_EL2 und VBAR_EL3 müssen entsprechend initialisiert werden, um die Adresse dieser Vektortabellenstruktur zu verwenden. Hier ist ein Beispiel für die Initialisierung auf EL1:

.global _start

_start:

   // Initialisiere Stack Pointer für EL1
   LDR x1, =stack_top_el1
   MSR SP_EL1, x1

   // Lade die Adresse der Vektortabelle
   ADR x0, vector_table
   MSR VBAR_EL1, x0          // Setze VBAR_EL1 zur Adresse der Vektortabelle

   // Initialise Interrupts
   BL enable_interrupts

   // Hauptprogrammschleife

main_loop:

   B main_loop

sync_invalid_el1t:

   // Handler für synchronous exception in EL1t
   RET

irq_invalid_el1t:

   // Handler für IRQ in EL1t
   RET

fiq_invalid_el1t:

   // Handler für FIQ in EL1t
   RET

error_invalid_el1t:

   // Handler für System Error in EL1t
   RET

sync_invalid_el1h:

   // Handler für synchronous exception in EL1h
   RET

handle_el1_irq:

   // Hauptinterrupt Handler für IRQ in EL1h
   RET

fiq_invalid_el1h:

   // Handler für FIQ in EL1h
   RET

error_invalid_el1h:

   // Handler für System Error in EL1h
   RET

sync_invalid_el0_64:

   // Handler für synchronous exception in 64-bit EL0
   RET

irq_invalid_el0_64:

   // Handler für IRQ in 64-bit EL0
   RET

fiq_invalid_el0_64:

   // Handler für FIQ in 64-bit EL0
   RET

error_invalid_el0_64:

   // Handler für System Error in 64-bit EL0
   RET

sync_invalid_el0_32:

   // Handler für synchronous exception in 32-bit EL0
   RET

irq_invalid_el0_32:

   // Handler für IRQ in 32-bit EL0
   RET

fiq_invalid_el0_32:

   // Handler für FIQ in 32-bit EL0
   RET

error_invalid_el0_32:

   // Handler für System Error in 32-bit EL0
   RET

.section .bss .stack_area:

   .skip 0x1000               // Speicherplatz reservieren

stack_top_el1:

Zusammenfassung

In der ARMv8-Architektur gibt es eine erweiterte Struktur für Vektortabellen mit 16 Einträgen, um verschiedene Arten und Zustände von Ausnahmen vollständig zu unterstützen. Bei der Ausnahmebehandlung können unterschiedliche Modi (64-Bit und 32-Bit) und verschiedene Betriebsarten (_el1t, _el1h, _el0_64, _el0_32) gleichzeitig berücksichtigt werden. Eine korrekte Initialisierung und Einhaltung der Reihenfolge dieser Einträge ist für die zuverlässige Ausnahmebehandlung unerlässlich.