BSP vs Device-Drivers

EdwardH picture EdwardH · Aug 5, 2012 · Viewed 26.2k times · Source

While understanding each by itself (or maybe not), looks like I'm far from understanding the practical differences between the two.

Per my understanding, a BSP is a package of drivers and configuration settings that allows a kernel image to boot up a board (and is part of it). The individual device driver, operates on a specific component (HW), interfacing on one side with the core kernel and on the other side with the device itself.

Looking at the Linux kernel, it is unclear to me where the BSP role starts and the device driver role ends. Specifically, I am used to see one BSP per board per image, however, the generic Linux Kernel may be loaded on any architecture family with the same image (it is clear that for different families there are different images: x86, amd64, arm, etc...), where the specific board and peripherals drivers are loaded per need from the initrd.

Is there a BSP for the common Linux Kernel distributions? Or is BSP relevant just for special cases boards?

Is this behavior similar on other kernels? VxWorks?

And the last one, is it common to merge different BSP/s in order to generate a single image that will fit different boards?

Answer

Jacob Stevens picture Jacob Stevens · Mar 28, 2014

I see the relationship between BSPs and devices drivers as "has-a". Board support packages include device drivers.

The differences between BSPs & kernels isn't easy to distinguish. A kernel translates instructions to the hardware. Kernels are often written to particular families of hardware, so they're not as portable or generic as they seem. It amounts to different permutations of the code for each architecture family.

The BSP acts as sort of the inverse: it provides the tools & instructions to work with that board's specific set of hardware. In specific, controlled situations, the kernel could do this work. But the BSP enables any compatible kernel/OS/application stack to use that board, by following its configuration instructions.

If you just need to access CPU cycles & memory, maybe a few protocols (USB, ethernet, a couple video types), a kernel with wide architecture support is fantastic, and there was a time when the breadth of that hardware abstraction was penultimately valued. But now, consider that the board may have a suite of sensors (accelerometer, magnetometer, gyroscope, light, proximity, atmospheric pressure, etc), telephony, there may be multiple CPUs, multiple GPUs, and so on. A kernel can be written to provide VGA/DVI/HDMI/DisplayPort, and several permutations of CPU/GPU combinations, if/when someone uses those particular hardware packages, but it's not practical to write support for all theoretical contexts, compared to utilizing a BSP that's built for a specific board. And even then, that would be for one kernel; the board is capable of supporting Linux, Windows, Android, Symbian, whatever.

That's why efforts like Yocto exist, to further decouple kernel & hardware. BSPs make hardware sets extensible beyond a kernel/os/app stack or two, while kernels make a particular os/app stack portable over multiple HW architectures.