aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorvetch <vetch97@gmail.com>2020-01-18 14:49:58 +0100
committervetch <vetch97@gmail.com>2020-01-18 14:49:58 +0100
commit795954eec24dbc77380e3136050c8f40c813491b (patch)
tree9845b03b643bcd9397444256da5121d76be51a70
parent76165edf385b607b3b9d36d273a4fcc4d969f897 (diff)
downloadrpi-MMU-example-795954eec24dbc77380e3136050c8f40c813491b.tar.gz
rpi-MMU-example-795954eec24dbc77380e3136050c8f40c813491b.zip
Exceptions added, linking linking
-rw-r--r--Exception-vector-explained.txt30
1 files changed, 17 insertions, 13 deletions
diff --git a/Exception-vector-explained.txt b/Exception-vector-explained.txt
index eb382a2..b82eadb 100644
--- a/Exception-vector-explained.txt
+++ b/Exception-vector-explained.txt
@@ -1,11 +1,14 @@
+## Exceptions
Whenever some illegal operation (attempt to execute undefined instruction, attempt to access memory with insufficient permission, etc.) happens or some peripheral device "messages" the ARM core, that something important happened, an exception occurs. Exception is something, that pauses normal execution and passes control to the (specific part of) operating system.
Upon an exception, several things happen:
-1. Processor mode <link to processor-modes-explained.txt> changes.
-2. CPSR gets saved into new mode's SPSR <link to PSRs-explained>.
+
+1. Change of [Processor mode](./processor-modes-explained.txt).
+2. CPSR gets saved into new mode's [SPSR](./PSRs-explained.txt).
3. pc (incremented by some value) is saved into new mode's lr.
4. Execution jumps to an entry in the exception vectors table specific to the exception.
Each exception type is taken to it's specific mode. Types and their modes are:
+
1. Reset and supervisor mode.
2. Undefined instruction and undefined mode.
3. Supervisor call and supervisor mode.
@@ -15,15 +18,16 @@ Each exception type is taken to it's specific mode. Types and their modes are:
7. IRQ and IRQ mode.
8. FIQ and FIQ mode.
-The new value of the pc (the address, to which the exception "jumps") is the address of nth instruction from exceptiom base address, which, undes simplest settings, is 0x0 (bottom of virtual address space <link to MMU-explained.txt>). N depends on the exception type. It is:
-· 1 for reset
-· 2 for undefined instruction
-· 3 for supervisor call
-· 4 for prefetch abort
-· 5 for data abort
-· 6 for hypervisor trap (not used here)
-· 7 for IRQ
-· 8 for FIQ
+The new value of the pc (the address, to which the exception "jumps") is the address of nth instruction from exceptiom base address, which, under simplest settings, is 0x0 (bottom of [virtual address space](./MMU-explained.txt)). N depends on the exception type. It is:
+
+1. reset
+2. undefined instruction
+3. supervisor call
+4. prefetch abort
+5. data abort
+6. hypervisor trap (not used here)
+7. IRQ
+8. FIQ
Those 8 instructions constitute the exception vectors table. As the instruction follow one another, each of them should be a branch to some exception-handling routine. In fact, on other architectures often the exception vector table holds raw addresses of where to jump instead of actual instructions, as here.
@@ -33,6 +37,6 @@ On exception entry, the registers r0-r12 contain values used by the code that wa
Having old CPSR in SPSR and old pc in lr is helpful, when after handling the exception, the handler needs to return to the code that was executing before. There are 2 special instructions, subs and ldm ^ (load multiple with a dash ^), that, when used to change the pc (and therefore perform a jump) cause the SPSR to be copied into CPSR. As bits of CPSR determine the current execution mode, this causes the mode to be change to that from before the exception. In short, subs and ldm ^ are the instructions to use to return from exceptions.
-As noted eariler, upon exception entry an incremented value of pc is stored in lr. By how much it is incremented, depends on exception type and execution state. For example, entering undefined instruction exception for thumb state places in undef's lr the problematic instruction's address + 2, while taking this exception from ARM state places in undef's lr that instruction's address + 4 (see full table in paragraph B1.8.3 of armv7-ar_arm <link here>).
+As noted eariler, upon exception entry an incremented value of pc is stored in lr. By how much it is incremented, depends on exception type and execution state. For example, entering undefined instruction exception for thumb state places in undef's lr the problematic instruction's address + 2, while taking this exception from ARM state places in undef's lr that instruction's address + 4 (see full table in paragraph B1.8.3 of [armv7-ar_arm](https://static.docs.arm.com/ddi0406/c/DDI0406C_C_arm_architecture_reference_manual.pdf)).
-It's worth noting, that while our implementation of exception handlers (<path to assembly source>) also sets the stack pointer (sp) upon each exception entry, a kernel could be written, where this wouldn't be done, as each mode enterable by exception has it's own sp.
+It's worth noting, that while our [implementation of exception handlers](src/arm/PL1/kernel/interrupt_vector.S) also sets the stack pointer (sp) upon each exception entry, a kernel could be written, where this wouldn't be done, as each mode enterable by exception has it's own sp.