Embedded Components and Tools Blog Center

Ron Fredericks writes: There are three separate views to what defines an effective Board Support Package (BSP). I believe each of these views is correct as independent descriptions of a BSP. But together these views provide insight into the embedded target from equally important perspectives or engineering disciplines. Read this post to learn more about the essence of embedded systems and how Wind River’s VxWorks BSP architecture has been a critical success factor in comparison to many other real-time embedded operating system executives and kernels available today.

I chose to discuss Wind River’s VxWorks BSP because of my familiarity with their product line, my understanding of their BSP as a competitive product compared to other real-time kernels, and because of my industry accomplishments working with Wind River’s BSPs:

• Ron Fredericks wins Wind River’s prestigious Navigation Award for designing, launching, and marketing the first online interactive social network for BSP’s. more>
• Ron Fredericks wins Aiysis’ Million Dollar Club Award for nurturing a Wind River partnership between VxWorks and Aiysis DriveWay BSP tool kit that generated over one million in annual sales. more>
• Ron Fredericks co-author’s an article with Xilinx on How to Design Field Upgradable Systems based on FPGA Internet connectivity with VxWorks BSP’s. more>
• Ron Fredericks produces an online video: How to Prototype a Device Driver [or BSP] in Less Than – Wow! – 5 Minutes for a Freescale application processor / communications co-processor System on Chip (SoC). more>

A similar high level discussion can not be made for most embedded Windows or embedded Linux BSP’s today. This is because the BSP for these monolithic kernels are not as modular as a real-time executive kernel such as VxWorks. Indeed other real-time kernel vendors can and do take advantage of the BSP too. But, the VxWorks BSP just took more advantage of this natural separation between board support and kernel tasks earlier in the marketplace and has been an advantage for its customers as a result ever since.

Figure 1 – Embedded device with BSP connected to a host workstation

As shown in Figure 1, most BSP’s today, even those for embedded Windows and embedded Linux, do have a robust set of boot options. In many cases a BSP can be used on its own to network attach to a shared file system where the full operating system and application can be loaded. In this way, a device under development need not be the device where development takes place. The BSP in this case forms the basis for a cross-platform development environment – a big plus for developers of embedded systems. Developers often expect cross-platform development to include a BSP with a limited network stack to load new code onto the target hardware during a cold reset. The BSP might use JTAG on-chip run-time control, RS232 serial port, FTP, Bootp, TFTP and RARP, or even a command shell with a full network stack, as the boot loading protocol. But what ever host to target connectivity is used, cross-development allows a high end workstation to be used for time-saving development along with an easy way to download the resulting compiled relocatable object code or a linked and located image onto an embedded target.

For hardware vendors, the BSP is a very useful partner tool. If a hardware vendor makes a set of boards along with a bus pre-assembled as a subsystem or just a single board computer, the BSP allows its clients to leverage this hardware for software development right away. So a hardware vendor can select major operating systems that meet the needs of its target client base and offer a BSP suitable for these operating systems. Usually the BSP is not a licensed product from the operating system vendor and can be bundled royalty free or under very libral license fee conditions. In this way, the operating system vendor or the open-source community, can partner with this hardware platform as a known reference for direct end products or for development of custom products. The horrible alternative is a slow hardware bring-up using new hardware for the first time to build a unique BSP – a very slow and expensive procedure where few software debug tools are available. JTAG or other N-wire run-control devices can be used with an operating system vendor’s debugger in some cases when a robust BSP is not already available. Silicon vendors and I/O device vendors can leverage this technical marketing strategy too.

I encourage Microsoft and embedded Linux communities to consider improving their BSP strategy to deliver more value from a separate BSP structure too. I also encourage my readers to go ahead and submit comments to this blog post if you know of other vendors with good BSP designs as the marketplace is always changing.

View #1: A BSP is the kernel’s interface to device drivers

A VxWorks Board Support Package provides a standardized interface between hardware and the operating system. A BSP does not directly access hardware. Although a BSP does provide an interface to device drivers which in turn allows the kernel to communicate with the hardware’s assets such as device controllers, the microprocessor (CPU), memory, internal and external busses.

Figure 2 – BSP is an interface between kernel and hardware

Figure 2 demonstrates how VxWorks and the developer’s application software remain hardware independent while the BSP provides an interface to the embedded system’s architecture and hardware assets. Wind River BSPs conform to a standard, introduced with VxWorks BSP Version 1.1. The standard is fully described in the Tornado BSP Developer’s Kit for VxWorks. The BSP provides a common application programming interface (API) and a stable environment for the real-time operating system. The standard interface defines both BSP conventions and BSP validation procedures.

