Difference between revisions of "Unit PlatformARMv7"

Note that this is also available in the FPC RTL as ReadBarrier/WriteBarrier See: \source\rtl\arm\arm.inc
Implementation is exactly the same for either.

(See: ARMv7ThreadSetupStack for additional information)

(Base "Highest Address" of Stack)
.
.
.
.
cpsr <- The current program status register value to load on return from the context switch
lr/pc <- The address to return to from the context switch
lr <- The lr value prior to the context switch
r12 <-
r11 <-
r10 <-
r9 <-
r8 <-
r7 <-
r6 <- The value of these registers prior to the context switch
r5 <-
r4 <-
r3 <-
r2 <-
r1 <-
r0 <-

d15 <-
d14 <-
d13 <-
d12 <-
d11 <-
d10 <-
d9 <-
d8 <- The value of these floating point registers prior to the context switch
d7 <-
d6 <-
d5 <-
d4 <-
d3 <-
d2 <-
d1 <-
d0 <-

fpscr <- The floating point FPSCR register
fpexc <- The floating point FPEXC register (Current StackPointer points to here)
.
.
.
.
(Top "Lowest Address" of Stack)

This form of context switch uses r12 to save the cpsr value (and RFE to restore it). Because this context switch is called from a routine which will have saved the value of r12 (which is caller save in the ARM ABI) then we do not need to save the original value of r12.

The context switch will be performed from SYS mode to SYS mode, the cpsr value will include the control bits (Mode and IRQ/FIQ state) but not the flags values. Again the ARM ABI does not require that the flags be saved by the callee and so the caller would have accounted for any needed flags before calling. If the thread to be resumed was interrupted by an IRQ or FIQ then the cpsr will also contain the flags etc as they were at the point of interrupt. We do not need to account for the state bits in the cpsr since all operations are performed in ARM mode at present.

The main requirement of this routine is to ensure that the context record on the stack matches exactly that which is created on an interrupt and also that created by ThreadSetupStack for a new thread. If this is correct then the next context switch for any given thread can be either by a call to reschedule or by an interrupt. Equally a new thread can be first run from a context switch that resulted from either a call to reschedule or an interrupt.

Note that this routine could use:

pop (lr)
pop (r12)
msr cpsr_c, r12
mov pc, lr

To return but that would mess up the value of r12, lr and the cpsr flags etc if the thread being resumed was interrupted by an IRQ, FIQ or SWI. The use of RFE here allows for exactly the same behaviour no matter which way the context record is saved and restored.

(See: ARMv7ThreadSetupStack for additional information)

(Base "Highest Address" of Stack)
.
.
.
.
cpsr <- The current program status register value to load on return from the context switch
lr/pc <- The address to return to from the context switch
lr <- The lr value prior to the context switch
r12 <-
r11 <-
r10 <-
r9 <-
r8 <-
r7 <-
r6 <- The value of these registers prior to the context switch
r5 <-
r4 <-
r3 <-
r2 <-
r1 <-
r0 <-

d15 <-
d14 <-
d13 <-
d12 <-
d11 <-
d10 <-
d9 <-
d8 <- The value of these floating point registers prior to the context switch
d7 <-
d6 <-
d5 <-
d4 <-
d3 <-
d2 <-
d1 <-
d0 <-

fpscr <- The floating point FPSCR register
fpexc <- The floating point FPEXC register (Current StackPointer points to here)
.
.
.
.
(Top "Lowest Address" of Stack)

This form of context switch relies on the IRQ handler to save the necessary registers including the lr, cpsr and other general registers from the point at which the thread was interrupted. The thread to be resumed may have been saved by a previous IRQ or by a call to the standard context switch from SchedulerReschule or it may be a new thread to be run for the first time. All of these result in the same context record on the stack and therefore can be resumed the same way.

The context switch will be performed by switching to SYS mode, exchanging the stack pointers and then returning to IRQ mode.

(See: ARMv7ThreadSetupStack for additional information)

(Base "Highest Address" of Stack)
.
.
.
.
cpsr <- The current program status register value to load on return from the context switch
lr/pc <- The address to return to from the context switch
lr <- The lr value prior to the context switch
r12 <-
r11 <-
r10 <-
r9 <-
r8 <-
r7 <-
r6 <- The value of these registers prior to the context switch
r5 <-
r4 <-
r3 <-
r2 <-
r1 <-
r0 <-

