bspintroduction | Channel 9

Summary: A high-level overview of the BSP Development Process, Device Driver Development, Testing and Validation, and packaging an SDK to allow developers to create applications on your Windows CE-based device.

Creating a BSP is the initial development activity required for building a Windows CE-based device. You can develop a BSP on your own or start from a BSP provided by Microsoft or a third party. Furthermore, leveraging existing CPU or System-on-Chip (""SoC"") libraries can greatly reduce the amount of development work required.

Regardless of the starting point you choose, the development or adaptation processes for the boot loader and the OAL are almost the same. Because of this similarity, OAL and kernel work can both leverage the work done to develop the boot loader.

Overview of the BSP Development Process

Like many development tasks, the process for developing a BSP involves high-level and low-level tasks. For example, at the highest level, you must select the hardware platform, and at the lowest level, you must develop a boot loader and the OEM abstraction layer (OAL) for the kernel. The following illustration shows the high-level steps needed to develop the low-level software for a BSP.

@@Image("http://channel9.msdn.com/wiki/images/introdiag.gif", "BSP Development Process")@@

A list of BSP development prerequisites can be found in the "What do you need to create a BSP" (BSPCreate) article.

The BSP development process begins with the selection or development of the hardware platform that the BSP will target. Specifically, this process includes developing a board with a CPU that can run the Windows CE operating system (OS), selecting the peripheral devices that will interface with the device, and including the interfaces required to support BSP development and debugging. For example, you might not need to include support for serial connections on a device for consumers, but a serial connection is typically important for low-level software development. You should consider populating your device with a debug header that can interface to a debug board for development and that can also be depopulated before the device is used for production.

After you have identified and created the hardware platform, you must develop a BSP that will run Windows CE on the device. Often, you can modify a BSP from Microsoft or a third party, which will greatly reduce your BSP development work. The process of starting with a BSP from Microsoft is called BSP cloning. You can find information about this process in the Windows CE Help documentation. If a BSP is not available, you will have to develop one entirely on your own. Given the significant amount of work inherent in developing a BSP entirely on your own, Microsoft recommends that you start with a BSP from Microsoft or a third party.

Adapting a Microsoft or 3rd party BSP for the same chipset/""SoC"" is typically the fastest way to produce a new BSP. You will need to examine how the target platform differs from the reference implementation, and update the code accordingly. Often the boot loader and OAL will require minimal modification.

If there is no BSP available for the ""SoC"", the development process is more involved, although leveraging the CPU libraries can speed the process.

At this point, you move to the low-level development tasks by developing a boot loader that can reside in persistent memory on the device. The boot loader's primary function is to initialize enough of the hardware and CPU to allow the hardware to communicate with the development environment for downloading a Windows CE-based run-time image. More detail can be found in the "Bootloader Bringup" (BSPBootloaderBringup) article. You can extend the boot loaders functionality to be used for any other purpose that your device requires.

After a boot loader has been developed, you download it and write it into persistent memory on the device using the tools specified by the silicon vendor. You then start development work on the OAL portion of the BSP. Part of the OAL work consists of implementing the bootstrapping kernel functions required to start the Windows CE kernel. Developing the OAL is a step-by-step process of implementing the startup functions and implementing the code that will initialize the hardware on the device in preparation for running the Windows CE kernel. You can leverage or share many of the startup functions that are implemented in the boot loader during OAL development. Once you have developed, downloaded, and debugged the OAL, a minimal Windows CE kernel will be running on the hardware platform.

Further details of this process can be found in the "Board Bringup" (BSPBringup) article. For quality and security guidance, see the "Production Quality OAL" and "Writing a code secure BSP" (PQOAL and BSPSecurity) articles.

Platform Device Driver Development

Once the core BSP has been validated, you need to add support for the peripherals that you have chosen for the device. To accomplish this task, you have to iteratively add and debug the drivers for these peripherals one at a time. If you have multiple developers working on drivers, the drivers can be developed in a series and added to the BSP one at a time. Depending on what peripherals you have chosen, or if you are using a System-On-Chip (""SoC""), you can add drivers from Microsoft or from a third party. You can leverage these drivers as the starting point for each driver that you develop. For quality guidance, see "Production Quality Drivers" (PQD).

Typically, drivers for standard hardware on standard expansion busses require little modification and can be used as-is. Standard peripherals hardwired to the chipset may require manual resource assignment and setup.

If you are adapting a reference or 3rd party BSP examine the SoC-specific drivers, such as the video, audio or keypad drivers. These drivers rely on external hardware, codecs and controllers, which often differ between the reference platform and target hardware.

Naturally, drivers will need to be developed for any custom devices present in the target device. You can use the various sample drivers as starting points for your development.

Once the device drivers have been developed, you should have a BSP with an OAL and the drivers for each peripheral that you intend to support on the hardware platform. Next, you will plan and implement power management.

Power management is an important part of the driver and BSP development process. Once you have planned your power management system, which includes deciding to what extent your device will rely on battery power, you will use the Power Manager to help you implement those power management capabilities. Although power management is not the focus of this article, you can find documentation that explicitly covers power management in the "Writing a Power Efficient BSP" and "Writing Power Efficient Drivers" (BSPPower and BSPDriverPower) articles. There you will find details about how to make each peripheral driver power-management-aware, as well as how drivers interact with the Power Manager and OAL.

Testing and Validation

As you develop the OAL, bring up device drivers, and implement power management, you must test each component. The Windows CE Test Kit (CETK) provides a wide variety of tests to help you with this process. The validation process is documented in the "How you know you are done" (BSPExitCriteria) article. For information about the CETK, see Windows CE Help and the MSDN Library.

SDK Generation

The final steps in the BSP development process are to create a software development kit (SDK) and package the BSP into an .msi install file so that it can be installed by others. An SDK is a set of headers, libraries, connectivity files, run-time files, OS design extensions, and Help documentation that developers use to write applications for a specific OS design. The contents of an SDK allow developers to create and debug an application on the run-time image built from your OS design. Windows CE provides an SDK Wizard to create an SDK from your BSP and an Export Wizard to package your BSP into an .msi install file.

Conclusion

All Windows CE device development begins by creating a targeted BSP for the device. The BSP also becomes the foundation for applications that run on the device by exporting an SDK from the BSP. Because of this, you must be sure that the high level BSP process is followed and the low-level function calls for the boot loader and kernel are implemented appropriately. With the information from this article, you should have a fundamental understanding of the BSP process and what the development effort is to get a boot loader and kernel running on a device.

Go up to Big Book of BSP

Thank you for contributing to this BSP Wiki. To ensure your comments and concerns receive proper exposure, include bspwiki""@""microsoft"".""com when providing feedback or topical suggestions.