Wind River provides a standardized BSP validation procedure for engineers who are developing their own BSP’s. Validation is very efficient with a BSP designed for VxWorks because the BSP testing can be performed without having to test the operating system at the same time. Unlike Wind River’s real-time operating systems, most operating systems can not separate the testing of the BSP from the testing of the operating system itself making code coverage during testing a much larger and more inaccurate process. The BSP validation test suite provided by Wind River is repeatable and as such can be performed by the company developing a BSP as well as by others because of this standard. When I supported Wind River’s partners back in 2002, a partner could request that the WindLink partner program grant “Tornado Certified” status to a new BSP after passing the validation procedure as part of an overall certification process.

The validation procedure include tests for:
• Package validation
• Installation tests
• Functional tests
• Code review process including certification from the WindLink partner program

The Tornado BSP standard included conventions to be used by developers that fall into four main categories:
• Coding Conventions
• Documentation guidelines
• BSP Packaging
• Driver guidelines

Another strength of VxWorks is that it provides a high degree of architectural and hardware independence for application code because of this API. Application code and VxWorks can both more easily migrate from one architecture to an other because the BSP and related device drivers offer a consistent interface and modular design.

To further illustrate the BSP’s ability to interface hardware to software: Consider the process of laying carpet on your home’s floor. The carpet layer uses two-sided sticky tape to quickly attach just about any style carpet to any architectural floor plan beneath it. The BSP acts like this two-sided sticky tape attaching the embedded hardware to the operating system that uses it.

View #2: A BSP is a set of libraries offering a hardware abstraction layer to the kernel

The BSP enforces a modular design by isolating hardware-specific functionally into a set of libraries that provide an identical software interface to the hardware functions available on an embedded system. See detailed description of some of the common libraries and related files later in this blog post.

Figure 3 – Location of BSP files

Figure 3 shows an example of the typical files supporting a PowerPC target’s BSP and their location in a Tornado installation on a host computer such as Windows XP.

The BSP includes facilities for hardware initialization when power is first applied or when a hardware reset has been initiated. The BSP also includes support for interrupt handling and generation, hardware clock and timer management, and mapping of available local and bus memory. These basic services provide the real-time kernel with multi-tasking services and memory space for the designer’s application code.

Other device drivers and related support services can be included in this set of libraries extending the hardware abstraction to support the embedded system’s custom hardware services. These services would include networking, security, storage, graphics, and input/output to the outside world – for example. The devices referenced by the BSP can be located on a single board computer, a system on a chip (SoC), or on peripheral devices located across a wireless boundary or on a backplane using a hardware bus.

View #3: A BSP supports a host/target cross development environment

The BSP provides support for developers using Tornado tools on a host computer for engineering development such as an editor, compiler, linker, and debugger through a client/server communications protocol between the developer’s host computer and the embedded target’s CPU, hardware devices and on-board memory. For VxWorks developers, the BSP offers an interface to the WDB agent that provides an open standard for cross-hosted programming on a specific target’s architecture. The host computer supports these services using the Tornado tool suite through a target server acting as the communications agent. The target BSP can support a networked development environment using one or more of the following devices: Ethernet, JTAG, serial UART, ROM socket, or custom driver, to communicate with the host’s target server. When an application is complete and the embedded device is ready for production, the WDB agent can be removed from the target’s BSP.

Figure 4 – BSP supports host/target cross development

Figure 4 demonstrates a typical cross development embedded programming model. The WDB client on the target BSP communicates with the host’s target server. This host/target pair supports connecting other software and hardware tools that lower the cost of a typical engineering cycle: design, edit, compile, link, download, debug, test, and deploy.

There are advantages to having a BSP that is separated from the kernel….

A BSP allows target applications to be ported to many architectures.

The three views of a BSP described above are all consistent with today’s engineering needs for a common interface to development tools residing on a robust host computer in support of an embedded application requiring operating system support and services that is modular and portable across many different architectures.

Wind River and its board and silicon partners offer a wide variety of BSP’s for custom off the shelf (COTS) single board computers, and time saving reference designs on more than 12 different architectures. See the BSP web site I designed for Wind River back in 2002:

www.windriver.com/products/bsp_web/bsp_architecture.html

Description of BSP technical features

