rtems/rtems-docs
1
0
Fork 0
mirror of https://git.rtems.org/rtems-docs/ synced 2025-05-17 16:02:01 +08:00
Code Issues Packages Projects Releases Wiki Activity

bsp-howto: Remove obsolete information

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

Update #2852.
This commit is contained in:
Sebastian Huber 2020-02-04 07:52:42 +01:00
parent 813ada57f7
commit 928bf73b9b
1 changed files with 0 additions and 152 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

152
bsp-howto/initilization_code.rst
View File

@ -52,22 +52,6 @@ functionality.
In most BSPs, the directory named ``start340`` in the gen68340 BSP would be
simply named ``start`` or start followed by a BSP designation.
Required Global Variables
=========================
Although not strictly part of initialization, there are a few global variables
assumed to exist by reusable device drivers. These global variables should
only defined by the BSP when using one of these device drivers.
The BSP author probably should be aware of the ``Configuration`` Table
structure generated by ``<rtems/confdefs.h>`` during debug but should not
explicitly reference it in the source code. There are helper routines provided
by RTEMS to access individual fields.
In older RTEMS versions, the BSP included a number of required global
variables. We have made every attempt to eliminate these in the interest of
simplicity.
Board Initialization
====================
@ -183,139 +167,3 @@ semaphores.
After completing execution, this routine returns to the ``boot_card()``
routine. In case of errors, the initialization should be terminated via
``bsp_fatal()``.
Device Driver Initialization
----------------------------
At this point in the initialization sequence, the initialization routines for
all of the device drivers specified in the Device Driver Table are invoked.
The initialization routines are invoked in the order they appear in the Device
Driver Table.
The Driver Address Table is part of the RTEMS Configuration Table. It defines
device drivers entry points (initialization, open, close, read, write, and
control). For more information about this table, please refer to the
*Configuring a System* chapter in the *RTEMS Application C User's Guide*.
The RTEMS initialization procedure calls the initialization function for every
driver defined in the RTEMS Configuration Table (this allows one to include
only the drivers needed by the application).
All these primitives have a major and a minor number as arguments:
- the major number refers to the driver type,
- the minor number is used to control two peripherals with the same driver (for
instance, we define only one major number for the serial driver, but two
minor numbers for channel A and B if there are two channels in the UART).
The Interrupt Vector Table
==========================
The Interrupt Vector Table is called different things on different processor
families but the basic functionality is the same. Each entry in the Table
corresponds to the handler routine for a particular interrupt source. When an
interrupt from that source occurs, the specified handler routine is invoked.
Some context information is saved by the processor automatically when this
happens. RTEMS saves enough context information so that an interrupt service
routine can be implemented in a high level language.
On some processors, the Interrupt Vector Table is at a fixed address. If this
address is in RAM, then usually the BSP only has to initialize it to contain
pointers to default handlers. If the table is in ROM, then the application
developer will have to take special steps to fill in the table.
If the base address of the Interrupt Vector Table can be dynamically changed to
an arbitrary address, then the RTEMS port to that processor family will usually
allocate its own table and install it. For example, on some members of the
Motorola MC68xxx family, the Vector Base Register (``vbr``) contains this base
address.
Interrupt Vector Table on the gen68340 BSP
------------------------------------------
The gen68340 BSP provides a default Interrupt Vector Table in the file
``$BSP_ROOT/start340/start340.s``. After the ``entry`` label is the definition
of space reserved for the table of interrupts vectors. This space is assigned
the symbolic name of ``__uhoh`` in the ``gen68340`` BSP.
At ``__uhoh`` label is the default interrupt handler routine. This routine is
only called when an unexpected interrupts is raised. One can add their own
routine there (in that case there's a call to a routine -
$BSP_ROOT/startup/dumpanic.c - that prints which address caused the interrupt
and the contents of the registers, stack, etc.), but this should not return.
Chip Select Initialization
==========================
When the microprocessor accesses a memory area, address decoding is handled by
an address decoder, so that the microprocessor knows which memory chip(s) to
access. The following figure illustrates this:
.. code-block:: c
+-------------------+
------------| |
------------| |------------
------------| Address |------------
------------| Decoder |------------
------------| |------------
------------| |
+-------------------+
CPU Bus Chip Select
The Chip Select registers must be programmed such that they match the
``linkcmds`` settings. In the gen68340 BSP, ROM and RAM addresses can be found
in both the ``linkcmds`` and initialization code, but this is not a great way
to do this. It is better to define addresses in the linker script.
Integrated Processor Registers Initialization
=============================================
The CPUs used in many embedded systems are highly complex devices with multiple
peripherals on the CPU itself. For these devices, there are always some
specific integrated processor registers that must be initialized. Refer to the
processors' manuals for details on these registers and be VERY careful
programming them.
Data Section Recopy
===================
The next initialization part can be found in
``$BSP340_ROOT/start340/init68340.c``. First the Interrupt Vector Table is
copied into RAM, then the data section recopy is initiated
(``_CopyDataClearBSSAndStart`` in ``$BSP340_ROOT/start340/startfor340only.s``).
This code performs the following actions:
- copies the .data section from ROM to its location reserved in RAM (see
:ref:`Initialized Data` for more details about this copy),
- clear ``.bss`` section (all the non-initialized data will take value 0).
The RTEMS Configuration Table
=============================
The RTEMS configuration table contains the maximum number of objects RTEMS can
handle during the application (e.g. maximum number of tasks, semaphores,
etc.). It's used to allocate the size for the RTEMS inner data structures.
The RTEMS configuration table is application dependent, which means that one
has to provide one per application. It is usually defined by defining macros
and including the header file ``<rtems/confdefs.h>``. In simple applications
such as the tests provided with RTEMS, it is commonly found in the main module
of the application. For more complex applications, it may be in a file by
itself.
The header file ``<rtems/confdefs.h>`` defines a constant table named
``Configuration``. With RTEMS 4.8 and older, it was accepted practice for the
BSP to copy this table into a modifiable copy named ``BSP_Configuration``.
This copy of the table was modified to define the base address of the RTEMS
Executive Workspace as well as to reflect any BSP and device driver
requirements not automatically handled by the application. In 4.9 and newer,
we have eliminated the BSP copies of the configuration tables and are making
efforts to make the configuration information generated by
``<rtems/confdefs.h>`` constant and read only.
For more information on the RTEMS Configuration Table, refer to the *RTEMS
Application C User's Guide*.