Imagelibrary/rtems
1
0
Fork 1
mirror of https://gitlab.rtems.org/rtems/rtos/rtems.git synced 2025-12-27 23:10:16 +00:00
Code Issues Packages Projects Releases Wiki Activity

2009-09-14 Sebastian Huber <sebastian.huber@embedded-brains.de>

Browse Source 
* cpu_supplement/arm.t: Update.
	* cpu_supplement/preface.texi: Typo.
	* cpu_supplement/general.t: Expanded abbreviation.
This commit is contained in:
Joel Sherrill
2009-09-14 14:50:39 +00:00
parent 7c411bda5b
commit eebcc5be64
4 changed files with 54 additions and 186 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
doc/ChangeLog
View File

@@ -1,3 +1,15 @@
2009-09-14 Sebastian Huber <sebastian.huber@embedded-brains.de>
* cpu_supplement/arm.t: Update.
* cpu_supplement/preface.texi: Typo.
* cpu_supplement/general.t: Expanded abbreviation.
2009-09-14 Sebastian Huber <sebastian.huber@embedded-brains.de>
* cpu_supplement/arm.t: Update.
* cpu_supplement/preface.texi: Typo.
* cpu_supplement/general.t: Expanded abbreviation.
2009-08-26 Sebastian Huber <sebastian.huber@embedded-brains.de>
* user/conf.t: Change stack allocator signature.

220
doc/cpu_supplement/arm.t
View File

@@ -10,144 +10,62 @@
@end ifinfo
@chapter ARM Specific Information
This chapter 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 many, many CPU models within it.
This chapter discusses the
@uref{http://en.wikipedia.org/wiki/ARM_architecture,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 many, many
CPU models within it. Currently the ARMv5 (and compatible) architecture
version as defined in the @code{ARMv5 Architecture Reference Manual} is supported by RTEMS.
@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
@c
For information on the ARM architecture refer to the
@uref{http://infocenter.arm.com,ARM Infocenter}.
@section CPU Model Dependent Features
This section 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
@code{cpukit/score/cpu/arm/rtems/score/arm.h} based upon the particular CPU
across ARM implementations and are of importance to RTEMS. The set of CPU
model feature macros are defined in the file
@file{cpukit/score/cpu/arm/rtems/score/arm.h} based upon the particular CPU
model flags specified 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
the architectural level of this CPU model. See in
@file{cpukit/score/cpu/arm/rtems/score/arm.h} for the values.
@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.
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. This is currently not used.
@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.
A floating point unit is currently not supported.
@c
@c
@c
@section Calling Conventions
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.
@c
@c
@c
Please refer to the
@uref{http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042c/IHI0042C_aapcs.pdf,Procedure Call Standard for the ARM Architecture}.
@section Memory Model
@subsection Flat Memory Model
A flat 32-bit memory model is supported. The board support package must take
care about the MMU if necessary.
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
@c
@section Interrupt Processing
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:
The ARMv5 (and compatible) architecture has seven exception types:
@itemize @bullet
@item Reset
@item Undefined instruction
@item Software interrupt (SWI)
@item Undefined
@item Software Interrupt (SWI)
@item Prefetch Abort
@item Data Abort
@item Interrupt (IRQ)
@@ -155,92 +73,30 @@ The ARM has 7 exception types:
@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.
Of these types only the IRQ has explicit operating system support. It is
intentional that the FIQ is not supported by the operating system. Without
operating system support for the FIQ it is not necessary to disable them during
critical sections of the system.
@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
The RTEMS interrupt level mapping scheme for the ARM is not a numeric level as
on most RTEMS ports. It is a bit mapping that corresponds the enable bit
postions in the Current Program Status Register (CPSR). There are only two
levels: IRQ enabled and IRQ disabled.
@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.
The board support package must initialize the interrupt stack. The memory for
the stacks is usually reserved in the linker script.
@c
@c
@c
@section Default Fatal Error Processing
The default fatal error handler for this architecture 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.
@item disables operating system supported interrupts (IRQ),
@item places the error code in @code{r0}, and
@item executes an infinite loop to simulate a halt processor instruction.
@end itemize
@c
@c
@c
@section Board Support Packages
@subsection System Reset
An RTEMS based application is initiated or re-initiated when the processor
is reset. When the processor is reset, the processor performs the
following actions:
@itemize @bullet
@item TBD
@end itemize
@subsection Processor Initialization
TBD

6
doc/cpu_supplement/general.t
View File

@@ -38,9 +38,9 @@ may be based on either an architectural specification or on maintaining
compatibility with a popular processor. Recent microprocessor families
such as the SPARC or 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.
Older families such as the Motorola 68000 and the Intel x86 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

2
doc/cpu_supplement/preface.texi
View File

@@ -33,7 +33,7 @@ which occur when a CPU core implementation is combined with
a set of peripherals to form a system on chip. For example,
there are many ARM CPU models from numerous semiconductor
vendors and a wide variety of peripherals. But at the
ISA level, they share a common compaability.
ISA level, they share a common compatibility.
RTEMS depends upon this core similarity across the CPU models
and leverages that to minimize the source code that is specific