There usually is a file named target.nr defined in the BSP documentation standards for each BSP. The file contains a list of technical features supported and unsupported for a particular COTS or reference board. The list of features describes what a BSP is expected to do during hardware initialization when the CPU executes its first instructions as well as what hardware assets should be presented to the operating system. This information is summarized here.

Boot Monitor
• Describe the methods and devices available for booting RTOS on this board. (sm, SCSI, Ethernet, vendor-bug ROMs, open firmware, visionWARE, etc).
• Describe the network support available for booting; bootp, proxy-arp, etc…

Default Ram size
Additional supported memory options
Cache support
Flash and ROM memory
• How are ROMs made and installed? (How do they split?) Can FLASH ROMs be burned on board? If so, how?

Timer support in addition to system clock
• Describe routines that are associated with speed of CPU and Timers

Devices supported:
• The chip drivers included are:
templateSio.c – template serial driver
templateTimer.c – template timer driver
templateVme.c – template VMEbus driver
templateNvram.c – template non-volatile RAM driver
• Describe the device drivers for this board. Are there special driver ptions that must be used with this board such as CompactPCI hot swap support? Read the specific driver documentation and describe any special options used with this board.
Memory Map
• Provide a detailed memory map of the local bus, and all additional busses from a bus master point of view. Identify only slave devices actually on each bus, not their apparent address on some other bus. (i.e. if a serial device is a PCI device, do not list it on the local bus memory map, just the PCI memory map). Identify all addresses that the user can adjust by changing config.h, as being software controllable. Identify all bus master devices (DMA) on each bus.
• If VME is present, describe the default parameters for the master windows and how to change them, if possible. (master access means accessing some other board from this board). Describe the default parameters for the slave access windows, and how to change them, if possible. (Slave access means an access from another bus master). The normal VxWorks default is to enable the slave access window(s) only on CPU 0, as part of the routine sysProcNumSet(). Otherwise, slave accesses are not normally permitted.
• If PCI is present, describe the configuration access methods used to access PCI configuration space. Describe any address mapping from local addresses to PCI addresses and vice versa. Describe how the user can alter this, if appropriate.
Shared Memory
• If appropriate, identify the main bus and the type of shared memory support provided, if any. Identify the type of mailbox support and Test-And-Set support used. Identify any special support, or consideration, necessary from other boards in a multi-board system.
Interrupts
• Provide a list of interrupts/exceptions by priority and/or vector number. Describe any special interrupt connection routines or considerations used with this BSP.
Serial Ports
• Identify the default configuration for all serial ports. Document any special considerations: i.e. hardware flow control cannot be disabled thus requiring a jumper to be installed when no terminal device is connected.
SCSI Support
• Are there any known SCSI configuration limitations? Does the BSP support SCSI-1 or SCSI-2? Describe any special connectors or adapters. Does the board include terminators on-board? Is there a jumper to activate the termination network?
Ethernet Support
• Describe the Ethernet ports on the board. Identify how the MAC address is obtained or specified for each port.
Delivered Objects
• Which pre-compiled objects are delivered with the BSP?

Make Targets
• If there is any special information about a specific make target, then it should be explained. Identify any standard targets that do not build or run correctly. (bootrom, bootrom_uncmp, bootrom.res_rom, examples on VxWorks also include: vxWorks, vxWorks.st, vxWorks.res_rom, vxWorks.res_rom_nosym, vxWorks_rom).
Special routines
• Are there any unique BSP routines available to the user?
Divide by zero exception
• Describe exception handling of divide by zero event.
Host-Target Communications Support
• Name of client server agent such as WDB for VxWorks
• Describe additional WDB agents supported for debug support with host if any.

Some details on the collection of BSP libraries

BSP Source and Include Files reside in the following two subdirectories of a Tornado installation:
• TornadoBaseDirectory/target/config/all
• TornadoBaseDirectory/target/config/BSPname

See figure 2 for a view of these subdirectories and files. The subdirectory TornadoBaseDirectory /target/config/bspname contains the hardware dependent Board Support Package (BSP), which consists of files for the particular hardware used to run VxWorks, such as a CompactPCI board with specific semiconductor silicon assets for serial lines, timers, and other devices. The files include:

• Makefile
• sysLib.c
• sysSerial.c
• sysALib.s
• romInit.s
• bspname.h
• config.h

