Introduction
Do you often get confused when people talk about the Board Support Package (BSP)?
Or maybe you have some idea about it… but you are not exactly sure:
- What a BSP is,
- Where it is located,
- Or what components it contains?
Like many engineers, you may have even Googled it — only to find many different definitions, each adding more confusion.
If that sounds familiar, you are in the right place.
I’ll explain what a BSP really is — in simple, practical terms, using a microcontroller analogy that every embedded engineer can relate to.
Let’s begin.
🔌 What Is a Board Support Package (BSP)?
A Board Support Package (BSP) is the set of low-level software components required to boot, initialize, and operate your hardware platform.
It includes:
- Startup code
- SoC-specific initialization
- Board-level drivers
- Utilities
- Low-level configuration necessary for the OS to run
But before we jump into Linux, let’s begin with something familiar.
🔧 Understanding BSP Using a Microcontroller Analogy
If you have worked with 8051, AVR, STM32, or any other microcontroller, you already know the typical bring-up steps:
1️⃣ Startup Code
Executed immediately after power-up.
It performs:
- Reset vector setup
- BSS and non-BSS initialization
- Stack pointer setup
- Cache initialization (if present)
This is the very first code that runs.
2️⃣ Clock Initialization
Microcontrollers contain bus clocks like AHB, APB, PLL, and peripheral clocks.
Before any peripheral works, these clocks must be configured.
3️⃣ Pin Multiplexing (Pinmux)
One pin may support GPIO, I2C, SPI or UART.
Depending on what is connected on the board, you configure the correct function.
Pinmux is always board-specific.
4️⃣ Drivers for Peripherals
If your board has EEPROM, LEDs, sensors, or codecs, you need to write:
- I2C driver
- SPI driver
- GPIO driver
- Peripheral initialization code
These four steps together make your microcontroller functional.
Now let’s map this thinking to BSP in Linux.
🧩 BSP in Embedded Linux – The Three Layers
In Embedded Linux, the BSP is divided into three major categories.
1️⃣ CPU-Dependent BSP
This includes everything required to initialize the CPU core:
- Startup code
- Reset handling
- Cache initialization
- Exception handling
- MMU setup
- Context switching infrastructure
- Low-level assembler routines
If your CPU is ARM Cortex-A, ARMv7, ARMv8, RISC-V, etc., this layer is CPU-specific.
2️⃣ SoC-Dependent BSP
Your CPU sits inside a System-on-Chip (SoC) — built by vendors like TI, NXP, Microchip, Allwinner, etc.
The SoC includes:
- Timers
- UART
- I2C
- SPI
- DMA
- Clocks
- Power domains
- Interrupt controller
- PLL
- Bus architecture
The initialization of these components is called SoC BSP.
It includes:
- Clock tree setup
- Power gating
- Reset control
- SoC-level peripheral drivers
This layer is extremely vendor-specific.
3️⃣ Board-Dependent BSP
Your SoC is mounted on a board such as:
- BeagleBone Black
- Raspberry Pi
- Custom hardware
- SOM + carrier board
At this level, the BSP deals with-board specifics:
- RAM initialization
- Flash/eMMC initialization
- Ethernet PHY setup
- Audio codec driver
- Pinmux for board wiring
- Reading EEPROM for board ID
- RTC driver
- Power supply constraints
- Boot source selection
This layer ensures your board boots exactly as your hardware requires.
🧩 So What Exactly Is the BSP?
From everything above, you can define BSP as:
A collection of low-level drivers, initialization code, and utilities required to bring up a specific hardware platform.
It includes everything needed to boot Linux on your board.
📍 Where Is the BSP Located?
This is where many engineers get confused.
A BSP is not a separate folder you add somewhere.
It is spread across the bootloader, kernel, and sometimes device tree.
✔ BSP in U-Boot (Bootloader)
- CPU startup code
- SoC initialization
- DDR initialization
- Pinmux
- Power management
- Low-level peripheral drivers
✔ BSP in Linux Kernel
- CPU architecture code
- SoC drivers
- Board drivers
- Device tree (DTS) describing hardware
- Memory map
- Interrupt map
- Clock definitions
✔ BSP in Build Systems (Yocto, Buildroot)
Vendors often package BSP as:
- U-Boot patches
- Kernel patches
- Device tree files
- Toolchains
- Board configuration
This is why vendor “BSPs” look different — they are simply bundling all low-level components together.
🧾 Why Is BSP So Important?
Because nothing boots without it.
Your application, root filesystem, frameworks — everything depends on BSP.
If BSP is wrong, you get:
- No boot
- No console
- No clocks
- No RAM
- No storage
- No device drivers
- No communication
BSP = The foundation of the system.
🧩 Final Summary – BSP in Embedded Linux
| BSP Layer | What It Does | Examples |
|---|---|---|
| CPU BSP | Initialize CPU | MMU, caches, reset |
| SoC BSP | Initialize SoC peripherals | UART, SPI, I2C, clocks |
| Board BSP | Board-specific bring-up | Pinmux, RAM, eMMC, codecs |
A BSP is:
✔ Board-specific
✔ Low-level
✔ Essential for boot
✔ Spread across bootloader + kernel
✔ Provided by vendors or implemented by you
🚀 Learn BSP, Boot Process & Linux Bring-up the RIGHT Way
If you want to master Linux bring-up, boot process, and low-level BSP development, check out:
🔥 Embedded Linux Essentials
Perfect for beginners →
👉 https://embitude.in/elph/
🔥 Embedded Linux Porting Advanced
Perfect for engineers working on board bring-up, kernel, device trees →
👉 https://embitude.in/elpa/
Both programs offer:
✔ Practical hands-on learning
✔ Weekly meetups
✔ Doubt clarification
✔ Career-oriented guidance
✔ Real embedded projects
And join our growing community of like-minded professionals:
👉 https://embitudeinfotech.graphy.com/s/community