Changeset 928bf73 in rtems-docs


Ignore:
Timestamp:
Feb 4, 2020, 6:52:42 AM (5 months ago)
Author:
Sebastian Huber <sebastian.huber@…>
Branches:
5, master
Children:
4205250
Parents:
813ada5
git-author:
Sebastian Huber <sebastian.huber@…> (02/04/20 06:52:42)
git-committer:
Sebastian Huber <sebastian.huber@…> (02/04/20 08:20:12)
Message:

bsp-howto: Remove obsolete information

Remove obsolete information as well as information which is highly
specific to a particular platform.

Update #2852.

File:
1 edited

Legend:

Unmodified
Added
Removed
  • bsp-howto/initilization_code.rst

    r813ada5 r928bf73  
    5252   In most BSPs, the directory named ``start340`` in the gen68340 BSP would be
    5353   simply named ``start`` or start followed by a BSP designation.
    54 
    55 Required Global Variables
    56 =========================
    57 
    58 Although not strictly part of initialization, there are a few global variables
    59 assumed to exist by reusable device drivers.  These global variables should
    60 only defined by the BSP when using one of these device drivers.
    61 
    62 The BSP author probably should be aware of the ``Configuration`` Table
    63 structure generated by ``<rtems/confdefs.h>`` during debug but should not
    64 explicitly reference it in the source code.  There are helper routines provided
    65 by RTEMS to access individual fields.
    66 
    67 In older RTEMS versions, the BSP included a number of required global
    68 variables.  We have made every attempt to eliminate these in the interest of
    69 simplicity.
    7054
    7155Board Initialization
     
    184168routine.  In case of errors, the initialization should be terminated via
    185169``bsp_fatal()``.
    186 
    187 Device Driver Initialization
    188 ----------------------------
    189 
    190 At this point in the initialization sequence, the initialization routines for
    191 all of the device drivers specified in the Device Driver Table are invoked.
    192 The initialization routines are invoked in the order they appear in the Device
    193 Driver Table.
    194 
    195 The Driver Address Table is part of the RTEMS Configuration Table. It defines
    196 device drivers entry points (initialization, open, close, read, write, and
    197 control). For more information about this table, please refer to the
    198 *Configuring a System* chapter in the *RTEMS Application C User's Guide*.
    199 
    200 The RTEMS initialization procedure calls the initialization function for every
    201 driver defined in the RTEMS Configuration Table (this allows one to include
    202 only the drivers needed by the application).
    203 
    204 All these primitives have a major and a minor number as arguments:
    205 
    206 - the major number refers to the driver type,
    207 
    208 - the minor number is used to control two peripherals with the same driver (for
    209   instance, we define only one major number for the serial driver, but two
    210   minor numbers for channel A and B if there are two channels in the UART).
    211 
    212 The Interrupt Vector Table
    213 ==========================
    214 
    215 The Interrupt Vector Table is called different things on different processor
    216 families but the basic functionality is the same.  Each entry in the Table
    217 corresponds to the handler routine for a particular interrupt source.  When an
    218 interrupt from that source occurs, the specified handler routine is invoked.
    219 Some context information is saved by the processor automatically when this
    220 happens.  RTEMS saves enough context information so that an interrupt service
    221 routine can be implemented in a high level language.
    222 
    223 On some processors, the Interrupt Vector Table is at a fixed address.  If this
    224 address is in RAM, then usually the BSP only has to initialize it to contain
    225 pointers to default handlers.  If the table is in ROM, then the application
    226 developer will have to take special steps to fill in the table.
    227 
    228 If the base address of the Interrupt Vector Table can be dynamically changed to
    229 an arbitrary address, then the RTEMS port to that processor family will usually
    230 allocate its own table and install it.  For example, on some members of the
    231 Motorola MC68xxx family, the Vector Base Register (``vbr``) contains this base
    232 address.
    233 
    234 Interrupt Vector Table on the gen68340 BSP
    235 ------------------------------------------
    236 
    237 The gen68340 BSP provides a default Interrupt Vector Table in the file
    238 ``$BSP_ROOT/start340/start340.s``.  After the ``entry`` label is the definition
    239 of space reserved for the table of interrupts vectors.  This space is assigned
    240 the symbolic name of ``__uhoh`` in the ``gen68340`` BSP.
    241 
    242 At ``__uhoh`` label is the default interrupt handler routine. This routine is
    243 only called when an unexpected interrupts is raised.  One can add their own
    244 routine there (in that case there's a call to a routine -
    245 $BSP_ROOT/startup/dumpanic.c - that prints which address caused the interrupt
    246 and the contents of the registers, stack, etc.), but this should not return.
    247 
    248 Chip Select Initialization
    249 ==========================
    250 
    251 When the microprocessor accesses a memory area, address decoding is handled by
    252 an address decoder, so that the microprocessor knows which memory chip(s) to
    253 access.  The following figure illustrates this:
    254 
    255 .. code-block:: c
    256 
    257                 +-------------------+
    258     ------------|                   |
    259     ------------|                   |------------
    260     ------------|      Address      |------------
    261     ------------|      Decoder      |------------
    262     ------------|                   |------------
    263     ------------|                   |
    264                 +-------------------+
    265     CPU Bus                            Chip Select
    266 
    267 The Chip Select registers must be programmed such that they match the
    268 ``linkcmds`` settings. In the gen68340 BSP, ROM and RAM addresses can be found
    269 in both the ``linkcmds`` and initialization code, but this is not a great way
    270 to do this.  It is better to define addresses in the linker script.
    271 
    272 Integrated Processor Registers Initialization
    273 =============================================
    274 
    275 The CPUs used in many embedded systems are highly complex devices with multiple
    276 peripherals on the CPU itself.  For these devices, there are always some
    277 specific integrated processor registers that must be initialized.  Refer to the
    278 processors' manuals for details on these registers and be VERY careful
    279 programming them.
    280 
    281 Data Section Recopy
    282 ===================
    283 
    284 The next initialization part can be found in
    285 ``$BSP340_ROOT/start340/init68340.c``. First the Interrupt Vector Table is
    286 copied into RAM, then the data section recopy is initiated
    287 (``_CopyDataClearBSSAndStart`` in ``$BSP340_ROOT/start340/startfor340only.s``).
    288 
    289 This code performs the following actions:
    290 
    291 - copies the .data section from ROM to its location reserved in RAM (see
    292   :ref:`Initialized Data` for more details about this copy),
    293 
    294 - clear ``.bss`` section (all the non-initialized data will take value 0).
    295 
    296 The RTEMS Configuration Table
    297 =============================
    298 
    299 The RTEMS configuration table contains the maximum number of objects RTEMS can
    300 handle during the application (e.g. maximum number of tasks, semaphores,
    301 etc.). It's used to allocate the size for the RTEMS inner data structures.
    302 
    303 The RTEMS configuration table is application dependent, which means that one
    304 has to provide one per application. It is usually defined by defining macros
    305 and including the header file ``<rtems/confdefs.h>``.  In simple applications
    306 such as the tests provided with RTEMS, it is commonly found in the main module
    307 of the application.  For more complex applications, it may be in a file by
    308 itself.
    309 
    310 The header file ``<rtems/confdefs.h>`` defines a constant table named
    311 ``Configuration``.  With RTEMS 4.8 and older, it was accepted practice for the
    312 BSP to copy this table into a modifiable copy named ``BSP_Configuration``.
    313 This copy of the table was modified to define the base address of the RTEMS
    314 Executive Workspace as well as to reflect any BSP and device driver
    315 requirements not automatically handled by the application.  In 4.9 and newer,
    316 we have eliminated the BSP copies of the configuration tables and are making
    317 efforts to make the configuration information generated by
    318 ``<rtems/confdefs.h>`` constant and read only.
    319 
    320 For more information on the RTEMS Configuration Table, refer to the *RTEMS
    321 Application C User's Guide*.
Note: See TracChangeset for help on using the changeset viewer.