Board Support Packages (BSPs) are the most vital component in any
Single Board Computer (SBC) based development project. As complexity
rises, their use has become all but essential in bringing new products
to market, based on the latest processors and associated integrated
Typically there are three major components to a BSP; firmware, that
initialises the SBC into a known state, a basic driver set, and a
so-called boot monitor. Through the provision of these low-level
components, developers are able to focus on handling the higher level
issues, such as the operating system (OS) and developing the
The firmware component is essential for every board; it contains
routines that initialise the processor(s) and bus(es), and set
configuration registers. The basic driver set contains drivers for
timers, serial I/O, networking and Flash memory, while the boot monitor
allows the rest of the system to be downloaded to the SBC through a
fast serial link, network interface or from Flash on the SBC itself.
BSPs are often key to the purchase decision of an SBC. Assuming the
supported RTOS can deliver the required performance, the availability
and quality of a BSP can make or break the SBC as a viable product.
BSPs are designed specifically for the board upon which they run and
so are unlikely to support a whole family of boards or all the
functions on every board. They are commonly written in a combination of
assembler and C and are debugged using a hardware-debugger, which takes
us back to standard development procedures of 20 years ago or more.
There is a job to be done by BSPs; to efficiently and reliably
initialise the hardware and load the OS. The application will interact
with the hardware through an API if one is present.
APIs present the user with a standardised way of interacting with
the hardware. They are provided to support communications, such as
TCP/IP, or to enable parts of the application to have much better
security than the norm.
The ARM TrustZone API, for example, provides a secure environment in
which sensitive operations such as Digital Rights Management and
cryptographic key management can be carried out.
This environment is designed to complement the less secure
environment provided by the host operating system. One common approach
that helps to increase the level of security provided is to reduce the
amount of code in the application.
This implies greater stability and requires a lower validation
effort. It is straightforward to envisage functional splits in most
sensitive software that will allow code to be partitioned into sections
that require the sort of protection an API like TrustZone can provide.
The implementation of a Linux BSP presents a much greater challenge
than one for, say, a VxWorks BSP. The reason is the absence of an API
in Linux; without it, the Linux kernel has to be patched in order to
support specific hardware. This can cause problems further down the
road, with maintenance and compatibility with newer kernels.
The absence of an API in Linux is due to the Linux community not
wanting to be constrained by a fixed API. Anyone using Visual Studio
will know the difficulties that upgrades can cause, when some systems
keep to the older version. Instinctively many users would prefer to
stick to the original version. This affects BSPs in the device driver
area and the methods of defining what is on a specific board.
Linux presents another problem, the BSP has to bring in the Linux
bootloader in order to install the OS. Effectively, two BSPs are
needed. According to Hans Juergen Rauser, Technical Account Manager
with Wind River Central Europe, this isn't always welcome: "Some
customers try to avoid upgrading the boot-loader in field-deployed
devices (flashing can go wrong, which would result in a dead device).
Therefore they try to boot a Linux boot-loader from VxWorks boot loader
or vice versa." Such approaches are understandable but perhaps not
BSPs have to chase new developments in hardware technology. From the
introduction of interfaces such as PCI Express, to new CPU variants or
memory technologies, BSPs have to be reworked or completely rewritten
to handle them, making a lot of work for someone.
On top of those changes, there is the highly flexible FPGA, where
there are many permutations of peripherals that could be invoked. To
ease this situation, Xilinx provides a process called Automatic BSP
Generation that tailors a BSP according to the current hardware
configuration of the FPGA.
Automatic generation of a BSP is done using Xilinx Platform Studio
(XPS), which is available in the Xilinx Embedded Development Kit (EDK).
XPS generates BSPs based on the defined hardware configuration. For
Linux, XPS generates a sparse Linux kernel source tree containing just
the hardware specific files for the BSP. For Linux 2.6, XPS supports
both the MontaVista and Wind River Linux distributions.