d15 <-
d14 <-
d13 <-
d12 <-
d11 <-
d10 <-
d9 <-
d8 <- The value of these floating point registers prior to the context switch
d7 <-
d6 <-
d5 <-
d4 <-
d3 <-
d2 <-
d1 <-
d0 <-

fpscr <- The floating point FPSCR register
fpexc <- The floating point FPEXC register (Current StackPointer points to here)
.
.
.
.
(Top "Lowest Address" of Stack)

This form of context switch relies on the FIQ handler to save the necessary registers including the lr, cpsr and other general registers from the point at which the thread was interrupted. The thread to be resumed may have been saved by a previous FIQ or by a call to the standard context switch from SchedulerReschule or it may be a new thread to be run for the first time. All of these result in the same context record on the stack and therefore can be resumed the same way.

The context switch will be performed by switching to SYS mode, exchanging the stack pointers and then returning to FIQ mode.

(See: ARMv7ThreadSetupStack for additional information)

(Base "Highest Address" of Stack)
.
.
.
.
cpsr <- The current program status register value to load on return from the context switch
lr/pc <- The address to return to from the context switch
lr <- The lr value prior to the context switch
r12 <-
r11 <-
r10 <-
r9 <-
r8 <-
r7 <-
r6 <- The value of these registers prior to the context switch
r5 <-
r4 <-
r3 <-
r2 <-
r1 <-
r0 <-

d15 <-
d14 <-
d13 <-
d12 <-
d11 <-
d10 <-
d9 <-
d8 <- The value of these floating point registers prior to the context switch
d7 <-
d6 <-
d5 <-
d4 <-
d3 <-
d2 <-
d1 <-
d0 <-

fpscr <- The floating point FPSCR register
fpexc <- The floating point FPEXC register (Current StackPointer points to here)
.
.
.
.
(Top "Lowest Address" of Stack)

This form of context switch relies on the SWI handler to save the necessary registers including the lr, cpsr and other general registers from the point at which the thread was interrupted. The thread to be resumed may have been saved by a previous SWI or by a call to the standard context switch from SchedulerReschule or it may be a new thread to be run for the first time. All of these result in the same context record on the stack and therefore can be resumed the same way.

The context switch will be performed by switching to SYS mode, exchanging the stack pointers and then returning to SWI (SVC) mode.

(Base "Highest Address" of Stack)
.
.
.
.
cpsr <- The current program status register value to load on return from the context switch
(On Interrupt: Includes the flags and control bits for the interrupted thread)
(On Yield: Includes the control bits only for the yielded thread)
(On Create: Includes the control bits only for the new thread)
lr/pc <- The address to return to from the context switch
(On Interrupt: The location the thread was at before interrupt)
(On Yield: The location to return to in SchedulerReschedule)
(On Create: The location of StartProc for the new thread)

lr <- The lr value prior to the context switch
(On Interrupt: The value of lr before the thread was interrupted)
(On Yield: The location to return to in SchedulerReschedule)
(On Create: The location of ReturnProc for the new thread)

r12 <-
r11 <-
r10 <-
r9 <-
r8 <-
r7 <-
r6 <- The value of these registers prior to the context switch
r5 <- (On Interrupt: The values before the thread was interrupted)
r4 <- (On Yield: The values on return to SchedulerReschedule)
r3 <- (On Create: The values on entry to StartProc as set by ThreadSetupStack)
r2 <-
r1 <-
r0 <-

d15 <-
d14 <-
d13 <-
d12 <-
d11 <-
d10 <-
d9 <-
d8 <- The value of these floating point registers prior to the context switch
d7 <- (On Interrupt: The values before the thread was interrupted)
d6 <- (On Yield: The values on return to SchedulerReschedule)
d5 <- (On Create: The values on entry to StartProc as set by ThreadSetupStack)
d4 <-
d3 <-
d2 <-
d1 <-
d0 <-

fpscr <- The floating point FPSCR register
fpexc <- The floating point FPEXC register (Current StackPointer points to here)
.
.
.
.
(Top "Lowest Address" of Stack)

On exit from a standard context switch as performed by SchedulerReschedule the first value (Highest Address) of lr is used by the RFE (Return From Exception) instruction to load the pc which also loads the saved cpsr value.

On exit from an IRQ or FIQ context switch as performed by SchedulerSwitch the first value (Highest Address) of lr is used by the interrupt handler to return from the interrupt.

A standard context switch uses r12 to save the cpsr value (and RFE to restore it). Because the standard context switch is called from a routine which will have saved the value of r12 (which is caller save in the ARM ABI) then we do not need to save the original value of r12.

