Overview#

This feature provides support for ARMv7 architecture processors. This revision of the architecture extends the ARMv6 architecture with:

• a new Thumb2 instruction set that implements 16/32 bits instructions that do not require any ARM instruction set support in the OS.
• a new ThumbEE instruction set designed for dynamic code generation (for example JIT compilers)
• advanced SIMD instruction set implemented by the Neon coprocessor
• a new VFPv3 floating point architecture
• a hierarchical cache architecture

QNX does not support Thumb or Jazelle (Java instruction set) so the core OS support requires only a few changes to the existing ARMv6 support implemented in libstartup.a and procnto-v6:

• libstartup support that is generic to all ARMv7 processor implementations
• libstartup support that is specific to Cortex-A8 processors
• kernel support for VFPv3/Neon context switching
• miscellaneous support

Board/BSP specific details for specific target boards using Cortex-A8 are outside the scope of this design document.

PR60971 is being used to track the code changes that are specific to ARMv7 and Cortex-A8 development work for 6.4.1

Design Review Status#

No general design review was performed for this work because:

• the startup related changes are straightforward cpu-specific implementation functions within the existing framework
• the VFP related changes are straightforward cpu-specific implementation functions within the existing framework
• the remaining kernel changes were in effect bug-fixes for problems encountered when testing on a Cortex-A8 target

Startup Support#

Generic ARMv7 Support#

The generic support for ARMv7 includes the following:

• handling the hierarchical cache architecture (arm_cache.c)
• handling ARMv7 specific page table encodings (armv_pte_v7xx.c)
• handling ARMv7 specific processor initialisation (armv_setup_v7.c)

Note that there is one outstanding issue: the current cstart.S implementation uses a CP15 cache invalidate operation that is not implemented in ARMv7. That code is intended to flush instruction/data caches and TLBs before jumping to the kernel entry point.

The current workaround for this is to implement a custom cstart.S in the board startup directory until a cleaner approach can be implemented.

Cortex-A8 Support#

The Cortex-A8 support includes the following:

• processor configuration information (armv_chip_a8.c)
• processor specific cache/TLB support (armv_cache_a8.c, callout_cache_a8.S, callout_page_a8.S)
• processor specific initialisation (armv_setup_a8.c)

Kernel Support#

VFPv3/Neon Support#

The current kernel code implements context swithc support for the VFPv2 implementation. The VFPv3 architecture differs in a number of ways relevant to context switch code:

• it can implement either 16 or 32 double registers (VFPv2 supported only 16 doubles)
• it is optional whether trapped FP exceptions are implemented, which means the relevant registers may not be present

This requires the vfp_init() function to detect which VFP version is present an use the appropriate context switch routines.

Miscellaneous Support#

Athough non-ARM instruction sets are not supported by QNX, it is possible that user code could execute in Thumb, Thumb2 or ThumbEE due to buggy code that causes an interworking branch that switches instruction set.

Various areas of kernel code may need to check the user instruction set mode to prevent incorrect operation:

• data abort handler cannot assume the faulting instruction is an ARM instruction (to determine whether it was a read or write access)
• undefined instruction handler cannot assume the faulting instruction is an ARM instruction (to determine what action to perform)
• kernel code that directly executes user code must ensure the CPSR specifies ARM mode before executing that code

Data Abort Handler#

Undefined Instruction Handler#

Forced User Code Execution#

This currently occurs for the following cases:

• invocation of cancellation stubs. This is known to be ARM code in libc so does not require any special action
• invocation of signal handlers. This is know to be ARM code in libc so does not require any special action
• resuming code after signal handler execution. This can be to arbitrary user code so the kernel forces CPSR to ARM mode
• executing the call stubs in the system page kercall section. This is ARM code so, the kernel forces CPSR to ARM mode