ARMv8-A Architecture: AArch64 and Exception Levels

From Modes to Levels: A New Privilege Model

Your experience with embedded systems likely includes familiarity with the classic ARM processor modes used in ARMv7 and earlier architectures (e.g., User, Supervisor, IRQ, FIQ). These modes provided different levels of privilege and access to system resources.

ARMv8-A replaces this model with a cleaner, more structured system of four Exception Levels (ELs). This hierarchical model is a cornerstone of the new architecture, providing a robust framework for virtualization, security, and managing complex software stacks.

The two most significant changes in ARMv8-A are:

1. Introduction of a 64-bit execution state (AArch64).
2. A new exception model based on Exception Levels EL0, EL1, EL2, and EL3.

Let's dive into what these levels are and why they are so important.

The Big Picture: Exception Levels and Security States

To get a comprehensive overview, we'll watch a video that explains the motivation behind the ARMv8-A architecture and provides an excellent breakdown of the exception levels and their real-world applications.

Now, let's consolidate what you've just seen.

AArch64 and AArch32 Execution States

As the video mentioned, a primary feature of ARMv8-A is its 64-bit capability. This is enabled by the AArch64 execution state.

• AArch64: The new 64-bit state. It features a streamlined instruction set (A64), access to 31 general-purpose 64-bit registers (X0-X30), and fully utilizes the new exception model.
• AArch32: This state provides backward compatibility, allowing the processor to run legacy 32-bit code from the ARMv7-A era without modification. It uses the older A32 and T32 (Thumb) instruction sets and register model.

This dual-state capability was crucial for a smooth industry transition to 64-bit computing. For new driver development on modern automotive platforms, you will almost exclusively work within the AArch64 state.

The Four Exception Levels

The hierarchy of privilege in ARMv8-A is strict: the higher the number, the greater the privilege. Code running at a certain level, ELn, can generally only access resources at its own level or lower.

• EL0: User Applications

  • This is the lowest privilege level.
  • It's where all your user-space applications run (e.g., the media player in an infotainment system, a command-line utility in Linux).
  • Access to system hardware and critical configuration registers is restricted. To perform a privileged action, an application must request it from the operating system via a system call, which causes an exception and a controlled transition to EL1.

• EL1: The Operating System Kernel

  • This level is designed for the OS kernel (e.g., Linux, QNX, AUTOSAR OS).
  • The kernel manages the system's resources, schedules processes running at EL0, and controls the hardware on their behalf.
  • In your AUTOSAR experience, the OS and the core parts of the BSW would conceptually reside here, managing the application layer.

• EL2: The Hypervisor (Virtualization)

  • This level enables hardware virtualization. A hypervisor running at EL2 can manage and switch between multiple "guest" operating systems, each running in its own sandboxed environment at EL1.
  • This is incredibly important in modern automotive architecture. For example, a single powerful SoC can run a safety-critical RTOS (like QNX) for the instrument cluster and a rich infotainment OS (like Android Automotive) simultaneously, with the hypervisor ensuring they are strictly isolated from one another. Your work with gateways and software-defined vehicle platforms directly relates to this trend of consolidating functions onto powerful, virtualized processors.

• EL3: The Secure Monitor (The Root of Trust)

  • This is the most privileged level in the processor and is the foundation of the system's security.
  • Code running at EL3, typically called the Secure Monitor, acts as the gatekeeper between the Normal World (where EL0, EL1, and EL2 typically operate) and the Secure World.
  • The Secure Monitor is responsible for booting the system securely, managing cryptographic keys, and handling transitions between the two worlds. This connects directly to concepts like secure boot, Hardware Security Modules (HSMs), and functional safety (ISO 26262), as EL3 provides the ultimate hardware-enforced protection for the most critical software.

The diagram below provides a useful comparison, mapping the old ARMv7 modes to the new AArch64 exception levels.

Putting It All Together: A Quick Review

Let's watch one more short clip to reinforce these core concepts from a slightly different perspective, focusing on how a programmer interacts with these features.

Interview Corner

Understanding this architectural shift is critical for any role involving ARMv8. Here are some questions you can expect, drawn from resources like "Top 25 ARM64 Interview Questions".

Q1: What are the main architectural differences between ARMv7 and ARMv8?
A: The main difference is that ARMv8 introduces a 64-bit architecture. This comes with two key changes: a new 64-bit execution state called AArch64, which features a larger register file (31 general-purpose registers) and a modern instruction set. Secondly, it replaces the old processor modes with a hierarchical four-level exception model (EL0 to EL3), which provides a much more structured foundation for security and virtualization. While introducing AArch64, it maintains backward compatibility with ARMv7 through the AArch32 execution state.

Q2: Can you explain the purpose of the exception levels in ARMv8-A? Give an example of software that runs at each level.
A: The exception levels define a hierarchy of privilege.

• EL0 is the least privileged and is for user applications, like a navigation app.
• EL1 is for the operating system kernel, like QNX or Linux, which manages applications and hardware.
• EL2 is for the hypervisor, which allows multiple operating systems to run on the same CPU, isolated from each other. For example, running a real-time OS for the instrument cluster and Android for infotainment on one chip.
• EL3 is the most privileged level for the Secure Monitor, which manages the switch between the Normal World and the Secure World (TrustZone) and handles secure boot and firmware.

Q3: What is the relationship between Exception Levels and ARM TrustZone security?
A: ARM TrustZone technology partitions the processor into two 'worlds': a Normal World for general-purpose processing and a Secure World for security-sensitive operations. The exception levels exist in both worlds. However, EL3, the Secure Monitor, exists only in the Secure World and acts as the gatekeeper between the two. When the Normal World OS needs a secure service (like validating a signature), it executes a special instruction (SMC) that traps to the Secure Monitor at EL3. The monitor then saves the Normal World state and passes control to a trusted OS or application running in the Secure World at Secure EL1 or EL0. This provides hardware isolation for critical assets.

Conclusion

You have now covered the fundamental architectural principles of ARMv8-A. Moving from ARMv7's flat mode-based system to ARMv8-A's hierarchical, multi-world exception model is a major conceptual step, but it's one that enables the complex, secure, and virtualized systems that are defining the future of automotive electronics.

Key Takeaways:

• ARMv8-A introduces the AArch64 64-bit execution state while retaining AArch32 for backward compatibility.
• The old processor modes are replaced by four hierarchical Exception Levels: EL0 (User), EL1 (OS), EL2 (Hypervisor), and EL3 (Secure Monitor).
• Privilege increases from EL0 to EL3.
• The architecture is split into a Normal World and a Secure World (TrustZone), with EL3 managing the transitions.
• This model is the foundation for modern virtualization and security in embedded systems.

Next Lesson Preview:
Now that we understand the structure of the ARMv8-A architecture, our next step is to look at how software actually executes on it. In the next lesson, we will analyze AArch64 assembly code to explain the procedure call standard for passing parameters and returning values. This will bridge the gap between high-level architectural concepts and low-level implementation.