Differences

This shows you the differences between two versions of the page.

--- en:multiasm:paarm:chapter_5_3 [2025/12/03 00:45] – [CPU Configuration] eriks.klavins
+++ en:multiasm:paarm:chapter_5_3 [2025/12/11 08:14] (current) – [CPU Configuration] eriks.klavins
@@ Line 46: / Line 46: @@
 The Raspberry Pi 5 has an ARM Cortex-A76 processor with 4 CPU cores. Each core has its own stack pointers, status registers and other registers. Before looking at CPU registers, some specifics must be explained. The single core has several execution levels: EL0, EL1, EL2, and EL3. These execution levels in datasheets are called Exception Levels – the level at which the processor resources are managed. EL0 is the lowest level; all user applications are executed at this level. EL1 is meant for operating systems; EL2 is intended for a Hypervisor application to control resources for the OS and the lower exception layers. The CPU's general-purpose registers are independent of Exception levels, but it is essential to understand which Exception Level executes the code. This is called “System configuration” because the processor has multiple cores, and each core has multiple exception levels. To configure the system and access the system registers, the MRS and MSR instructions must be used. Note that the registers that have the suffix “_ELn” have a separate, banked copy in some or all of the levels, except for EL0. This suffix also defines the lowest exception level, which can access the particular system register. Only a few system registers are accessible from EL0, though the Cache Type Register (CTR_EL0) is one of them.
-''<fc #800000>MRS</fc> <fc #008000>X0</fc>, CTR_EL0 <fc #6495ed><fc #87ceeb>@ Move CTR_EL0 into X0 – now the X0 register can be modified</fc></fc>''
+''<fc #800000>MRS</fc> <fc #008000>X0</fc>, CTR_EL0 <fc #6495ed>@ Move CTR_EL0 into X0 – now the X0 register can be modified</fc>''
 ''<fc #800000>MSR</fc> CTR_EL0, <fc #008000>X0</fc> <fc #6495ed>@ Move X0 into CTR_EL0 – write back the modifications</fc>''
-{{ :en:multiasm:paarm:exceptionlevels.svg |}}
+{{:en:multiasm:paarm:exceptionlevels_new.jpg?600|}}
+In the image, all of the exception levels are visualised. The Orange area is so-called the untrusted or non-secure state. The region with a blue background is the Operating System and its parts and applications. User applications can request resources using SVC (supervisor calls), or on Raspberry Pi OS (and others), this is called SysCalls. The operating system is treated as a separate program on the exception level EL1 from the EL2 perspective. If the hypervisor is available, the OS may request resources via HVC (Hypervisor calls), and the hypervisor can request resources from the secure monitor via SMC (Secure monitor calls). On Raspberry Pi 5, the bootloader runs on EL3, loading memory and initialising the hardware. Then the operating system is started at the EL1 level, and the rest of the applications in the OS are at the EL0 level. Raspberry Pi 5 does not have hypervisor software, which is why Exception Level 2 is not used.
+The Green region is a Secure State where only special secure applications and operating systems are executed. This may be used in system duplication, where two identical systems must run, with the second used for integrity checks, fault and error detection in the central system that runs in a non-secure state. Note that both secure and non-secure states are isolated, and the resources can be shared only through the EL3 level.
 We will look only at AArch64 registers to narrow the number of registers.
-There are many registers dedicated to the CPU. Specialised registers will be left aside again to narrow the amount of information, and only those registers meant for program execution will be reviewed. As there is more than one core, each core must have a dedicated status register. All registers that store some status on AArch64 CPU cores are collected in the table below. Don’t get confused by many of these listed status registers. The registers with a green background are relevant to the programming because only those registers store the actual status of instruction execution.
+There are many registers dedicated to the CPU. Specialised registers will be left aside again to narrow the amount of information, and only those registers meant for program execution will be reviewed. As there is more than one core, each core must have a dedicated status register. All registers that store some status on AArch64 CPU cores are collected in the table below. Don’t get confused by many of these listed status registers. The registers whose names are in bold are relevant to the programming because only those registers store the actual status of instruction execution.
 <table tab_label>

en/multiasm/paarm/chapter_5_3.1764722703.txt.gz · Last modified: 2025/12/03 00:45 by eriks.klavins