Changeset 928bf73 in rtems-docs

Feb 4, 2020, 6:52:42 AM (5 months ago)
Sebastian Huber <sebastian.huber@…>
5, master
Sebastian Huber <sebastian.huber@…> (02/04/20 06:52:42)
Sebastian Huber <sebastian.huber@…> (02/04/20 08:20:12)

bsp-howto: Remove obsolete information

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

Update #2852.

1 edited


  • 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.
    55 Required Global Variables
    56 =========================
    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.
    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.
    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.
    7155Board Initialization
    184168routine.  In case of errors, the initialization should be terminated via
    187 Device Driver Initialization
    188 ----------------------------
    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.
    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*.
    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).
    204 All these primitives have a major and a minor number as arguments:
    206 - the major number refers to the driver type,
    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).
    212 The Interrupt Vector Table
    213 ==========================
    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.
    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.
    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.
    234 Interrupt Vector Table on the gen68340 BSP
    235 ------------------------------------------
    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.
    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.
    248 Chip Select Initialization
    249 ==========================
    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:
    255 .. code-block:: c
    257                 +-------------------+
    258     ------------|                   |
    259     ------------|                   |------------
    260     ------------|      Address      |------------
    261     ------------|      Decoder      |------------
    262     ------------|                   |------------
    263     ------------|                   |
    264                 +-------------------+
    265     CPU Bus                            Chip Select
    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.
    272 Integrated Processor Registers Initialization
    273 =============================================
    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.
    281 Data Section Recopy
    282 ===================
    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``).
    289 This code performs the following actions:
    291 - copies the .data section from ROM to its location reserved in RAM (see
    292   :ref:`Initialized Data` for more details about this copy),
    294 - clear ``.bss`` section (all the non-initialized data will take value 0).
    296 The RTEMS Configuration Table
    297 =============================
    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.
    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.
    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.
    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.