An IRQ or FIQ context switch uses the SRS (Store Return State) and RFE (Return From Exception) instructions to save and restore the cpsr value from the spsr value of either IRQ or FIQ mode.

The SWI handler first saves the SWI mode lr and spsr (which represent the location and state to return to) onto the SYS mode stack using the srsdb (Store Return State Decrement Before) instruction.

The SWI handler then switches to SYS mode and saves all the neccessary registers for the return to the interrupted thread before switching back to SWI mode in order to process the software interrupt. Because we arrive here from an interrupt the thread that was executing has no opportunity to save registers and will be unaware on return that it was interrupted. For this reason we must save all of the general purpose registers (r0 to r12) as well as the SYS mode link register (lr). We do not save the stack pointer (r13) because we use it to store the other registers and will return it to the correct value before we return from the SWI handler. The program counter (r15) does not need to be saved as it now points to this code.

The SystemCall function should pass the parameters of the call as follows:

R0 - System Call Number (eg SYSTEM_CALL_CONTEXT_SWITCH)
R1 - Parameter 1
R2 - Parameter 2
R3 - Parameter 3

To process the software interrupt
??????

To return from the software interrupt
??????

At the end of each instruction the processor checks the IRQ line and if triggered it will lookup the vector in the vector table and jump to the routine listed.

When the processor receives an IRQ it switches to IRQ mode, stores the address of the next instruction in the IRQ mode link register (lr_irq) and saves the current program status register into the IRQ mode saved program status register (spsr_irq).

The IRQ handler first saves the IRQ mode lr and spsr (which represent the location and state to return to) onto the SYS mode stack using the srsdb (Store Return State Decrement Before) instruction.

The IRQ handler then switches to SYS mode and saves all the neccessary registers for the return to the interrupted thread before switching back to IRQ mode in order to process the interrupt request. Because we arrive here from an interrupt the thread that was executing has no opportunity to save registers and will be unaware on return that it was interrupted. For this reason we must save all of the general purpose registers (r0 to r12) as well as the SYS mode link register (lr). We do not save the stack pointer (r13) because we use it to store the other registers and will return it to the correct value before we return from the IRQ handler. The program counter (r15) does not need to be saved as it now points to this code.

To process the interrupt request the handler calls the DispatchIRQ function which will dispatch the interrupt to a registered handler for processing. The handler must clear the interrupt source before it returns or the interrupt will simply occur again immediately once reenabled.

To return from the interrupt request the handler uses the rfeia (Return From Exception Increment After) instruction which will load the pc and cpsr from the SYS mode stack.

At the end of each instruction the processor checks the FIQ line and if triggered it will lookup the vector in the vector table and jump to the routine listed.

When the processor receives an FIQ it switches to FIQ mode, stores the address of the next instruction in the FIQ mode link register (lr_fiq) and saves the current program status register into the FIQ mode saved program status register (spsr_fiq).

The FIQ handler first checks the spsr to determine if the task being interrupted is a normal thread or an exception or interrupt handler.

The FIQ handler then saves the FIQ mode lr and spsr (which represent the location and state to return to) onto eihter the SYS mode or SVC mode stack using the srsdb (Store Return State Decrement Before) instruction depending on the value of spsr.

The FIQ handler switches to SYS or SVC mode and saves all the neccessary registers for the return to the interrupted task before switching back to FIQ mode in order to process the interrupt request. Because we arrive here from an interrupt the task that was executing has no opportunity to save registers and will be unaware on return that it was interrupted. For this reason we must save all of the general purpose registers (r0 to r12) as well as the SYS mode link register (lr). We do not save the stack pointer (r13) because we use it to store the other registers and will return it to the correct value before we return from the FIQ handler. The program counter (r15) does not need to be saved as it now points to this code.

To process the fast interrupt request the handler calls the DispatchFIQ function which will dispatch the interrupt to a registered handler for processing. The handler must clear the interrupt source before it returns or the fast interrupt will simply occur again immediately once reenabled.

To return from the fast interrupt request the handler uses the rfeia (Return From Exception Increment After) instruction which will load the pc and cpsr from the stack of the current mode (SYS or SVC).

Caller must call ARMv7InvalidateTLB after changes if MMU is enabled

See page ???
Caller must call ARMv7InvalidateTLB after changes if MMU is enabled

Caller must call ARMv7InvalidateTLB after changes if MMU is enabled

Caller must call ARMv7InvalidateTLB after changes if MMU is enabled

See page ???
Caller must call ARMv7InvalidateTLB after changes if MMU is enabled