Split document into seperate files by section.

1 files changed, 147 insertions, 0 deletions

diff --git a/porting/cpu_model_variations.rst b/porting/cpu_model_variations.rst
new file mode 100644
index 0000000..797a009
--- /dev/null
+++ b/porting/cpu_model_variations.rst
@@ -0,0 +1,147 @@
+CPU Model Variations
+####################
+
+XXX enhance using portability presentation from CS595 class.  See
+general/portability.ppt.
+
+Since the text in the next section was written, RTEMS view of
+portability has grown to distinguish totally portable, CPU
+family dependent, CPU model dependent, peripheral chip dependent
+and board dependent.  This text was part of a larger paper that
+did not even cover portability completely as it existed when this
+was written and certainly is out of date now. :)
+
+Overview of RTEMS Portability
+=============================
+
+RTEMS was designed to be a highly portable, reusable software component.
+This reflects the fundamental nature of embedded systems in which hardware
+components, ranging from boards to peripherals to even the processor
+itself, are selected specifically to meet the requirements of a particular
+project.
+
+Processor Families
+------------------
+
+Since there are a wide variety of embedded systems, there are a wide
+variety of processors targeting embedded systems. RTEMS alleviates some of
+the burden on the embedded systems programmer by providing a consistent,
+high-performance environment regardless of the target processor.  RTEMS
+has been ported to a variety of microprocessor families including:
+
+- Motorola ColdFire
+
+- Motorola MC68xxx
+
+- Motorola MC683xx
+
+- Intel ix86 (i386, i486, Pentium and above)
+
+- ARM
+
+- MIPS
+
+- PowerPC 4xx, 5xx, 6xx, 7xx, 8xx, and 84xx
+
+- SPARC
+
+- Hitachi H8/300
+
+- Hitachi SH
+
+- OpenCores OR32
+
+- Texas Instruments C3x/C4x
+
+In addition, there is a port of RTEMS to UNIX that uses standard UNIX
+services to simulate the embedded environment.
+
+Each RTEMS port supplies a well-defined set of services that are the
+foundation for the highly portable RTEMS and POSIX API implementations.
+When porting to a new processor family, one must provide the processor
+dependent implementation of these services.  This set of processor
+dependent core services includes software to perform interrupt
+dispatching, context switches, and manipulate task register sets.
+
+The RTEMS approach to handling varying processor models reflects the
+approach taken by the designers of the processors themselves.  In each
+processor family, there is a core architecture that must be implemented on
+all processor models within the family to provide any level of
+compatibility.  Many of the modern RISC architectures refer to this as the
+Architectural Definition.  The Architectural Definition is intended to be
+independent of any particular implementation. Additionally, there is a
+feature set which is allowed to vary in a defined way amongst the
+processor models.  These feature sets may be defined as Optional in the
+Architectural Definition, be left as implementation defined
+characteristics, or be processor model specific extensions.  Support for
+floating point, virtual memory, and low power mode are common Optional
+features included in an Architectural Definition.
+
+The processor family dependent software in RTEMS includes a definition of
+which features are present in each supported processor model.  This often
+makes adding support for a new processor model within a supported family
+as simple as determining which features are present in the new processor
+implementation.  If the new processor model varies in a way previously
+unaccounted for, then this must be addressed.  This could be the result of
+a new Optional feature set being added to the Architectural Definition.
+Alternatively, this particular processor model could have a new and
+different implementation of a feature left as undefined in the
+Architectural Definition.  This would require software to be written to
+utilize that feature.
+
+There is a relatively small set of features that may vary in a processor
+family.  As the number of processor models in the family grow, the
+addition of each new model only requires adding an entry for the new model
+to the single feature table.  It does not require searching for every
+conditional based on processor model and adding the new model in the
+appropriate place.  This significantly eases the burden of adding a new
+processor model as it centralizes and logically simplifies the process.
+
+Boards
+------
+
+Being portable both between models within a processor family and across
+processor families is not enough to address the needs of embedded systems
+developers.  Custom board development is the norm for embedded systems.
+Each of these boards is optimized for a particular project.  The processor
+and peripheral set have been chosen to meet a particular set of system
+requirements.  The tools in the embedded systems developers’ toolbox must
+support their project’s unique board.  RTEMS addresses this issue via the
+Board Support Package.
+
+RTEMS segregates board specific code to make it possible for the embedded
+systems developer to easily replace and customize this software.  A
+minimal Board Support Package includes device drivers for a clock tick,
+console I/O, and a benchmark timer (optional) as well as startup and
+miscellaneous support code.  The Board Support Package for a project may
+be extended to include the device drivers for any peripherals on the
+custom board.
+
+Applications
+------------
+
+One important design goal of RTEMS was to provide a bridge between the
+application software and the target hardware.  Most hardware dependencies
+for real-time applications can be localized to the low level device
+drivers which provide an abstracted view of the hardware.  The RTEMS I/O
+interface manager provides an efficient tool for incorporating these
+hardware dependencies into the system while simultaneously providing a
+general mechanism to the application code that accesses them.  A well
+designed real-time system can benefit from this architecture by building a
+rich library of standard application components which can be used
+repeatedly in other real-time projects. The following figure illustrates
+how RTEMS serves as a buffer between the project dependent application
+code and the target hardware.
+
+Coding Issues
+=============
+
+XXX deal with this as it applies to score/cpu.  Section name may
+be bad.
+
+.. COMMENT: COPYRIGHT (c) 1988-2002.
+
+.. COMMENT: On-Line Applications Research Corporation (OAR).
+
+.. COMMENT: All rights reserved.
+