Changeset ee3dd9ae in rtems

Oct 20, 1998, 4:25:29 PM (21 years ago)
Joel Sherrill <joel.sherrill@…>
4.10, 4.11, 4.8, 4.9, master

Significant additions.

1 edited


  • doc/bsp_howto/target.t

    racee84c ree3dd9ae  
    9 @chapter CPU and Board Dependent Files
    11 RTEMS divides board dependencies into two parts:
     9@chapter Target Dependent Files
     11RTEMS has a multi-layered approach to portability.  This is done to
     12maximize the amount of software that can be reused.  Much of the
     13RTEMS source code can be reused on all RTEMS platforms.  Other parts
     14of the executive are specific to hardware in some sense.
     15RTEMS classifies target dependent code based upon its dependencies
     16into one of the following categories.
    1318@itemize @bullet
    15 @item the CPU dependant code : it provides basics calls to the kernel,
    16 just as the context switch or the interrupt subroutine implementations.
    17 Sources for the supported families of processors can be found in
    18 $RTEMS_ROOT/c/src/exec/score/cpu. A good starti ng point for a new family
    19 of processors is the no_cpu directory, which holds both prototypes and
    20 descriptions of each needed CPU dependant function.
    22 @item the board dependant code : it includes support for a given board,
    23 such as the board initialization code and drivers for the various devices:
     19@item CPU dependent
     20@item Board dependent
     21@item Peripheral dependent
    2522@end itemize
    27 Porting RTEMS on a new board should raise two questions:
     24@subheading CPU Dependent
     26This class of code includes the foundation
     27routines for the executive proper such as as the context switch and
     28the interrupt subroutine implementations.  Sources for the supported
     29processor families can be found in @code{$RTEMS_ROOT/c/src/exec/score/cpu}.
     30A good starting point for a new family of processors is the
     31@code{no_cpu} directory, which holds both prototypes and
     32descriptions of each needed CPU dependent function.
     34CPU dependent code is further subcategorized if the implementation is
     35dependent on a particular CPU model.  For example, the MC68000 and MC68020
     36processors are both members of the m68k CPU family but there are significant
     37differents between these CPU models which RTEMS must take into account.
     39@subheading Board Dependent
     41This class of code provides the most specific glue between RTEMS and
     42a particular board.  This code is represented by the Board Support Packages
     43and associated Device Drivers.
     45Some BSPs may support multiple board models within a single board family.
     46This is necessary when the board's vendor supports build variants on a
     47single base base.  For example, the Motorola MVME162 board family has a
     48a fairly large number of variations based upon the particular CPU model
     49and the peripherals actually placed on the board.
     51@subheading Peripheral Dependent
     53This class of code provides a reusable library of peripheral device
     54drivers which can be tailored easily to a particular board.  This
     55reusable library provides software objects which correspond to standard
     56controllers.  Just as the hardware engineer choose a standard controller
     57when designing a board, the goal of this library is to let the software
     58engineer do the same thing.
     60@section Questions to Ask
     62Porting RTEMS on a new board should raise some questions:
    2964@itemize @bullet
    31 @item is the main board CPU supported ?
    33 @item does a BSP for a similar board exists ?
     66@item Does a BSP for this board exist?
     68@item Does a BSP for a similar board exists?
     70@item Is the board's CPU supported?
    3572@end itemize
    37 If the main board CPU is supported, you will only have do write the Board
    38 Support Package. Otherwise you'll have to write both CPU dependant code
    39 and the BSP. One should always start writing a BSP from a similar one.
     74If there is already a BSP for your board, then you may already be ready
     75to start developing application software.  You should verify that the
     76existing BSP provides device drivers for all the peripherals on the board
     77that your application will be using.  For example, the board may have
     78an Ethernet controller which is not supported by the existing BSP.
     80If the BSP does not exist and the board's CPU model is supported, then
     81you should look at existing BSPs for a close match.  This will help
     82reduce the effort required.  It is often possible to reuse device drivers
     83from BSPs from different CPU families.
     85If the board's CPU family is supported but the particular CPU model on
     86that board is not, then the RTEMS port to that CPU family will have to
     87be augmented.  After this is done, then you can proceed to developing
     88the new BSP.
     90Otherwise you'll have to write both CPU dependent code and the BSP.
     92Regardless of the amount of development required, OAR Corporation
     93offers custom development services to help you use RTEMS.
     94@ifset use-html
     95For more information, contact OAR Corporation
     96at @href{,,,}.
     97@end ifset
     98@ifclear use-html
     99For more information, contact OAR Corporation
     101@end ifclear
    41104@section CPU Dependent Executive Files
    43 XXX
     106The CPU dependent files in the RTEMS executive source code are found
     107in the following directory:
     111@end example
     113where CPU is replcaed with the CPU family name.
     115Within each CPU dependent directory inside the executive proper is a
     116file named @code{CPU.h} which contains information about each of the
     117supported CPU models within that family.
    45119@section CPU Dependent Support Files
    47 XXX
     121The CPU dependent support files contain routines which aid in the development
     122of applications using that CPU family.  For example, the support routines
     123may contain standard trap handlers for alignment or floating point exceptions
     124or device drivers for peripheral controllers found on the CPU itself.
     125This class of code may be found in the following directory:
     129@end example
     131CPU model dependent support code is found in the following directory:
     135@end example
    49137@section Board Support Package Structure
    51 The BSPs are kept in the $RTEMS_ROOT/c/src/lib/libbsp directory. They
    52 are filed under the processor family (m68k, powerpc, etc.). A given BSP
    53 consists in the following directories:
     139The BSPs are all under the c/src/lib/libbsp directory.  Below this
     140directory, there is a subdirectory for each CPU family.  Each BSP
     141is found under the subdirectory for the appropriate processor
     142family (m68k, powerpc, etc.).  In addition, there is source code
     143available which may be shared across all BSPs regardless of
     144the CPU family or just across BSPs within a single CPU family.  This
     145results in a BSP using the following directories:
     151@end example
     153Under each BSP specific directory, you will find a collection of
     154subdirectories.  For commonly provided functionality, the BSPs
     155follow a convention on subdirectory naming.  The following list
     156describes the commonly found subdirectories under each BSP.
    55158@itemize @bullet
    57 @item @b{clock} -
    58 support for the realtime clock, which provides a regular
    59 time basis to the kernel,
    61 @item @b{console} -
    62 rather the serial driver than only a console driver, it
    63 deals with the board UARTs (i.e. serial devices),
    65 @item @b{include} -
    66 the include files,
    68 @item @b{startup} -
    69 the board initialization code,
    71 @item @b{timer} -
    72 support of timer devices,
    74 @item @b{shmsupp} -
    75 support of shared memory in a multiprocessor system,
    77 @item @b{network} -
    78 the Ethernet driver.
    80 @item @b{rtc} -
    81 the real-time clock driver.
    83 @item @b{wrapup} - XXX
     160@item @b{console}:
     161is technically the serial driver for the BSP rather
     162than just a console driver, it deals with the board
     163UARTs (i.e. serial devices).
     165@item @b{clock}:
     166support for the clock tick -- a regular time basis to the kernel.
     168@item @b{timer}:
     169support of timer devices.
     171@item @b{rtc}:
     172support for the hardware real-time clock.
     174@item @b{nvmem}:
     175support for non-volatile memory such as EEPROM or Flash.
     177@item @b{network}:
     178the Ethernet driver.
     180@item @b{shmsupp}:
     181support of shared memory driver MPCI layer in a multiprocessor system,
     183@item @b{include}:
     184include files for this BSP.
     186@item @b{wrapup}:
     187bundles all the components necessary to construct the BSP library.
    85189@end itemize
    87 Another important element are the makefiles, which have to be provided by
    88 the user.
     191The build order of the BSP is determined by the Makefile structure.
     192This structure is discussed in more detail in the @ref{Makefiles}
     194RTEMS uses the @b{GNU autoconf} automatic configuration package.  This
     195tool specializes the @code{} files at the time that RTEMS
     196is configured for a specific development host and target.  Makefiles
     197are automatically generated from the @code{} files.  It is
     198necessary for the BSP developer to provide these files.  Most of the
     199time, it is possible to copy the @code{} from another
     200similar directory and edit it.
    91202@b{NOTE:} This manual refers to the gen68340 BSP for numerous concrete
    97 $RTEMS_ROOT/c/src/lib/libbsp/m68k/gen68340
    98209@end example
Note: See TracChangeset for help on using the changeset viewer.