bsp-howto: Remove obsolete information

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

Update #2852.

bsp-howto/initilization_code.rst

@@ -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*.