Differences

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

--- en:multiasm:paarm:chapter_5_3 [2025/12/02 22:54] – [CPU registers] eriks.klavins
+++ en:multiasm:paarm:chapter_5_3 [2025/12/11 08:14] (current) – [CPU Configuration] eriks.klavins
@@ Line 44: / Line 44: @@
 ===== CPU Configuration=====
-For Raspberry PI 5, the ARM Cortex-A76 processor has four 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 core has several execution levels named 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 level is meant for operating systems, EL3 is intended for a Hypervisor application to control the resources for OS and the lower levels of 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.
+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.
-IMAGE IMAGE
+''<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_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 a lot of 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 instruction execution status.
+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>
+<caption>some of statsu registers for ARMv8 processor</caption>
+^ Register      ^ description                                                               ^
+| AFSR0_EL1..3 and AFSR1_EL1..2  | Auxiliary Fault Status Register 0/1 (EL1..EL3) provides additional fault information for exceptions taken to EL1, EL2 or EL3.  |
+| DBGAUTHSTATUS_EL1   | The Debug Authentication Status Register provides information about the debug authentication interface's state. |
+| DISR_EL1 | The Deferred Interrupt Status Register stores the records that an ESB (Error synchronisation barrier) instruction has consumed an SError (System Error) exception. |
+| DSPSR_EL0 | The Debug Saved Program Status Register holds the saved process state for the Debug state. When entering the Debug state, PSTATE information is written in this register. Values are copied from this register to PSTATE on exiting the Debug state.|
+| ERXGSR_EL1 | The Selected Error Record Group Status Register shows the status for the records in a group of error records. Accesses ERRGSR for the group of error records <n> selected by ERRSELR_EL1.SEL[15:6]. |
+| ERXSTATUS_EL1 | Selected Error Record Primary Status Register Accesses ERR<n>STATUS for the error record <n> selected by ERRSELR_EL1.SEL |
+| **FPSR** | The Floating-point Status Register provides floating-point system status information. |
+| ICH_EISR_EL2 | Interrupt Controller End of Interrupt Status Register indicates which List registers have outstanding EOI (End Of Interrupt) maintenance interrupts. |
+| ICH_ELRSR_EL2 | Interrupt Controller Empty List Register Status Register. These registers can locate a usable List register when the hypervisor delivers an interrupt to a VM (Virtual Machine). |
+| IFSR32_EL2 | The Instruction Fault Status Register (EL2) allows access to the AArch32 IFSR register only from AArch64 state. Its value does not affect execution in AArch64 state. |
+| ISR_EL1 | Interrupt Status Register shows the pending status of IRQ and FIQ interrupts and SError exceptions. |
+| MDCCSR_EL0 | Monitor DCC Status Register is a read-only register containing control status flags for the DCC (Debug Communications Channel) |
+| OSLSR_EL1 | OS Lock Status Register provides the status of the OS Lock. |
+| **SPSR_EL1..3** | The Saved Program Status Register (EL1..EL3) holds the saved process state when an exception is taken to EL1, EL2, or EL3. |
+| **SPSR_abt** | Saved Program Status Register (Abort mode) holds the saved process state when an exception is taken to Abort mode. |
+| **SPSR_fiq** | The Saved Program Status Register (FIQ mode) holds the saved process state when an exception is taken into FIQ mode. |
+| **SPSR_irq** | Saved Program Status Register (IRQ mode) holds the saved process state when an exception is taken to IRQ mode. |
+| **SPSR_und** | Saved Program Status Register (Undefined mode) holds the saved process state when an exception is taken to Undefined mode. |
+| TFSRE0_EL1 | The Tag Fault Status Register (EL0) holds accumulated Tag Check Faults occurring in EL0 that are not taken precisely. |
+| TFSR_EL1..3 | Tag Fault Status Register (EL1..EL3) holds accumulated Tag Check Faults occurring in EL1, EL2 or EL3 that are not taken precisely |
+| TRCAUTHSTATUS | The Trace Authentication Status Register provides information about the authentication interface's state for debugging. The CoreSight Architecture Specification offers more information. |
+| TRCOSLSR | Trace OS Lock Status Register returns the status of the Trace OS Lock |
+| TRCRSR | The Trace Resources Status Register is used to set or read the status of the resources. |
+| TRCSSCSR<n> | Trace Single-shot Comparator Control Status Register <n> returns the status of the corresponding Single-shot Comparator Control. |
+| TRCSTATR | Trace Status Register returns the trace unit status. |
+| VDISR_EL2..3 | Virtual Deferred Interrupt Status Register (EL2..EL3) Records that a SError exception has been consumed by an ESB instruction executed at EL1 or EL2. |
+</table>
+You can see how many states this processor has. Not all of them are used during program execution. Many registers are related to debugging and resource management. On the Raspberry Pi, the OS and bootloader have already configured all CPU Cores and the registers. Trace registers are used only when hardware debugging is enabled, such as JTAG or TRACE32.
+Summarising: in Cortex-A76, ARMV8.2-A, installed on Raspberry Pi 5, on EL1, the system OS (kernel) is running. Since the OS is booted from the SD card, there is no Hypervisor software, which means EL2 is not used, and the Linux OS is the only one running on the Raspberry Pi 5 board. All users’ software runs in EL0. However, any code executed by the OS kernel runs at EL1, and it can be designed and executed as a kernel module.
+There are rules for creating a Linux OS kernel module – it must contain functions that initialise the module and exit when the job is finished. The skeleton for the kernel module is given below in C. It will require a GCC compiler to compile the code, but inline assembly can be written directly in the code itself. After changing the Exception level from EL0 to EL1, only some system instruction executions will be allowed.
+<codeblock code_label>
+<caption>Linux kernel module example</caption>
+<code>
+// mymod.c
+#include <linux/module.h>
+#include <linux/kernel.h>
-TABLE
+static int __init mymod_init(void)
+{
+    asm volatile(
+        "mrs x0, CurrentEL\n"
+        "lsr x0, x0, #2\n"  // EL >> 2
+        // x0 now contains current EL (expect 1)
+    );
+    pr_info("mymod: running in EL1\n");
+    return 0;
+}
+static void __exit mymod_exit(void)
+{
+    pr_info("mymod: exit\n");
+}
+module_init(mymod_init);
+module_exit(mymod_exit);
+MODULE_LICENSE("GPL");
+</code>
+</codeblock>
+There are restrictions on the use of privileged instructions in the code. In EL0, privileged instruction execution will trap into the kernel. Note that switching between EL0 and EL1 is allowed only in the kernel and firmware. The firmware code will require access to the whole chip documentation, and at the moment, this documentation is confidential. So, the only option left is to design a kernel module and use the available EL1 resources.

en/multiasm/paarm/chapter_5_3.1764716094.txt.gz · Last modified: 2025/12/02 22:54 by eriks.klavins