summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
-rw-r--r--doc/ChangeLog12
-rw-r--r--doc/cpu_supplement/arm.t220
-rw-r--r--doc/cpu_supplement/general.t6
-rw-r--r--doc/cpu_supplement/preface.texi2
4 files changed, 54 insertions, 186 deletions
diff --git a/doc/ChangeLog b/doc/ChangeLog
index eb05e3aa94..89c6186d54 100644
--- a/doc/ChangeLog
+++ b/doc/ChangeLog
@@ -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.
diff --git a/doc/cpu_supplement/arm.t b/doc/cpu_supplement/arm.t
index 697d306e02..66ac826a9c 100644
--- a/doc/cpu_supplement/arm.t
+++ b/doc/cpu_supplement/arm.t
@@ -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
-
-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.
+A flat 32-bit memory model is supported. The board support package must take
+care about the MMU if necessary.
-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.
-@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
-
+@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
-
-@subsection Processor Initialization
-
-TBD
diff --git a/doc/cpu_supplement/general.t b/doc/cpu_supplement/general.t
index c4f277d27f..b91476eb9f 100644
--- a/doc/cpu_supplement/general.t
+++ b/doc/cpu_supplement/general.t
@@ -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
diff --git a/doc/cpu_supplement/preface.texi b/doc/cpu_supplement/preface.texi
index 8184c54bcd..7d3fc5e736 100644
--- a/doc/cpu_supplement/preface.texi
+++ b/doc/cpu_supplement/preface.texi
@@ -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