diff options
Diffstat (limited to 'doc/cpu_supplement/arm.t')
| -rw-r--r-- | doc/cpu_supplement/arm.t | 595 |
1 files changed, 595 insertions, 0 deletions
diff --git a/doc/cpu_supplement/arm.t b/doc/cpu_supplement/arm.t new file mode 100644 index 0000000000..91e9f23286 --- /dev/null +++ b/doc/cpu_supplement/arm.t @@ -0,0 +1,595 @@ +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@ifinfo +@end ifinfo +@chapter ARM Specific Information + +The Real Time Executive for Multiprocessor Systems (RTEMS) +is designed to be portable across multiple processor +architectures. However, the nature of real-time systems makes +it essential that the application designer understand certain +processor dependent implementation details. These processor +dependencies include calling convention, board support package +issues, interrupt processing, exact RTEMS memory requirements, +performance data, header files, and the assembly language +interface to the executive. + +This document discusses the ARM architecture dependencies +in this port of RTEMS. The ARM family has a wide variety +of implementations by a wide range of vendors. Consequently, +there are 100's of CPU models within it. + +It is highly recommended that the ARM +RTEMS application developer obtain and become familiar with the +documentation for the processor being used as well as the +documentation for the ARM architecture as a whole. + +@subheading Architecture Documents + +For information on the ARM architecture, +refer to the following documents available from Arm, Limited +(@file{http//www.arm.com/}). There does not appear to +be an electronic version of a manual on the architecture +in general on that site. The following book is a good +resource: + +@itemize @bullet +@item @cite{David Seal. "ARM Architecture Reference Manual." +Addison-Wesley. @b{ISBN 0-201-73719-1}. 2001.} + +@end itemize + + +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section CPU Model Dependent Features + + +Microprocessors are generally classified into +families with a variety of CPU models or implementations within +that family. Within a processor family, there is a high level +of binary compatibility. This family may be based on either an +architectural specification or on maintaining compatibility with +a popular processor. Recent microprocessor families such as the +ARM, SPARC, and PowerPC are based on an architectural specification +which is independent or any particular CPU model or +implementation. Older families such as the M68xxx and the iX86 +evolved as the manufacturer strived to produce higher +performance processor models which maintained binary +compatibility with older models. + +RTEMS takes advantage of the similarity of the +various models within a CPU family. Although the models do vary +in significant ways, the high level of compatibility makes it +possible to share the bulk of the CPU dependent executive code +across the entire family. Each processor family supported by +RTEMS has a list of features which vary between CPU models +within a family. For example, the most common model dependent +feature regardless of CPU family is the presence or absence of a +floating point unit or coprocessor. When defining the list of +features present on a particular CPU model, one simply notes +that floating point hardware is or is not present and defines a +single constant appropriately. Conditional compilation is +utilized to include the appropriate source code for this CPU +model's feature set. It is important to note that this means +that RTEMS is thus compiled using the appropriate feature set +and compilation flags optimal for this CPU model used. The +alternative would be to generate a binary which would execute on +all family members using only the features which were always +present. + +This chapter presents the set of features which vary +across ARM implementations and are of importance to RTEMS. +The set of CPU model feature macros are defined in the file +cpukit/score/cpu/arm/rtems/score/arm.h based upon the particular CPU +model defined on the compilation command line. + +@subsection CPU Model Name + +The macro @code{CPU_MODEL_NAME} is a string which designates +the architectural level of this CPU model. The following is +a list of the settings for this string based upon @code{gcc} +CPU model predefines: + +@example +__ARM_ARCH4__ "ARMv4" +__ARM_ARCH4T__ "ARMv4T" +__ARM_ARCH5__ "ARMv5" +__ARM_ARCH5T__ "ARMv5T" +__ARM_ARCH5E__ "ARMv5E" +__ARM_ARCH5TE__ "ARMv5TE" +@end example + +@subsection Count Leading Zeroes Instruction + +The ARMv5 and later has the count leading zeroes (@code{clz}) +instruction which could be used to speed up the find first bit +operation. The use of this instruction should significantly speed up +the scheduling associated with a thread blocking. + +@subsection Floating Point Unit + +The macro ARM_HAS_FPU is set to 1 to indicate that +this CPU model has a hardware floating point unit and 0 +otherwise. It does not matter whether the hardware floating +point support is incorporated on-chip or is an external +coprocessor. + +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section Calling Conventions + + +Each high-level language compiler generates +subroutine entry and exit code based upon a set of rules known +as the compiler's calling convention. These rules address the +following issues: + +@itemize @bullet +@item register preservation and usage +@item parameter passing +@item call and return mechanism +@end itemize + +A compiler's calling convention is of importance when +interfacing to subroutines written in another language either +assembly or high-level. Even when the high-level language and +target processor are the same, different compilers may use +different calling conventions. As a result, calling conventions +are both processor and compiler dependent. + +@subsection Processor Background + +The ARM architecture supports a simple yet +effective call and return mechanism. A subroutine is invoked +via the branch and link (@code{bl}) instruction. This instruction +saves the return address in the @code{lr} register. Returning +from a subroutine only requires that the return address be +moved into the program counter (@code{pc}), possibly with +an offset. It is is important to +note that the @code{bl} instruction does not +automatically save or restore any registers. It is the +responsibility of the high-level language compiler to define the +register preservation and usage convention. + +@subsection Calling Mechanism + +All RTEMS directives are invoked using the @code{bl} +instruction and return to the user application via the +mechanism described above. + +@subsection Register Usage + +As discussed above, the ARM's call and return mechanism dos +not automatically save any registers. RTEMS uses the registers +@code{r0}, @code{r1}, @code{r2}, and @code{r3} as scratch registers and +per ARM calling convention, the @code{lr} register is altered +as well. These registers are not preserved by RTEMS directives +therefore, the contents of these registers should not be assumed +upon return from any RTEMS directive. + +@subsection Parameter Passing + +RTEMS assumes that ARM calling conventions are followed and that +the first four arguments are placed in registers @code{r0} through +@code{r3}. If there are more arguments, than that, then they +are place on the stack. + +@subsection User-Provided Routines + +All user-provided routines invoked by RTEMS, such as +user extensions, device drivers, and MPCI routines, must also +adhere to these calling conventions. + +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section Memory Model + + +A processor may support any combination of memory +models ranging from pure physical addressing to complex demand +paged virtual memory systems. RTEMS supports a flat memory +model which ranges contiguously over the processor's allowable +address space. RTEMS does not support segmentation or virtual +memory of any kind. The appropriate memory model for RTEMS +provided by the targeted processor and related characteristics +of that model are described in this chapter. + +@subsection Flat Memory Model + +Members of the ARM family newer than Version 3 support a flat +32-bit address space with addresses ranging from 0x00000000 to +0xFFFFFFFF (4 gigabytes). Each address is represented by a +32-bit value and is byte addressable. +The address may be used to reference a +single byte, word (2-bytes), or long word (4 bytes). Memory +accesses within this address space are performed in the endian +mode that the processor is configured for. In general, ARM +processors are used in little endian mode. + +Some of the ARM family members such as the +920 and 720 include an MMU and thus support virtual memory and +segmentation. RTEMS does not support virtual memory or +segmentation on any of the ARM family members. + +@c +@c Interrupt Stack Frame Picture +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section Interrupt Processing + + +Different types of processors respond to the +occurrence of an interrupt in its own unique fashion. In +addition, each processor type provides a control mechanism to +allow for the proper handling of an interrupt. The processor +dependent response to the interrupt modifies the current +execution state and results in a change in the execution stream. +Most processors require that an interrupt handler utilize some +special control mechanisms to return to the normal processing +stream. Although RTEMS hides many of the processor dependent +details of interrupt processing, it is important to understand +how the RTEMS interrupt manager is mapped onto the processor's +unique architecture. Discussed in this chapter are the ARM's +interrupt response and control mechanisms as they pertain to +RTEMS. + +The ARM has 7 exception types: +@itemize @bullet + +@item Reset +@item Undefined instruction +@item Software interrupt (SWI) +@item Prefetch Abort +@item Data Abort +@item Interrupt (IRQ) +@item Fast Interrupt (FIQ) + +@end itemize + +Of these types, only IRQ and FIQ are handled through RTEMS's interrupt +vectoring. + +@subsection Vectoring of an Interrupt Handler + + +Unlike many other architectures, the ARM has seperate stacks for each +interrupt. When the CPU receives an interrupt, it: + +@itemize @bullet +@item switches to the exception mode corresponding to the interrupt, + +@item saves the Current Processor Status Register (CPSR) to the +exception mode's Saved Processor Status Register (SPSR), + +@item masks off the IRQ and if the interrupt source was FIQ, the FIQ +is masked off as well, + +@item saves the Program Counter (PC) to the exception mode's Link +Register (LR - same as R14), + +@item and sets the PC to the exception's vector address. + +@end itemize + +The vectors for both IRQ and FIQ point to the _ISR_Handler function. +_ISR_Handler() calls the BSP specific handler, ExecuteITHandler(). Before +calling ExecuteITHandler(), registers R0-R3, R12, and R14(LR) are saved so +that it is safe to call C functions. Even ExecuteITHandler() can be written +in C. + +@subsection Interrupt Levels + +The ARM architecture supports two external interrupts - IRQ and FIQ. FIQ +has a higher priority than IRQ, and has its own version of register R8 - R14, +however RTEMS does not take advantage of them. Both interrupts are enabled +through the CPSR. + +The RTEMS interrupt level mapping scheme for the AEM is not a numeric level +as on most RTEMS ports. It is a bit mapping that corresponds the enable +bits's postions in the CPSR: + +@table @b +@item FIQ +Setting bit 6 (0 is least significant bit) disables the FIQ. + +@item IRQ +Setting bit 7 (0 is least significant bit) disables the IRQ. + +@end table + + +@subsection Disabling of Interrupts by RTEMS + +During the execution of directive calls, critical +sections of code may be executed. When these sections are +encountered, RTEMS disables interrupts to level seven (7) before +the execution of this section and restores them to the previous +level upon completion of the section. RTEMS has been optimized +to insure that interrupts are disabled for less than +RTEMS_MAXIMUM_DISABLE_PERIOD microseconds on a +RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ Mhz processor with +zero wait states. These numbers will vary based the +number of wait states and processor speed present on the target board. +[NOTE: The maximum period with interrupts disabled is hand calculated. This +calculation was last performed for Release +RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.] + +Non-maskable interrupts (NMI) cannot be disabled, and +ISRs which execute at this level MUST NEVER issue RTEMS system +calls. If a directive is invoked, unpredictable results may +occur due to the inability of RTEMS to protect its critical +sections. However, ISRs that make no system calls may safely +execute as non-maskable interrupts. + +@subsection Interrupt Stack + +RTEMS expects the interrupt stacks to be set up in bsp_start(). The memory +for the stacks is reserved in the linker script. + +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section Default Fatal Error Processing + + +Upon detection of a fatal error by either the +application or RTEMS the fatal error manager is invoked. The +fatal error manager will invoke the user-supplied fatal error +handlers. If no user-supplied handlers are configured, the +RTEMS provided default fatal error handler is invoked. If the +user-supplied fatal error handlers return to the executive the +default fatal error handler is then invoked. This chapter +describes the precise operations of the default fatal error +handler. + +@subsection Default Fatal Error Handler Operations + +The default fatal error handler which is invoked by +the @code{rtems_fatal_error_occurred} directive when there is +no user handler configured or the user handler returns control to +RTEMS. The default fatal error handler performs the +following actions: + +@itemize @bullet +@item disables processor interrupts, +@item places the error code in @b{r0}, and +@item executes an infinite loop (@code{while(0);} to +simulate a halt processor instruction. +@end itemize + +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section Board Support Packages + + +An RTEMS Board Support Package (BSP) must be designed +to support a particular processor and target board combination. +This chapter presents a discussion of XXX specific BSP +issues. For more information on developing a BSP, refer to the +chapter titled Board Support Packages in the RTEMS +Applications User's Guide. + +@subsection System Reset + +An RTEMS based application is initiated or +re-initiated when the XXX processor is reset. When the +XXX is reset, the processor performs the following actions: + +@itemize @bullet +@item The tracing bits of the status register are cleared to +disable tracing. + +@item The supervisor interrupt state is entered by setting the +supervisor (S) bit and clearing the master/interrupt (M) bit of +the status register. + +@item The interrupt mask of the status register is set to +level 7 to effectively disable all maskable interrupts. + +@item The vector base register (VBR) is set to zero. + +@item The cache control register (CACR) is set to zero to +disable and freeze the processor cache. + +@item The interrupt stack pointer (ISP) is set to the value +stored at vector 0 (bytes 0-3) of the exception vector table +(EVT). + +@item The program counter (PC) is set to the value stored at +vector 1 (bytes 4-7) of the EVT. + +@item The processor begins execution at the address stored in +the PC. +@end itemize + +@subsection Processor Initialization + +The address of the application's initialization code +should be stored in the first vector of the EVT which will allow +the immediate vectoring to the application code. If the +application requires that the VBR be some value besides zero, +then it should be set to the required value at this point. All +tasks share the same XXX's VBR value. Because interrupts +are enabled automatically by RTEMS as part of the initialize +executive directive, the VBR MUST be set before this directive +is invoked to insure correct interrupt vectoring. If processor +caching is to be utilized, then it should be enabled during the +reset application initialization code. + +In addition to the requirements described in the +Board Support Packages chapter of the Applications User's +Manual for the reset code which is executed before the call to +initialize executive, the XXX version has the following +specific requirements: + +@itemize @bullet +@item Must leave the S bit of the status register set so that +the XXX remains in the supervisor state. + +@item Must set the M bit of the status register to remove the +XXX from the interrupt state. + +@item Must set the master stack pointer (MSP) such that a +minimum stack size of MINIMUM_STACK_SIZE bytes is provided for +the initialize executive directive. + +@item Must initialize the XXX's vector table. +@end itemize + +Note that the BSP is not responsible for allocating +or installing the interrupt stack. RTEMS does this +automatically as part of initialization. If the BSP does not +install an interrupt stack and -- for whatever reason -- an +interrupt occurs before initialize_executive is invoked, then +the results are unpredictable. + +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section Processor Dependent Information Table + + +Any highly processor dependent information required +to describe a processor to RTEMS is provided in the CPU +Dependent Information Table. This table is not required for all +processors supported by RTEMS. This chapter describes the +contents, if any, for a particular processor type. + +@subsection CPU Dependent Information Table + +The XXX version of the RTEMS CPU Dependent +Information Table contains the information required to interface +a Board Support Package and RTEMS on the XXX. This +information is provided to allow RTEMS to interoperate +effectively with the BSP. The C structure definition is given +here: + +@example +@group +typedef struct @{ + void (*pretasking_hook)( void ); + void (*predriver_hook)( void ); + void (*postdriver_hook)( void ); + void (*idle_task)( void ); + boolean do_zero_of_workspace; + unsigned32 idle_task_stack_size; + unsigned32 interrupt_stack_size; + unsigned32 extra_mpci_receive_server_stack; + void * (*stack_allocate_hook)( unsigned32 ); + void (*stack_free_hook)( void* ); + /* end of fields required on all CPUs */ + + /* XXX CPU family dependent stuff */ +@} rtems_cpu_table; +@end group +@end example + +@table @code +@item pretasking_hook +is the address of the user provided routine which is invoked +once RTEMS APIs are initialized. This routine will be invoked +before any system tasks are created. Interrupts are disabled. +This field may be NULL to indicate that the hook is not utilized. + +@item predriver_hook +is the address of the user provided +routine that is invoked immediately before the +the device drivers and MPCI are initialized. RTEMS +initialization is complete but interrupts and tasking are disabled. +This field may be NULL to indicate that the hook is not utilized. + +@item postdriver_hook +is the address of the user provided +routine that is invoked immediately after the +the device drivers and MPCI are initialized. RTEMS +initialization is complete but interrupts and tasking are disabled. +This field may be NULL to indicate that the hook is not utilized. + +@item idle_task +is the address of the optional user +provided routine which is used as the system's IDLE task. If +this field is not NULL, then the RTEMS default IDLE task is not +used. This field may be NULL to indicate that the default IDLE +is to be used. + +@item do_zero_of_workspace +indicates whether RTEMS should +zero the Workspace as part of its initialization. If set to +TRUE, the Workspace is zeroed. Otherwise, it is not. + +@item idle_task_stack_size +is the size of the RTEMS idle task stack in bytes. +If this number is less than MINIMUM_STACK_SIZE, then the +idle task's stack will be MINIMUM_STACK_SIZE in byte. + +@item interrupt_stack_size +is the size of the RTEMS +allocated interrupt stack in bytes. This value must be at least +as large as MINIMUM_STACK_SIZE. + +@item extra_mpci_receive_server_stack +is the extra stack space allocated for the RTEMS MPCI receive server task +in bytes. The MPCI receive server may invoke nearly all directives and +may require extra stack space on some targets. + +@item stack_allocate_hook +is the address of the optional user provided routine which allocates +memory for task stacks. If this hook is not NULL, then a stack_free_hook +must be provided as well. + +@item stack_free_hook +is the address of the optional user provided routine which frees +memory for task stacks. If this hook is not NULL, then a stack_allocate_hook +must be provided as well. + +@item XXX +is where the CPU family dependent stuff goes. + +@end table |