5. Initialization Code

Warning

This chapter contains outdated and confusing information.

5.1. 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.

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 contained under the start directory in the BSP source directory. The BSP source code for these BSPs is in the following directories:

bsps/m68k/gen68340
bsps/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.

../../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.

5.2. 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.

5.3. 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 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 routines invoked during this will be discussed and their location in the RTEMS source tree pointed out as we discuss each.

5.3.1. 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:

  • initializing the stack
  • zeroing out the uninitialized data section .bss
  • disabling external interrupts
  • 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 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.

5.3.2. 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 bsps/shared/start/bootcard.c file.

The boot_card() routine performs the following functions:

  • It disables processor interrupts.
  • It sets the command line argument variables for later use by the application.
  • It invokes the routine rtems_initialize_executive() which never returns. This routine will perform the system initialization through a linker set. The important BSP-specific steps are outlined below.
  • Initialization of the RTEMS Workspace and the C Program Heap. Usually the default implementation in bsps/shared/start/bspgetworkarea-default.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/bootcard.h>.
  • Invocation of 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.
  • Specific initialization steps can be registered via the RTEMS_SYSINIT_ITEM() provided by #include <rtems/sysinit.h>.

5.3.3. bsp_work_area_initialize() - BSP Specific Work Area Initialization

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 bsps/shared/start/bspgetworkarea-default.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/bootcard.h>.

5.3.4. 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 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 found in the file bsps/${RTEMS_CPU}/${RTEMS_BSP}/start.c. 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().

5.3.5. 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).

5.4. 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.

5.4.1. 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.

5.5. 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:

            +-------------------+
------------|                   |
------------|                   |------------
------------|      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.

5.6. 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.

5.7. 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 Chapter 3 Section 5 - Initialized Data for more details about this copy),
  • clear .bss section (all the non-initialized data will take value 0).

5.8. 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.