The Right Board Support Package (BSP) for Your SBC By Alexander Kaliadin, Business Development Manager, RTSoft Inc.

	The Importance of Board Support Packages
	According to research conducted in 1999 , the single most important factor for customers selecting single board computers (SBCs) is not price, performance, or available I/O, but the availability of software and development tools. A well-designed board support package (BSP) is an critical part of such support, and may be the most important single component in ensuring the customer's ability to seamlessly integrate the ever-expanding range of SBC capabilities. A carefully developed BSP enables the customer to focus on the OS and applications, helping to shorten the learning curve and, potentially, time-to-market.

		In addition to reducing development time, however, the BSP can also help the customer exploit the full range of the SBC's built-in capabilities. The research cited above also showed that the principal criterion for selection of an onboard real-time operating system (RTOS) is performance. The BSP provides the foundation for the overlying RTOS, and helps to ensure its overall speed and reliability. Far from being "a necessary evil," the BSP can be regarded as a vital element of your sales support strategy, helping to package your SBC attractively for your target markets.

	Under the Hood: the Components of a Board Support Package
	The idea of a BSP is not new; the primary goal is to isolate the OS core from the hardware, to make it portable within one processor family. The process of creating a BSP is sometimes referred to as "porting" (this term is also used, in a different context, to describe the compilation of a new OS core for another processing family). A BSP typically consists of three major components: firmware that initializes the SBC into a known state, a basic driver set, and a so-called boot monitor.

		The firmware component is essential for every board; it contains routines that initialize the processor(s) and bus(es), set arbitration, set configuration registers, and so on. The basic driver set contains, at minimum, drivers for timers and a serial port (if present), as well as optional drivers for Ethernet, SCSI, and other interfaces.

	The boot monitor is an application that allows the user to connect to the SBC via serial or Ethernet link and download the rest of the system, including the OS and applications. If the OS is already in onboard FLASH, the boot monitor can load and execute code immediately. The boot monitor provides a method of downloading code to a target SBC without use of hardware-assisted tools such as JTAG debuggers.

		Building a Board Support Package
		When starting with a bare board, the process of developing a BSP should begin with writing an initialization code. Typically, you will need to study and use the assembly language; however, it is important to limit the scope of assembly to basic data and register set initialization, leaving the remainder for a high level language like C. Compilers continue to improve, producing more effective code, and flash memory size is now quite large.

	Within certain architectures, you may have even tighter control on code size vs. speed; for example, ARM THUMB compatible processors permit the selection of a 16-bit or 32-bit instruction set within the same file for different blocks of code. As a general rule, limit the assembly to a single file in the BSP, and make sure to provide extensive comments for both code and data. At this stage in development, you can benefit from the use of a hardware-assisted debugging tool, such as JTAG, that is able to directly access the hardware on the board. The best tools may even be provided with predefined register sets for your board (or similar boards), ready for editing and download.

		If you plan to use different operating systems for your SBC, the next logical step may be to define and develop specific API, plus underlying functions, to handle most or all of the components you have on board. This is sometimes referred to as a microcode library - the idea is to provide developers with building blocks for any specific applications and operating systems they may work with. This approach provides greater flexibility, but consumes more time and engineering effort, because the structure, design, and effectiveness of API become high priorities. Such APIs can be found in sample development systems like the ARM Integrator family or the Intel IXP1200.

	In most cases, however, you will be focusing on developing a BSP for a specific operating system. In this situation, you can start developing basic drivers after completing the initialization code. These will often include drivers for timers and the serial port. Timer support is essential for OS function, except in those cases when the timer is built into the processor, with support included in the OS core. A serial port driver is essential if you plan to use a boot monitor; Ethernet may be used as a higher speed option to serial.

		In developing drivers, try to avoid static resource configurations when possible, especially when using PCI bus. Some extra effort invested here, to support dynamic coding, will likely pay dividends during later stages of development, when you need to add support for other devices. It's important to make your code as modular as possible - code for different components must be located in different files, with a clear header file structure, and well-documented configuration files must be included.

	Is a boot monitor essential? The final decision is yours, but it can be a convenient and attractive option for the end user. A boot monitor represents a big chunk of code and you should approach its development from the OS side, as a component. This means you need to decide if it should be written hardware-independent. Because it will use drivers that you provide, it's possible to write it once and compile for each specific processor family, rather than for a specific board. This eliminates the burden of integrating such support into new designs, but the boot monitor should be tested carefully and source code should be provided.

		It isn't necessary to provide a boot monitor if you are sure that your customer will be developing additional drivers or components using tools like JTAG debugger. These tools perform the function of a boot monitor, and are bundled with many additional features and options, using the same physical interfaces between host and SBC.

	You should select development and debugging tools based on a track record of stable and proven performance, instead of using highly sophisticated versions that have been only recently released. You should carefully select the blend of hardware and software that permits the development of reliable, compact, and optimized code. If you are working with the first prototypes of a newly-designed SBC, a bus analyzer, to help detect hardware errors, can be a valuable investment.

		Test it, test it, test it
		The execution of new BSP code on a new SBC can, and often does, bring unexpected results, even when you think the code is error-free. Hang-ups, mysterious interrupts, and data transfer errors are just a few examples of the unpleasant behavior that may haunt a new BSP.

	A new BSP should always be tested using a written and clearly identified test specification. The specification should cover all possible combinations of system and bus speeds, caches on and off, data size and transfer speeds, polling and interrupt modes, and error checking. Software, especially when developed for a new hardware platform, is rarely error-free; a solid testing specification will help you identify and promptly resolve problems.

		In addition to "basic" test specifications, it is often advisable to develop stress tests or applications, especially if the board is intended for the military or communication markets, where reliability is paramount. A series of well-designed stress tests can help ensure both you and your customer that the board has been designed with an adequate safety margin, capable of withstanding the harshest anticipated working conditions. As noted at the beginning of this article, superior support is criterion number one in selecting a single board computer vendor. The conformance of a new board to test specifications, both basic and stress, is an essential element in providing such support.

	A number of vendors and independent organizations provide validation services, as well. For example, WindRiver supplies a Validation Test Suite, in source form, along with its Tornado BSP Developer's Kit. Once your BSP has successfully passed the test suite in the toolkit, WindRiver will provide paid verification and compliance certification for BSPs written for VxWorks RTOS. In most cases, RTOS vendors provide at least a porting guide, as well as tools similar to those provided by WindRiver.

		The Future of Board Support Packages
		An obvious trend in the post-PC era is the increasing design complexity in areas such as System-on-Chip (SOC), network processors, portable systems, and datacom and telecom applications. Vendors are scrambling to provide cost-effective solutions by integrating many functions onto a single board.

	For example, Cirrus Logic's MSP (Market Specific Processor) Maverick EP72111 integrates an ARM720T core with an audio interface, LCD controller, DRAM controller, synchronous serial, ROM, SDRAM, UARTs, infrared, general purpose I/O, Ethernet, keyboard, and PCMCIA. Intel's IXP1200 architecture combines a StrongARM core with six additional specific cores known as microengines. In systems such as these, it's not uncommon for the size of your firmware to be comparable to, or even exceed, the OS plus applications image.

		In the world of SOC designs, new interfaces - including Universal Serial Bus (USB) and FireWire (IEEE 1394) - are migrating from the PC world. The USB port included in new PCs stands a good chance of becoming the de facto interface of choice, with the adoption of the new USB 2.0 specification promising far higher speeds than the USB 1.1 in common use today.

	Many RTOS vendors, including Microware and WindRiver, have already built USB support into their operating systems; Microware claims USB 2.0 compatibility. It is only a matter of time before USB replaces or coexists with Ethernet in single board computers. For developers, of course, this means the addition of USB support into board support packages.

		FireWire, providing 400 Mbit/sec real-time performance today, represents an attractive solution for those applications that deal with video information. It is unlikely to replace USB, but there will be a place for FireWire in many new SBCs.

	Within the telecom market, there is strong demand for Hot-Swap capable applications. The addition of Hot-Swap support, especially for CompactPCI systems, can make your BSP far more attractive to developers serving this market. Several tools are available (for example, the GO-HotSwap toolkit from Jungo) that simplify the development of Hot-Swap aware drivers.

		All of this increased functionality comes at the price of consistent increases in firmware size and complexity. To provide the needed support environment for developers, BSPs must be better organized than ever, and built in modular fashion. An excellent example of this approach is provided by VisionWare, from WindRiver. VisionWare includes a basic initialization/boot code called vBase, along with additional modules, including console interface, protocol stacks, software monitor, loader, flash file system, HTML server and a diagnostic module. vBuilder IDE enables developers to select modules to integrate into their firmware, and to add customized modules as needed. However, even VisionWare does not provide the ability to dynamically add drivers and modules, in an on-demand fashion, to the system while running.

	The most flexible and powerful BSP solution will include a device manager, capable of interacting with applications, the OS core, and the user, in addition to serving requests for the dynamic loading and unloading of drivers, system modules, or services (see Figure 1). Such a design could potentially provide field upgradeability, flexibility, minimal code size, Hot-Swap capability, serviceability, and long product life.

		Figure 1: The Future of BSPs? This figure illustrates a modular BSP structure discussed in the text, in which components (drivers, services) can be dynamically loaded or unloaded into the system by a "device manager" in response to calls from the operating system or user applications.

	One would hope to see implementation of such solutions in 2001, but the amount of work that needs to be done will probably require the dedicated, close cooperation of several companies. The overall message, however, is clear: investments made now in design concepts for board support packages will significantly shape the future of single board computers. Whether made in a collaborative approach or by individual companies, such investments promise to create advantages for all developers working in this environment.

		Editor's Note: Alexander Kaliadin is Business Development Manager for RTSoft Inc., a leading provider of complete software and support solutions for the embedded systems market, based in Moscow, Russia. RTSoft offers services including the development of board support packages (BSPs), custom firmware, device drivers, and network protocols, as well as OS porting, application programming and technical support. The company, which employs over 200 people worldwide and maintains relationships with suppliers in Europe and North America, has successfully completed projects in telecommunications, electronics, and avionics; and has developed solutions for oil and gas, power distribution, and metallurgy industries.

	Copyright 2000 - 2004 © RTSoft