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.
BSP Folder Structure
To increase code reusability, PQOAL-based BSPs feature a common architecture and corresponding folder structure that is consistent across processor families. Due to this common architecture, large portions of the source code can be reused regardless of hardware-specific BSP requirements. Figure 5-3 shows the typical BSP folder structure and Table 5-1 summarizes the most important BSP folders.
Figure 5-3 Folder structure of a typical BSP
You can use the environment variable %_TARGETPLATROOT% in the build window to locate the path of the BSP being used in the current OS design (Open Release Directory in Build Window option on the Build menu in Visual Studio).
Table 5-1 Important BSP folders
| Folder | Description |
|---|---|
| Root Folder | Contains configuration and batch files. The two most important files for developers are as follows: |
| ■ Sources.cmn Contains macro definitions that are common across the entire BSP. | |
| ■ <BSP Name>.bat Sets the default BSP environment variables. | |
| CATALOG | Contains the BSP catalog file in which all the components of the BSP are defined. This file is used in the OS design stage to add or remove BSP features. Chapter 1, "Customizing the Operating System Design," discusses how to manage catalog items. |
| CESYSGEN | Contains the Makefile for the Sysgen tool. Configuring a BSP does requires no changes to this directory. |
| FILES | Contains the build configuration files, such as .bib, .reg, .db, and .dat files. |
| SRC | Contains the platform-specific source code that you must adapt according to the PQOAL model, which divides the code between platform-specific and common components per CPU type. |
| COMMON | Exists under the Platform directory and contains most of the BSP source code. It consists of a common set of processor specific components. The BSP links to libraries in this folder, generated during the build process. These are libraries for processor-based peripherals as well as processor-specific OAL parts. If the hardware uses a CPU from the family of supported processors, then most of these libraries can be reused without modification. |
Platform-Specific Source Code
The most important platform-specific source code that you must adapt as part of your BSP is for the boot loader, the OAL, and the device drivers. You can find the corresponding source code underneath the Src folder in the following subdirectories:
■ Src\Boot loader Contains the boot loader code. However, if the boot loader relies on BLCOMMON and related libraries, then only the basic hardware- specific part of the boot loader is located in this directory. The reusable boot loader code is available in the Public folder (%_WINCEROOT%\Public \Common\Oak\Drivers\Ethdbg) and linked as libraries to the BSP part. Chapter 4, "Debugging and Testing the System," introduces the static libraries that facilitate boot loader development.
■ Src\Oal Contains the bare minimal amount of code that is specific to the hardware platform. The majority of the OAL code is located in %_WINCEROOT%\Platform\Common, divided into hardware-independent, processor-family-related, chip-set-specific and platform-specific groups. These code groups provide most of the OAL functionality and are linked to the platform-specific parts as libraries.
■ Src\Common and Src\Drivers Contains the driver source code, organized in different categories to facilitate maintenance and portability. These categories are typically processor-specific and platform-specific. The processor-specific component is located in the Src\Common directory and requires no modifications when adapted to new hardware based on the same processor family.
Implementing a Boot Loader from Existing Libraries
Several aspects have to be considered when adapting a boot loader for a new platform, including: