RTEMS 4.9.3 On-Line Library

Initialization Code boot_card() - Boot the Card

BSP and Device Driver Development Guide

7.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 following file:

c/src/lib/libbsp/shared/bootcard.c

The boot_card() routine performs the following functions:

It disables processor interrupts.
It sets the global program name and command line argument variables for later use by the application.
If the macro is BSP_BOOTCARD_HANDLES_RAM_ALLOCATION is defined, it will invoke the BSP specific bsp_get_work_area function to obtain information on the amount and location of BSP RAM that is available to be allocated to the C Program Heap and RTEMS Workspace. If the amount of memory available for the RTEMS Workspace is less than that required by the application (e.g. rtems_configuration_get_work_space_size(), then a message is printed using printk, bsp_cleanup is invoked, and -1 is return to the assembly language start code. BSPs which use this memory allocation functionality in bootcard.c must invoke the RTEMS specific autoconf macro RTEMS_BSP_BOOTCARD_HANDLES_RAM_ALLOCATION in the BSP's configure.ac file.
It invokes the BSP specific routine bsp_start() which is written in C and thus able to perform more advanced initialization. Often MMU and bus initialization occurs here.
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.
If the macro is BSP_BOOTCARD_HANDLES_RAM_ALLOCATION is defined, it will calculate the memory available for the C Program Heap and invoke the initialization routine for the C Library with this information.
It invokes the BSP specific routine bsp_pretasking_hook. On most BSPs which utilize the framework, this routine does nothing.
If RTEMS_DEBUG is enabled, then the RTEMS debug mask level is inialized appropriately.
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. However, on some BSPs, required subsystems which utilize the C Library (e.g. malloc in particular) may be initialized at this point.
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 BSPs use this hook and perform some initialization which must be done at 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 starts multitasking and context switches to the first task. boot_card() will not return until the application is shutdown. As part of this sequence the following actions occur:
- RTEMS will context switch to the first application task. As a side-effect of this context switch, processor interrupts will be enabled. This is often the source of a fatal error 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.
Finally after the application shutsdown RTEMS and control is return to boot_card() from RTEMS, it invokes the BSP specific routine bsp_cleanup() to perform any necessary board specific shutdown actions.

That's it. We just went through the entire sequence.

BSP and Device Driver Development Guide