BSP (Board Support Package) is low-level software that supports an OS for a specific board/processor and is sandwiched between the hardware and OS (and BSP does a lot more things also that we would discuss in time). Since a BSP is particularly targeted for a specific CPU/board, there exist many a variants. But typically a BSP consists of the following:
1> Boot Loader
2> OS Adaptation Layer (this is my term; most people call it as OEM Adaptation Layer) or OAL
3> Device Drivers (Kernel level)
4> Image configuration files
A system can be broadly viewed like this at the low-level:
1> Boot Loader:
The main purpose of a boot-loader is to initialize the target device(including SRAM, clocks, PLLs etc), place the run-time image into memory and then boot the run-time image on the target device (i.e. jump to the OS startup routine). An assembly file called boot.S contains a minimal set of code for transferring control from the processor’s reset location to the start of the application (i.e. the run-time image).
During the linking process, a jump instruction is mapped to the reset vector (i.e. the processor’s reset location, i.e. the location at which the control goes first once the processor is powered ON) with a label that marks the run-time image’s entry point. The reset location is board dependent and is fixed for a particular processor. This jump instruction is the first boot instruction that gets executed.
The boot-loader can obtain the run-time image in different ways, including loading it over a cabled connection (Ethernet, USB, serial COM ports etc), or from local storage device (flash/hard-disk). A boot-loader should reside in a non-volatile memory such as flash.
2> OAL:
OAL is linked with kernel libraries to create kernel executable file. The OAL facilitates communication between OS and the target device and includes code to handle interrupts, timers, power management, bus abstraction, generic I/O control codes (IOCTLs), and so on. The OAL is physically a part of the kernel image.
Creating the OAL is one of the more complex tasks in the process of getting an OS to run on a new hardware platform. In general, the easiest way to create an OAL is to copy the OAL implementation from a working OS design, and then modify it to suit the specific requirements of your hardware platform (ctrl-c + ctrl-v!! J).
3> Device Driver:
Device drivers in an embedded system is too a huge topic to cover at this level.
But remember that when you execute a device driver in kernel mode (or any code for that matter in kernel mode), you must have access to the physical memory, and the BSP should account for that (by virtual-physical memory mapping).
4> Image Configuration files:
These are mostly header files, and contain all the important board-specific parameters and data that BSP might require. These include:
(i) Initial address space or kernel space: The exact interpretation of this field is architecture-dependent.
a. In some cases, it describes the address space which must be established in the hardware when entering the microkernel.
b. In other cases, it describes the address space which must be established by the microkernel's memory management module.
c. Some architecture does not require it at all (for example when there is no MMU).
(ii) Banks: System image memory bank (number of banks, size of each bank, starting address within the initial address space etc)
(iii) Binaries: Points to the absolute executable binary involved in the system, such as bootconf (the main role of bootconf is to hold the structure containing the configuration parameters), microkernel, or a driver.
(iv) Heap and Stack: You people know more about it than me!
(v) There are a lot other parameters which get changed dynamically,.
