_______________
INTRODUCTION
The board support package (BSP) is the glue software that allows an embedded real-time operating system (RTOS) to run on a specific target board. Creating a BSP for your chosen board is a detailed software engineering task that takes 2 to 8 weeks. Expect an embedded software consultant to charge $20,000 to $100,000 for the work. The task involves interfacing the RTOS to the new board’s memory layout as well as to a timer, a serial console, and a network interface, at least. The BSP is the foundation of your software, so it is important that it be high quality and support all the peripherals you need. This article will guide you through the minefield of getting the right BSP and suggest options to reduce or eliminate the cost.
FIRST: A WORD ABOUT US
Why trust us when it comes to the details on pricing a BSP? Because Lynx Software Technologies has built and supported real-time operating systems (RTOSes) since 1988. We have witnessed hardware and embedded software technologies evolve and have supported our customers through the design, development, integration, certification, deployment, and support of software systems across mission-critical applications in AVIONICS, INDUSTRIAL, AUTOMOTIVE, UNMANNED SYSTEMS, DEFENSE, SECURE LAPTOPS, CRITICAL INFRASTRUCTURE, and other markets.
Where to look for a Board Support Package?
There are hundreds of different embedded boards available—such as the Raspberry Pi, BeagleBoard, Arduino, etc.—and you will need a BSP for your RTOS if you want to run it on your board. Boards and BSPs are a “chicken and egg”-type problem. Often you will choose the perfect board only to find there’s no BSP or vice versa. In some cases, commercial off-the-shelf (COTS) board vendors include BSPs—or sell BSPs for their boards—but the largest BSP libraries tend to reside with RTOS vendors, who strive to support as many BSPs as they can. If a suitable BSP exists, they will typically provide it free of charge to enable a sale.
The open-source Zephyr RTOS supports about 160 BSPs and VxWorks v7 lists 77 BSPs. In general, commercial RTOSs support fewer BSPs than open source OSes like Linux. However, be careful with large BSP lists—while everyone wants an impressive list, the devil lies in the details. Consider the following questions when looking for a BSP:
- How recent are the BSPs?
- Do they support modern processors, boards, and RTOS versions?
- What features are included?
- The core challenge is that BSPs are a moving target—new processors, boards and RTOS versions come out all the time—so that RTOS vendors are forever playing catch-up.
Choosing the ‘Right’ Board
Impacts on Board Support Package Cost
Certified Board Support Packages
Minimizing Board Support Package Cost
PC-Compatible Target Boards
If a PC-compatible target board is suitable, then the need for a custom BSP can likely be avoided. RTOS vendors tend to have a generic x86 PC BSP that works on most PC-compatible boards. This works because Intel-based boards have better hardware backward compatibility than other embedded boards. PC-compatible boards have a BIOS to help them boot and layers of operating modes so that a BSP written to use a common subset can run on practically any board.
Highly Integrated SoCs
BSP work can be reduced on modern System on Chips (SoCs) if they are so highly integrated that they are practically self-contained (except for RAM). That is, if every peripheral is implemented inside of the main chip, then an RTOS’s BSP for any board using that chip will be highly compatible with other boards using the same chip.
Auto-Generated BSPs
Another possibility for reducing costs is with advanced development tools that are smart enough to automatically generate a BSP for you. These tools are rare, but they do exist. The Xilinx Software Development Kit (SDK), for example, is capable of automatically generating BSPs for FreeRTOS on Xilinx parts based on Arm Cortex-R5, Cortex-A9, Cortex-A53 and Xilinx Microblaze processors. The SDK includes canned BSP source code templates that are automatically cut and pasted to construct complete BSPs. Drivers for peripherals are included as necessary and parameters are automatically populated into address maps. Xilinx can do this because their SDK is setup to build combined processor and FPGA based SoC systems on their FPGA hardware platforms. The Xilinx SDK includes both the intellectual property (IP) for hardware peripherals, knows the complete system memory map and has the software drivers to run them. Cleverly combining these using a FreeRTOS BSP source code template results in a buildable and executable BSP.
Hypervisor-Based Systems
Using a hypervisor to host your RTOS in a virtual board isolates the RTOS from the underlying target board. The RTOS BSP is simplified because board specific target initialization code is eliminated from the RTOS BSP, being done instead by the hypervisor as it boots up. If the RTOS is expecting a specific target board, the hypervisor can even be configured to make a virtual machine emulate that target board. For example, the memory map, available peripherals, and their locations can be tuned to look like a real target board. This is useful to host legacy applications without recompiling them, for example. Lynx MOSA.ic™ is an example of such a hypervisor based system. Lynx MOSA.ic™ is a development framework that allows a multicore processor (MCP) to be partitioned into virtual machines into which RTOS, Linux, and bare-metal guests can be hosted. It includes the LynxOS-178® RTOS, Buildroot Linux, and Lynx’s bare-metal environments configured with generic BSPs to run as guests.
Hardware Device Trees
A device tree is a machine readable hardware catalogue with the potential to further automate the creation of BSPs. It is a data structure that describes the hardware components of a target board so that an operating system (OS)—typically Linux—can run on it. The normal use of a device tree file is to pass it to a bootloader that loads it, along with a Linux kernel image, in order to boot Linux. Since Linux is usually the first OS ported to new boards, those new boards all come with pre-written device tree files. Lynx MOSA.ic™ takes advantage of device trees to further reduce BSP costs. The internals of Lynx MOSA.ic™ are built to support specific SoCs, but in addition, it reads device tree files to automatically account for differences between boards using the same SoC. In combination, this means Lynx MOSA.ic™ is able to automatically generate binary code to boot target boards without requiring a BSP for those boards. Lynx MOSA.ic™ first reads the device tree file to build a hardware catalog, then, using an architecture description language, an engineer assigns those hardware resources to create virtual machines ready for guest software workloads. Lynx MOSA.ic™ auto-generates the bootcode and virtual machine creation code, combining them together with guest images into a single executable file that can be launched by the boot loader.
BSP Support & Maintenance
Avoid Unnecessary BSP Costs In Your Next Project