¦ Modifying and adapting BSPs and boot loaders for specific target devices
¦ Understanding memory management and layout
¦ Enabling power management in a BSP
To complete the lessons in this chapter, you must have the following:
¦ At least some basic knowledge about Windows Embedded CE software development.
¦ A thorough understanding of hardware architectures for embedded devices.
¦ Basic knowledge about power management and how to implement it in drivers and applications.
¦ A development computer with Microsoft Visual Studio® 2005 Service Pack 1 and Platform Builder for Windows Embedded CE 6.0 R2 installed.
Lesson 1: Adapting and Configuring a Board Support Package
The BSP development process for a new hardware platform typically begins after performing functional tests of the hardware by using a ROM monitor, by cloning an appropriate reference BSP, followed by implementing a boot loader and the core OAL functions to support the kernel. The goal is to create a bootable system with the least possible amount of custom code. You can then add device drivers to the BSP to support integrated and peripheral hardware and expand the system by implementing power management and other advanced operating system (OS) features according to the capabilities of the target device.
After this lesson, you will be able to:
¦ Identify and locate the content of a PQOAL-based Board Support Package.
¦ Identify hardware-specific and common-code libraries.
¦ Understand how to clone a BSP.
¦ Adapt a boot loader, OAL, and device drivers.
Estimated lesson time: 40 minutes.
Board Support Package Overview
A BSP contains all the source code for the boot loader, OAL, and device drivers for a given platform. In addition to these components, the BSP also contains build and system configuration files, as illustrated in Figure 5- 1. The configuration files are not included in the actual run-time image, yet they are part of the BSP package to specify source code files, memory layout, registry settings, and other aspects to compile and build the run-time image, as explained in Chapter 2, 'Building and Deploying a Run-Time Image.'
Figure 5-1 Components of a BSP in relationship to the remaining elements of Windows Embedded CE 6.0
According to Figure 5-1, BSP development includes the following main components:
¦ Boot loader Runs when powering up or resetting the device. The boot loader is responsible for initializing the hardware platform and passing execution to the operating system.
¦ OEM adaptation layer (OAL) Represents the core of the BSP and is the interface between the kernel and the hardware. Because it is linked directly to the kernel, it becomes part of the kernel in a CE run-time image. Some of the core kernel components are directly dependent on the OAL for hardware initialization, such as the interrupt handling and timer handling for the thread scheduler.
¦ Device drivers Manage the functionality of a particular peripheral and provide an interface between the device hardware and the operating system. Windows Embedded CE supports a variety of driver architectures based on the interfaces they expose, as explained in Chapter 6, 'Developing Device Drivers.'
¦ Configuration files Provide the necessary information to control the build process and plays a key role in the design of a platform's operating system. Typical configuration files included in BSPs are Sources files, Dirs files, Config.bib, Platform.bib, Platform.reg, Platform.db, Platform.dat, and catalog files (*.pbcxml).
Adapting a Board Support Package
It is generally a good idea to jump start the BSP development process by cloning an existing reference BSP instead of creating a BSP from scratch. Even if you must develop a BSP for an entirely new platform with an entirely new CPU, it is still recommended to clone a BSP based on a similar processor architecture. In this way, you can reduce BSP development time by reusing hardware-independent code from the existing BSP and shorten future migration cycles to new Windows Embedded versions as they become available on the market. Migrating a proprietary BSP design is generally much harder to do than migrating a PQOAL-based design because the proprietary BSP cannot benefit from those PQOAL code portions that Microsoft implicitly migrates and tests as part of the new operating system version.
Adapting a board support package includes the following sequence of steps:
¦ Cloning a reference BSP.
¦ Implementing a boot loader.
¦ Adapting the OAL functions.
4. Modifying the run-time image configuration files.
5. Developing device drivers.
Cloning a Reference BSP
Platform Builder includes a wizard that facilitates cloning a reference BSP. This wizard copies the entire source code of the selected reference BSP to a new folder structure so that you can customize the BSP for the new hardware without affecting the reference BSP or other BSPs in the %_WINCEROOT% folder hierarchy. Figure 5-2 illustrates how to start the BSP Cloning Wizard in Microsoft Visual Studio 2005 with Platform Builder for Windows Embedded CE 6.0.
Figure 5-2 Cloning a BSP in Visual Studio 2005
When cloning a BSP, you have to choose a new name for this new set of files. The name that you choose for the platform must match the name of the folder on your hard drive. As mentioned in the previous chapter, the build engine is based on a command-line script and is not compatible with spaces in folder names. Therefore, the BSP's name must not include white spaces. You can use the underscore (_) character instead.