Two target-specific libraries, sysLib and sysALib, are included with each port of VxWorks. These libraries are the heart of VxWorks portability; they provide an identical software interface to the hardware functions of all boards. They include facilities for hardware initialization, interrupt handling and generation, hardware clock and timer management, mapping of local and bus memory spaces, memory sizing, and so on.

The System Library
The file sysLib.c provides the board-level interface on which VxWorks and application code can be built in a hardware-independent manner. The functions that should be addressed include:

• Initialization functions
1. Initialize the hardware to a known state
2. Identify the system

• Initialize drivers, such as SCSI or custom drivers

• Memory/address space functions
1. Get the on-board memory size
2. Make on-board memory accessible to external bus (optional)
3. Map local and bus address spaces
4. Enable/disable cache memory
5. Set/get nonvolatile RAM (NVRAM)
6. Define the board’s memory map (optional)
7. virtual-to-physical memory map declarations for processors with MMUs

• Bus interrupt functions
1. Enable/disable bus interrupt levels
2. Generate bus interrupts

• Clock/timer functions
1. enable/disable timer interrupts
2. set the periodic rate of the timer

• Mailbox/location monitor functions (optional)
1. Enable mailbox/location monitor interrupts

The sysLib library does not support every feature of every board: some boards may have additional features, others may have fewer, others still may have the same features with a different interface. For example, some boards provide some sysLib functions by means of hardware switches, jumpers, or PALs, instead of by software-controllable registers.

The configuration modules usrConfig.c and bootConfig.c in TornadoBaseDirectory/target/config/all subdirectory are responsible for invoking this library’s routines at the appropriate time. Device drivers can use some of the memory mapping routines and bus functions.

Each BSP also includes a boot ROM or other boot mechanism. Many of these import the run-time image from the development host. For information on boot ROMs and other booting mechanisms see Tornado Getting Started manual and VxWorks User ‘s Guide section 8.9 Creating Bootable Applications. For information on target-specific libraries, see 8.2 The Board Support Package (BSP) in the VxWorks User’s Guide and the target-specific reference entries for your board type starting with the file target.nr on the BSP distribution.

Virtual Memory Mapping
For boards with MMU support, the data structure sysPhysMemDesc defines the virtual-to-physical memory map. This table is typically defined in sysLib.c, although some BSPs place it in a separate file, memDesc.c. It is declared as an array of the data structure PHYS_MEM_DESC. No two entries in this descriptor can overlap; each entry must be a unique memory space.

The sysPhysMemDesc array should reflect your system configuration, and you may encounter a number of reasons for changing the MMU memory map, for example: the need to change the size of local memory or the size of the VME master access space, or because the address of the VME master access space has been moved. For information on virtual memory mapping, as well as an example of how to modify sysPhysMemDesc, see VxWorks User’s Guide section 7.3 Virtual Memory Configuration.

The Serial Driver
The file sysSerial.c provides board-specific initialization for the on-board serial ports. The actual serial I/O driver is located in the TornadoBaseDirectory /target/src/drv/sio directory. The library ttyDrv uses the serial I/O driver to provide terminal operations for VxWorks.

BSP Initialization Modules
The following files initialize the BSP:

The file romInit.s contains assembly-level initialization routines.

The file sysALib.s contains initialization and system-specific assembly-level routines.

BSP Documentation
The target.nr file located in the TornadoBaseDirectory /target/config/bspname directory is the source of the online reference entries for target-specific information in our new BSP web site. For a description on how to view the target.nr reference files supplied with our product distributions, see the Tornado Getting Started manual. The target.nr file describes the supported board variations, the relevant jumpering, and supported devices. It also includes an ASCII representation of the board layout with an indication of board jumpers (if applicable) and the location of the ROM sockets.

References

• Tornado Getting Started Manual
• VxWorks User ‘s Guide
• Tornado BSP Developer’s Kit for VxWorks: User’s Guide (some times referred to as a porting guide)
• Tornado BSP Training Workshop – book 1 (see Wind River training web site for BSP class times)
• Wind River’s BSP web site

The Wind River logo is a trademark of Wind River Systems, Inc., and Wind River is a registered trademark of Wind River Systems. Other marks used herein are the property of the respective owners.

Technorati Tags: Ron Fredericks, Wind River, VxWorks, Board Support Package, BSP, Tornado, FTP, Bootp, TFTP, command shell, RARP, Network Stack, JTAG, N-wire, Ethernet, JTAG, UART, ROM

This entry was posted on Wednesday, November 21st, 2007 at 2:41 am and is filed under Component Technology, Embedded C/C++. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.