A Board Support Package, or BSP, is a software layer for a specific computer board or embedded system. It initializes the hardware and provides interfaces that allow an operating system, middleware, or application code to access the processor, memory, and peripherals.
Content
What does Board Support Package mean?
A Board Support Package bundles board-specific code. This code describes how a specific hardware design is started, configured, and addressed. This includes drivers, initialization routines, and often also components for memory management, power management, and the boot process.
The term is primarily used with embedded systems. There, the software is closely linked to the processor, memory components, interfaces, and peripheral devices of the respective board. A BSP separates these hardware dependencies from higher software layers.
How does a Board Support Package work?
When turning on a board, a Bootloader or a comparable startup code performs basic steps. It prepares for the launch of further software and can load an operating system or a software image. Afterwards, initialization routines ensure that memory areas, clock sources, and peripherals are brought into a defined state.
Device drivers then establish the connection between software and hardware functions. They allow access to components such as GPIO, UART, Timer, ADC, memory, or communication interfaces. In architecturally defined BSPs, this access occurs through defined APIs. This regulates which functions are called, which parameters are allowed, and what behavior the upper software layer can expect.
A BSP can be on a hardware abstraction Layer set up. The HAL usually provides manufacturer-specific access to microcontroller peripherals. The BSP then defines how these accesses are used and limited within the project. This keeps manufacturer-specific code in a designated layer.
A Board Support Package is used in embedded systems development.
Board Support Packages are used in embedded systems where software is intended to run on a specific hardware platform. This includes systems with an operating system, real-time operating system, or other system software.
Typical use cases include:
- Initializing a specific board at system startup
- Connection of processor, memory, and peripherals to an operating system
- Providing drivers for board-specific hardware
- Encapsulation of microcontroller or processor dependencies
- Migrating an application to another board with a similar functional structure.
- Building reusable interfaces for multiple hardware variants
For Linux-based embedded systems, a BSP can be part of a build and integration environment. The Yocto Project provides templates, tools, and methods for creating customized Linux systems for embedded products.
Manufacturers like Toradex, Dry or PHYTEC provide Linux, Android, and Yocto-based BSPs for microprocessor-based SoMs.
Properties
A BSP is tied to a specific board. It contains knowledge about the existing hardware and its startup conditions. This includes the processor, memory, peripheral devices, interfaces, and board-specific wiring.
The components of a BSP often include:
- Device drivers for hardware components
- Bootloader or startup code
- Initialization code for memory and peripherals
- Memory management code
- Energy management code
- Communication protocols or libraries as far as they are needed for hardware connection
- APIs for access from higher software layers
The development of a BSP requires knowledge of hardware and operating systems. Developers must understand the target platform's architecture and the requirements of the overlying software regarding initialization, drivers, and runtime behavior. After implementation, the BSP is tested on the target hardware. Different hardware configurations and operating system versions can be considered during this process.
A typical development environment for a BSP includes a cross-compiler, a debugger, build tools, and often an integrated development environment. The cross-compiler generates code for the target platform. The debugger supports debugging the BSP code on or for the target hardware.
Demarcation from related terms
A BSP is not identical to a single Device driver. A driver provides access to a specific hardware component. A BSP includes several board-related components and describes the startup and integration of the hardware platform into the software architecture.
A BSP is also not the same as a HAL. A Hardware Abstraction Layer usually provides basic, often manufacturer-specific access to microcontroller or processor peripherals. A BSP can use this HAL but restricts access on a project-specific basis and provides APIs that are used by the application, middleware, or operating system.
A bootloader is also just a sub-area. It starts up when powered on and loads further software components. The BSP can contain a bootloader or work with it, but additionally includes drivers, initialization, and board-specific interfaces.
An operating system is the runtime environment for processes, threads, memory management, or device services. The BSP provides the board-specific foundation so that the operating system can use the hardware of the specific board.
Boundaries and typical misunderstandings
A BSP does not automatically make software independent of all hardware. It limits hardware dependencies to a specific layer. If applications access registers, HAL functions, or board-specific details directly, this separation is broken.
Another misunderstanding is equating a BSP with sample code from the manufacturer. Sample code can serve as a starting point, but it does not replace a defined interface, clear responsibilities, or validation on the target hardware.
A BSP is also not completely generic. It consciously contains board-specific information. If the microcontroller or board is changed, parts of the BSP may need to be rewritten. If the APIs remain stable, application code can remain unchanged, provided the new hardware offers the same required functionalities.
The quality of an SDK depends on tests on the target platform. Without validation, initialization errors, anomalous peripheral behavior, or problems due to other operating system versions cannot be reliably ruled out.
