Installing Linux on most PCs is easy — you pop in a DVD or a USB stick, click through the install process, and you’re most of the way there. When it comes to more specialised devices, however, installing and running an operating system isn’t quite so straight-forward.
Embedded devices, for example, vary wildly in their specifications and their capabilities. Unlike PCs, they lack standardised hardware platforms, protocols and interfaces that make it easy for the operating system to speak to the hardware. This is where Board Support Packages are used, and they are used often. Most ‘smart’ devices you own are likely to use BSPs in some fashion, whether they be embedded development boards like Arduinos, or IoT appliances, smartphones and more.
Before continuing, we have to delve into some of the previous paragraph’s terminology. To better understand what Board Support Packages are, it’s important to also understand what an operating system is, and what a kernel is.
In a nutshell, an operating system is the massive software program that communicates between a user’s applications and the hardware powering them. It allows you to tell the hardware what to do and how to do it -- without an operating system, the hardware is essentially useless. The core component of an operating system is its kernel, which links the user-facing side of the operating system (i.e. the programs you use) to the hardware running them. A kernel contains the essentials required to make most programs able to communicate with the hardware so specific applications using specific hardware, like video games that need to communicate with a specific vendor’s graphics card, may need additional drivers that are not included in the kernel. This part of the OS is also mostly protected from what is going on in userspace, i.e. the programs and files that the user interacts with normally while using their computer for the usual (i.e. not development or tinkering-related) tasks. In most operating systems in use today, the kernel is bundled with a number of other components to give the operating system added flexibility and functionality.
So what is a BSP? The answer to that is tricky, because BSPs can vary quite significantly in size and scope and as a result of that different people define BSPs in different ways.
In simple terms, Board Support Packages are the bundles of patches to the operating system’s core layers that allow it to run on a specific piece of hardware. Unlike a kernel, the BSP provided by an Original Equipment Manufacturers (OEM) will include all the software that is required to make the board usable for whatever application it is meant to perform -- this means a BSP will often include not just a kernel but also a bootloader, a root filesystem, device drivers, and more.
However, this is not always the case. One of the reasons why BSPs are difficult to define is because they each contain and affect different components. Some are as simple as a few added patches to a kernel, thus allowing it to run on the hardware in question. Some are far more complex, and involve every part of the operating system stack. This can depend on the complexity of the board in question or the functions required from it: basic boards will only require basic BSPs that enable functions as basic as initialising the processor, communication buses, clocks and memory — to power the board in question and boot it up. More complex BSPs can include drivers that allow the operating system to communicate with the board’s peripherals, applications to use and configure these peripherals, services required to keep the board’s functionality running properly, and more.
Example of a Board Support Package’s place within an operating system stack. BSPs often introduce patches on several layers of the stack, with the biggest changes taking place on the lower levels.
BSPs are found in the entirety of the hardware industry; the chances of a piece of electronics shipping without having had some sort of BSP is minimal, but today they are most visible on embedded devices. This is partly due to the fact that they are often not built on standardised platforms and also partly due to the wide range of different specifications and components. These devices sometimes run Real Time Operating Systems (RTOS) like Zephyr for speed and efficiency, but in the last few years the increasing computing power of these devices have allowed them to run the more complex and versatile Linux kernel. The fact that the Linux kernel is free, open source, and vendor agnostic has also made it a popular choice for OEMs.
Board Support Packages are quite useful, but they are not a flawless solution. There are sometimes problems with the way they are maintained. In the case of BSPs created to run Linux on devices, for example, the patches that are created and included are often not upstreamed. This often means that the kernel versions included in these packages are out of date. There might be several reasons for this: the changes made by the hardware vendor might not be ready for mainstream use yet, or they might have been deemed to not be up to the standard expected by the upstream bootloader or kernel projects. Sometimes some vendors are simply not interested in upstreaming their work, too.
This introduces potential security concerns and the loss of features included in the latest versions. It is especially problematic when support for these BSPs is dropped, because this can mean that the hardware in question will never receive these updates at all. So the device you might have bought a few months ago is now obsolete, either because the manufacturer can no longer afford to maintain it, or because it was in their interest to stop maintaining it.
This does not apply to all BSPs, particularly since they are not a Linux-specific concept. The term was coined a decade before Linux even existed, in 1981, and the concept slowly grew in popularity until being adopted widely throughout the software industry. Though its origins may be ancient by technology’s standards, their importance has not diminished — particularly as mobile and embedded devices grow in popularity.
Stay up to date on our latest news about embedded
Receive our most relevant Embedded stories in your inbox.
- Using Git LFS and fast-import together
- Testing in a Box: Streamlining Embedded Systems Testing
- SDV Europe: What Codethink has planned
- How do Hardware Security Modules impact the automotive sector? The final blog in a three part discussion
- How do Hardware Security Modules impact the automotive sector? Part two of a three part discussion
- How do Hardware Security Modules impact the automotive sector? Part one of a three part discussion
- Automated Kernel Testing on RISC-V Hardware
- Automated end-to-end testing for Android Automotive on Hardware
- GUADEC 2023
- Embedded Open Source Summit 2023
- RISC-V: exploring a bug in stack unwinding
- Adding RISC-V Vector Cryptography Extension support to QEMU
- Introducing Our New Open-Source Tool: Quality Assurance Daemon
- Long Term Maintainability
- FOSDEM 2023
- Think before you Pip
- BuildStream 2.0 is here, just in time for the holidays!
- A Valuable & Comprehensive Firmware Code Review by Codethink
- GNOME OS & Atomic Upgrades on the PinePhone
- Flathub-Codethink Collaboration
- Codethink proudly sponsors GUADEC 2022
- Tracking Down an Obscure Reproducibility Bug in glibc
- Web app test automation with `cdt`
- FOSDEM Testing and Automation talk
- Protecting your project from dependency access problems
- Porting GNOME OS to Microchip's PolarFire Icicle Kit
- YAML Schemas: Validating Data without Writing Code
- Deterministic Construction Service
- Codethink becomes a Microchip Design Partner
- Hamsa: Using an NVIDIA Jetson Development Kit to create a fully open-source Robot Nano Hand
- Using STPA with software-intensive systems
- Codethink achieves ISO 26262 ASIL D Tool Certification
- RISC-V: running GNOME OS on SiFive hardware for the first time
- Automated Linux kernel testing
- Native compilation on Arm servers is so much faster now
- Higher quality of FOSS: How we are helping GNOME to improve their test pipeline
- RISC-V: A Small Hardware Project
- Why aligning with open source mainline is the way to go
- Build Meetup 2021: The BuildTeam Community Event
- A new approach to software safety
- Does the "Hypocrite Commits" incident prove that Linux is unsafe?
- ABI Stability in freedesktop-sdk
- Why your organisation needs to embrace working in the open-source ecosystem
- RISC-V User space access Oops
- Tracking Players at the Edge: An Overview
- What is Remote Asset API?
- Running a devroom at FOSDEM: Safety and Open Source
- Meet the codethings: Understanding BuildGrid and BuildBox with Beth White
- Streamlining Terraform configuration with Jsonnet
- Bloodlight: Designing a Heart Rate Sensor with STM32, LEDs and Photodiode
- Making the tech industry more inclusive for women
- Bloodlight Case Design: Lessons Learned
- Safety is a system property, not a software property
- RISC-V: Codethink's first research about the open instruction set
- Meet the Codethings: Safety-critical systems and the benefits of STPA with Shaun Mooney
- Why Project Managers are essential in an effective software consultancy
- FOSDEM 2021: Devroom for Safety and Open Source
- Meet the Codethings: Ben Dooks talks about Linux kernel and RISC-V
- Here we go 2021: 4 open source events for software engineers and project leaders
- Xmas Greetings from Codethink
- Call for Papers: FOSDEM 2021 Dev Room Safety and Open Source Software
- Building the abseil-hello Bazel project for a different architecture using a dynamically generated toolchain
- Advent of Code: programming puzzle challenges
- Full archive