BSP Development Process

Every board comes with a base BSP (Board Support Package) from the manufacturers. However, in most cases, different levels of customization must meet the strict application requirements in real-life scenarios. Thus implicitly demanding the development
of a custom BSP.

This article will cover the main aspects of the BSP development process when creating custom BSPs for embedded systems.

Main BSP Development Steps

The development process of a BSP starts with the hardware and the Operating System that is supposed to be used on the given embedded platform. In general, choosing a hardware platform depends on the application’s needs and the target OS that needs to run on it.

There are two main categories of the OS ecosystem for embedded applications: UNIX Like Operating systems and Real-Time Operating Systems. The BSP development process highly depends on the target OS. There are as well few main steps in the development process that are common for both types of operating systems:

Choosing the OS Open-Source vs Proprietary

The OS is chosen depending on specific requirements for the application at hand. This choice is motivated by considerations as varied as safety-relevant vs non-safety-relevant applications, required certifications for the system, real-time requirements, and application software stacks that need to run under the OS, etc.

Bootloader & Boot scheme Development

Irrespective of the chosen OS, the bootloader does the first initialization of the system. In general, depending on the chosen OS, a Bootloader will have a customization starting from scratch or from an Open-Source implementation. In addition to the development and configuration of the individual Bootloaders for each boot stage, it’s necessary to implement the boot scheme/strategy, such that the system can boot up according to strict application requirements and be in sync with other SoC or cores present on the same Board/SoC.

Hardware Abstraction

Depending on the chosen OS, there are different techniques to abstract/describe the hardware/SoC on which the OS is running, such that the kernel of the OS can work with an abstract description of the hardware components – peripherals CPU cores, hardware accelerators, interrupt lines, etc. For Unix Like Operating Systems such as VxWorks, Linux, etc. there is the tree structure data format – Device Tree. It describes the hardware in a binary blob-compilable format. Also, the Kernel loads it at boot time. Although not so popular in applications with RTOSs, Device Tree starts to gain popularity with Real-Time Operating Systems. Other common hardware abstraction methods for hardware in RTOS applications include writing standardized C routines that have good documentation.

The specification/documentation of the various APIs acts as a to-do list for developers that implement the hardware abstraction layers. We can use it later on, in the upper kernel layers/device drivers. Many silicon vendors implement a widespread specification is the Common Microcontroller Software Interface Standard (CMSIS).

Device Driver Development

After the bootloader and the low-level hardware abstractions are ready, the OS can start to boot on the custom platform. Now the Kernel customization development can start. New functionality is added in terms of device drivers such that the various OS software stacks can be reliably interfaced with the various hardware peripherals, on-chip hardware accelerators, etc. As well as customization for existing drivers, depending on the type of OS Opensource vs proprietary, the amount of work will be centered around customization of existing opensource drivers or development of new ones from scratch based on guidelines and sample drivers from the OS supplier.

OS Stacks Development & Integration

For the OS to be able to reliably provide the application services the needed functionalities in terms of hardware and software resources, various software stacks such as networking, USB, video, audio, etc. we need to integrate or further develop such that they met the requirements of the application at hand. Most OS’es, proprietary, and Open-Source have already well-tested standard software stacks that can provide required functionalities for the application layer. The only needs in terms of custom development are isolated customization and integration work, such that only the required components are integrated and properly configured according to the needs of the overall application.

Root File System Customization

Embedded applications rely in general on a whole suite of tools that are necessary along with them such that they can reliably provide the needed functionalities. Thus, is demanding that the rotfs have custom configuration in order to include the various packages that the application needs.

Testing

As any custom development, the developed BSP also needs testing and benchmarking according to the specific application KPIs. That way the overall software platform has a solid foundation on which it can function properly at the expected performance. To reliably perform all the tests, we need to set up the infrastructure in such a way that tests from unit to system test can be developed and integrated on a continuous integration pipeline.

Conclusion

In conclusion, the development of a custom Board Support Package is complex development work. It is highly dependent on the type of OS and the underlying characteristics of the hardware. Also, it depends on the application that will run on top of the OS. It dictates the features that need development at both the kernel/BSP level and OS Middleware level.