Understanding ARM Exceptions

.globl _start                    ；System reset position
_start: b       reset            ；Jump code corresponding to each exception vector
       ldr     pc, _undefined_instruction ；Undefined instruction exception
       ldr     pc, _software_interrupt     ；Software interrupt exception
       ldr     pc, _prefetch_abort          ；Memory operation exception
       ldr     pc, _data_abort               ；Data exception
       ldr     pc, _not_used                  ；Not used
       ldr     pc, _irq                       ；Slow interrupt exception
       ldr     pc, _fiq                       ；Fast interrupt exception

From this we can see that ARM supports 7 exceptions. The question is how does ARM respond after an exception occurs? The first reset exception is good.

Understand, it is placed at 0x0, it is executed as soon as the power is turned on, and our program always starts from the reset exception handler, so

This reset exception handler does not need to return. So how did it execute to the following exception handlers?
After reading the book, I understood the ARM response process to exceptions, so I was able to answer this question.
When an exception occurs, ARM will automatically perform the following steps:
(1) Put the address of the next instruction into the link register LR (usually R14), so that it can return from the correct position when handling the exception.

Continue execution.
(2) Copy the corresponding CPSR (Current Program Status Register) to the SPSR (Backup Program Status Register).

(3) According to the exception type, the operating mode bit of CPSR is forced to be set. (
4) The PC (program counter) is forced to fetch the next instruction from the relevant exception vector address and execute it, thereby jumping to the corresponding exception handling procedure .

As
for what these exception types represent, I didn't go into it. Because I usually care about reset, there is no need to figure it out.
ARM specifies the address of the exception vector:
  b       reset            ; reset 0x0
ldr pc, _undefined_instruction; undefined instruction exception 0x4
      ldr     pc, _software_interrupt     ; software interrupt exception    0x8
      ldr     pc, _prefetch_abort          ; prefetch instruction    0xc
      ldr     pc, _data_abort               ; data        0x10
      ldr     pc, _not_used                  ; not used      0x14
      ldr     pc, _irq                       ; slow interrupt exception   0x18
       ldr   pc, _fiq                       ; fast interrupt exception    0x1c
It is very simple to understand this code. When an exception occurs, the PC will be forced to be set to the corresponding exception vector, thereby jumping to the corresponding

The interrupt vectors of these boot
programs are only used by the boot program itself. Once the boot program has finished booting the Linux kernel, it will use

Own interrupt vector.
Oh, this is a problem. For example, when an ARM interrupt (irq) occurs, it will always run to 0x18 for execution. How about the Linux kernel?

How can you use your own interrupt vector? The reason is that the Linux kernel uses paged memory management. After the MMU page mapping is enabled, the CPU

The address sent is a virtual address rather than a physical address. As far as the Linux kernel is concerned, the physical address after the virtual address 0x18 is mapped is

That is 0xc000 0018. So Linux just puts the interrupt vector at 0xc000 0018.
The two main functions of MMU are:
(1) Security: specify access rights
(2) Provide address space: convert discontinuous space into continuous space.
Does the second point mean to implement paged storage?

.globl _start ; System reset position
_start: b reset ; Jump code corresponding to each exception vector
ldr pc, _undefined_instruction ; Undefined instruction exception

……

_undefined_instruction :
.word undefined_instruction

Some people may wonder, for the same jump instruction, why does the first sentence use b reset,
while the following ones all use ldr?

To understand this problem, let's take the undefined instruction exception as an example.

When this exception occurs, the CPU always jumps to 0x4, which is a virtual address. The physical address it maps
to depends on the specific mapping.
ldr pc, _undefined_instruction 
relative addressing, jumps to the label _undefined_instruction, but the actual jump address is actually _undefined_instruction

The content is undefined_instruction. The .word equivalent is:
_undefined_instruction dw undefined_instruction (see Graduation Notes 3 for details).
It is hard to say how far this address undefined_instruction is. It may be in the same

The page may be far away. However, except for reset, other exceptions may only occur after the MMU starts working, so

The address of undefined_instruction is also mapped by the MMU.
When the power is just turned on, the CPU starts executing from 0x0, and the MMU has not started working yet. At this time, the virtual address and the physical address are the same; on the other hand,

On the other hand, restart may also happen after MMU starts working. If reset also uses ldr, there will be problems because the virtual address and physical address are different at this time.

The address is completely different.

Therefore, the reason why reset uses b is because reset can occur before or after the MMU is established, while other exceptions can only occur after the MMU is established.

Use b reset, the reset subroutine and reset vector are on the same page, so there will be no problem (b is a relative jump)

If the two are too far apart, the compiler will report an error.