From 6d7a4d2ee7053488f625faccc8bd4dc4d25d6460 Mon Sep 17 00:00:00 2001 From: Chris Johns Date: Fri, 17 Jun 2016 15:05:41 +1000 Subject: Update the BSP howto. Closes #2590. --- bsp_howto/initilization_code.rst | 441 ++++++++++++++++++++------------------- 1 file changed, 222 insertions(+), 219 deletions(-) (limited to 'bsp_howto/initilization_code.rst') diff --git a/bsp_howto/initilization_code.rst b/bsp_howto/initilization_code.rst index e4482f4..516362f 100644 --- a/bsp_howto/initilization_code.rst +++ b/bsp_howto/initilization_code.rst @@ -1,5 +1,9 @@ .. comment SPDX-License-Identifier: CC-BY-SA-4.0 +.. COMMENT: COPYRIGHT (c) 1988-2008. +.. COMMENT: On-Line Applications Research Corporation (OAR). +.. COMMENT: All rights reserved. + Initialization Code ################### @@ -7,87 +11,85 @@ Introduction ============ The initialization code is the first piece of code executed when there's a -reset/reboot. Its purpose is to initialize the board for the application. -This chapter contains a narrative description of the initialization -process followed by a description of each of the files and routines -commonly found in the BSP related to initialization. The remainder of -this chapter covers special issues which require attention such -as interrupt vector table and chip select initialization. +reset/reboot. Its purpose is to initialize the board for the application. This +chapter contains a narrative description of the initialization process followed +by a description of each of the files and routines commonly found in the BSP +related to initialization. The remainder of this chapter covers special issues +which require attention such as interrupt vector table and chip select +initialization. Most of the examples in this chapter will be based on the SPARC/ERC32 and -m68k/gen68340 BSP initialization code. Like most BSPs, the initialization -for these BSP is divided into two subdirectories under the BSP source -directory. The BSP source code for these BSPs is in the following -directories: +m68k/gen68340 BSP initialization code. Like most BSPs, the initialization for +these BSP is divided into two subdirectories under the BSP source directory. +The BSP source code for these BSPs is in the following directories: + .. code:: c c/src/lib/libbsp/m68k/gen68340 c/src/lib/libbsp/sparc/erc32 -Both BSPs contain startup code written in assembly language and C. -The gen68340 BSP has its early initialization start code in the``start340`` subdirectory and its C startup code in the ``startup`` -directory. In the ``start340`` directory are two source files. -The file ``startfor340only.s`` is the simpler of these files as it only -has initialization code for a MC68340 board. The file ``start340.s`` -contains initialization for a 68349 based board as well. - -Similarly, the ERC32 BSP has startup code written in assembly language -and C. However, this BSP shares this code with other SPARC BSPs. -Thus the ``Makefile.am`` explicitly references the following files -for this functionality. +Both BSPs contain startup code written in assembly language and C. The +gen68340 BSP has its early initialization start code in the ``start340`` +subdirectory and its C startup code in the ``startup`` directory. In the +``start340`` directory are two source files. The file ``startfor340only.s`` is +the simpler of these files as it only has initialization code for a MC68340 +board. The file ``start340.s`` contains initialization for a 68349 based board +as well. + +Similarly, the ERC32 BSP has startup code written in assembly language and C. +However, this BSP shares this code with other SPARC BSPs. Thus the +``Makefile.am`` explicitly references the following files for this +functionality. + .. code:: c ../../sparc/shared/start.S -*NOTE:* In most BSPs, the directory named ``start340`` in the -gen68340 BSP would be simply named ``start`` or start followed by a -BSP designation. +.. note:: + + 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. +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 ```` during debug but -should not explicitly reference it in the source code. There are helper -routines provided by RTEMS to access individual fields. +The BSP author probably should be aware of the ``Configuration`` Table +structure generated by ```` 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. +variables. We have made every attempt to eliminate these in the interest of +simplicity. Board Initialization ==================== -This section describes the steps an application goes through from the -time the first BSP code is executed until the first application task -executes. The following figure illustrates the program flow during -this sequence: +This section describes the steps an application goes through from the time the +first BSP code is executed until the first application task executes. -IMAGE NOT AVAILABLE IN ASCII VERSION +The initialization flows from assembly language start code to the shared +``bootcard.c`` framework then through the C Library, RTEMS, device driver +initialization phases, and the context switch to the first application task. +After this, the application executes until it calls ``exit``, +``rtems_shutdown_executive``, or some other normal termination initiating +routine and a fatal system state is reached. The optional +``bsp_fatal_extension`` initial extension can perform BSP specific system +termination. -The above figure illustrates the flow from assembly language start code -to the shared ``bootcard.c`` framework then through the C Library, -RTEMS, device driver initialization phases, and the context switch -to the first application task. After this, the application executes -until it calls ``exit``, ``rtems_shutdown_executive``, or some -other normal termination initiating routine and a fatal system state is -reached. The optional ``bsp_fatal_extension`` initial extension can perform -BSP specific system termination. - -The routines invoked during this will be discussed and their location -in the RTEMS source tree pointed out as we discuss each. +The routines invoked during this will be discussed and their location in the +RTEMS source tree pointed out as we discuss each. Start Code - Assembly Language Initialization --------------------------------------------- -The assembly language code in the directory ``start`` is the first part -of the application to execute. It is responsible for initializing the -processor and board enough to execute the rest of the BSP. This includes: +The assembly language code in the directory ``start`` is the first part of the +application to execute. It is responsible for initializing the processor and +board enough to execute the rest of the BSP. This includes: - initializing the stack @@ -97,29 +99,29 @@ processor and board enough to execute the rest of the BSP. This includes: - copy the initialized data from ROM to RAM -The general rule of thumb is that the start code in assembly should -do the minimum necessary to allow C code to execute to complete the -initialization sequence. +The general rule of thumb is that the start code in assembly should do the +minimum necessary to allow C code to execute to complete the initialization +sequence. -The initial assembly language start code completes its execution by -invoking the shared routine ``boot_card()``. +The initial assembly language start code completes its execution by invoking +the shared routine ``boot_card()``. -The label (symbolic name) associated with the starting address of the -program is typically called ``start``. The start object file is the -first object file linked into the program image so it is ensured that -the start code is at offset 0 in the ``.text`` section. It is the -responsibility of the linker script in conjunction with the compiler -specifications file to put the start code in the correct location in -the application image. +The label (symbolic name) associated with the starting address of the program +is typically called ``start``. The start object file is the first object file +linked into the program image so it is ensured that the start code is at offset +0 in the ``.text`` section. It is the responsibility of the linker script in +conjunction with the compiler specifications file to put the start code in the +correct location in the application image. boot_card() - Boot the Card --------------------------- -The ``boot_card()`` is the first C code invoked. This file is the -core component in the RTEMS BSP Initialization Framework and provides -the proper sequencing of initialization steps for the BSP, RTEMS and -device drivers. All BSPs use the same shared version of ``boot_card()`` -which is located in the following file: +The ``boot_card()`` is the first C code invoked. This file is the core +component in the RTEMS BSP Initialization Framework and provides the proper +sequencing of initialization steps for the BSP, RTEMS and device drivers. All +BSPs use the same shared version of ``boot_card()`` which is located in the +following file: + .. code:: c c/src/lib/libbsp/shared/bootcard.c @@ -131,33 +133,38 @@ The ``boot_card()`` routine performs the following functions: - It sets the command line argument variables for later use by the application. -- It invokes the BSP specific routine ``bsp_work_area_initialize()`` - which is supposed to initialize the RTEMS Workspace and the C Program Heap. - Usually the default implementation in``c/src/lib/libbsp/shared/bspgetworkarea.c`` should be sufficient. Custom - implementations can use ``bsp_work_area_initialize_default()`` or``bsp_work_area_initialize_with_table()`` available as inline functions from``#include ``. +- It invokes the BSP specific routine ``bsp_work_area_initialize()`` which is + supposed to initialize the RTEMS Workspace and the C Program Heap. Usually + the default implementation in ``c/src/lib/libbsp/shared/bspgetworkarea.c`` + should be sufficient. Custom implementations can use + ``bsp_work_area_initialize_default()`` or + ``bsp_work_area_initialize_with_table()`` available as inline functions + from``#include ``. -- It invokes the BSP specific routine ``bsp_start()`` which is - written in C and thus able to perform more advanced initialization. - Often MMU, bus and interrupt controller initialization occurs here. Since the - RTEMS Workspace and the C Program Heap was already initialized by``bsp_work_area_initialize()``, this routine may use ``malloc()``, etc. +- It invokes the BSP specific routine ``bsp_start()`` which is written in C and + thus able to perform more advanced initialization. Often MMU, bus and + interrupt controller initialization occurs here. Since the RTEMS Workspace + and the C Program Heap was already initialized by + ``bsp_work_area_initialize()``, this routine may use ``malloc()``, etc. -- It invokes the RTEMS directive``rtems_initialize_data_structures()`` to initialize the RTEMS - executive to a state where objects can be created but tasking is not - enabled. +- It invokes the RTEMS directive ``rtems_initialize_data_structures()`` to + initialize the RTEMS executive to a state where objects can be created but + tasking is not enabled. -- It invokes the BSP specific routine ``bsp_libc_init()`` to initialize - the C Library. Usually the default implementation in``c/src/lib/libbsp/shared/bsplibc.c`` should be sufficient. +- It invokes the BSP specific routine ``bsp_libc_init()`` to initialize the C + Library. Usually the default implementation in + ``c/src/lib/libbsp/shared/bsplibc.c`` should be sufficient. -- It invokes the RTEMS directive``rtems_initialize_before_drivers()`` to initialize the MPCI Server - thread in a multiprocessor configuration and execute API specific - extensions. +- It invokes the RTEMS directive ``rtems_initialize_before_drivers()`` to + initialize the MPCI Server thread in a multiprocessor configuration and + execute API specific extensions. -- It invokes the BSP specific routine ``bsp_predriver_hook``. For - most BSPs, the implementation of this routine does nothing. +- It invokes the BSP specific routine ``bsp_predriver_hook``. For most BSPs, + the implementation of this routine does nothing. -- It invokes the RTEMS directive``rtems_initialize_device_drivers()`` to initialize the statically - configured set of device drivers in the order they were specified in - the Configuration Table. +- It invokes the RTEMS directive ``rtems_initialize_device_drivers()`` to + initialize the statically configured set of device drivers in the order they + were specified in the Configuration Table. - It invokes the BSP specific routine ``bsp_postdriver_hook``. For most BSPs, the implementation of this routine does nothing. However, some @@ -165,20 +172,20 @@ The ``boot_card()`` routine performs the following functions: this point in the initialization sequence. This is the last opportunity for the BSP to insert BSP specific code into the initialization sequence. -- It invokes the RTEMS directive``rtems_initialize_start_multitasking()`` - which initiates multitasking and performs a context switch to the - first user application task and may enable interrupts as a side-effect of - that context switch. The context switch saves the executing context. The - application runs now. The directive rtems_shutdown_executive() will return - to the saved context. The exit() function will use this directive. - After a return to the saved context a fatal system state is reached. The - fatal source is RTEMS_FATAL_SOURCE_EXIT with a fatal code set to the value - passed to rtems_shutdown_executive(). - The enabling of interrupts during the first context switch is often the source - for fatal errors during BSP development because the BSP did not clear and/or - disable all interrupt sources and a spurious interrupt will occur. - When in the context of the first task but before its body has been - entered, any C++ Global Constructors will be invoked. +- It invokes the RTEMS directive ``rtems_initialize_start_multitasking()`` + which initiates multitasking and performs a context switch to the first user + application task and may enable interrupts as a side-effect of that context + switch. The context switch saves the executing context. The application + runs now. The directive ``rtems_shutdown_executive()`` will return to the + saved context. The ``exit()`` function will use this directive. After a + return to the saved context a fatal system state is reached. The fatal + source is ``RTEMS_FATAL_SOURCE_EXIT`` with a fatal code set to the value + passed to rtems_shutdown_executive(). The enabling of interrupts during the + first context switch is often the source for fatal errors during BSP + development because the BSP did not clear and/or disable all interrupt + sources and a spurious interrupt will occur. When in the context of the + first task but before its body has been entered, any C++ Global Constructors + will be invoked. That's it. We just went through the entire sequence. @@ -189,15 +196,18 @@ This is the first BSP specific C routine to execute during system initialization. It must initialize the support for allocating memory from the C Program Heap and RTEMS Workspace commonly referred to as the work areas. Many BSPs place the work areas at the end of RAM although this is certainly not -a requirement. Usually the default implementation in:file:`c/src/lib/libbsp/shared/bspgetworkarea.c` should be sufficient. Custom -implementations can use ``bsp_work_area_initialize_default()`` or``bsp_work_area_initialize_with_table()`` available as inline functions from``#include ``. +a requirement. Usually the default implementation +in:file:`c/src/lib/libbsp/shared/bspgetworkarea.c` should be sufficient. +Custom implementations can use ``bsp_work_area_initialize_default()`` +or``bsp_work_area_initialize_with_table()`` available as inline functions from +``#include ``. bsp_start() - BSP Specific Initialization ----------------------------------------- This is the second BSP specific C routine to execute during system -initialization. It is called right after ``bsp_work_area_initialize()``. -The ``bsp_start()`` routine often performs required fundamental hardware +initialization. It is called right after ``bsp_work_area_initialize()``. The +``bsp_start()`` routine often performs required fundamental hardware initialization such as setting bus controller registers that do not have a direct impact on whether or not C code can execute. The interrupt controllers are usually initialized here. The source code for this routine is usually @@ -206,52 +216,56 @@ It is not allowed to create any operating system objects, e.g. RTEMS semaphores. After completing execution, this routine returns to the ``boot_card()`` -routine. In case of errors, the initialization should be terminated via``bsp_fatal()``. +routine. In case of errors, the initialization should be terminated via +``bsp_fatal()``. bsp_predriver_hook() - BSP Specific Predriver Hook -------------------------------------------------- -The ``bsp_predriver_hook()`` method is the BSP specific routine that is -invoked immediately before the the device drivers are initialized. RTEMS -initialization is complete but interrupts and tasking are disabled. +The ``bsp_predriver_hook()`` method is the BSP specific routine that is invoked +immediately before the the device drivers are initialized. RTEMS initialization +is complete but interrupts and tasking are disabled. -The BSP may use the shared version of this routine which is empty. -Most BSPs do not provide a specific implementation of this callback. +The BSP may use the shared version of this routine which is empty. Most BSPs +do not provide a specific implementation of this callback. 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. +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 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). +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 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). RTEMS Postdriver Callback ------------------------- -The ``bsp_postdriver_hook()`` BSP specific routine is invoked -immediately after the the device drivers and MPCI are initialized. -Interrupts and tasking are disabled. +The ``bsp_postdriver_hook()`` BSP specific routine is invoked immediately after +the the device drivers and MPCI are initialized. Interrupts and tasking are +disabled. + +Most BSPs use the shared implementation of this routine which is responsible +for opening the device ``/dev/console`` for standard input, output and error if +the application has configured the Console Device Driver. This file is located +at: -Most BSPs use the shared implementation of this routine which is responsible for opening the device ``/dev/console`` for standard input, output and error if the application has configured the Console Device Driver. This file is located at: .. code:: c c/src/lib/libbsp/shared/bsppost.c @@ -259,121 +273,110 @@ Most BSPs use the shared implementation of this routine which is responsible for 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. +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. +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. +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: +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:: c +.. code:: +-------------------+ ------------| | - ------------| \|------------ - ------------| Address \|------------ - ------------| Decoder \|------------ - ------------| \|------------ + ------------| |------------ + ------------| 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. +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. +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``). +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 `Initialized Data`_ for more details about this copy), +- copies the .data section from ROM to its location reserved in RAM (see + `Initialized Data`_ for more details about this copy), -- clear ``.bss`` section (all the non-initialized - data will take value 0). +- 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 ````. 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 ```` 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 ```` constant and read only. - -For more information on the RTEMS Configuration Table, refer to the*RTEMS Application C User's Guide*. - -.. COMMENT: COPYRIGHT (c) 1988-2008. - -.. COMMENT: On-Line Applications Research Corporation (OAR). - -.. COMMENT: All rights reserved. - +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 ````. 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 ```` 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 +```` constant and read only. + +For more information on the RTEMS Configuration Table, refer to the *RTEMS +Application C User's Guide*. -- cgit v1.2.3