BSP Migration Guide
Other versions of this page are also available for the following:
.gif "A hyphen indicates that the information in this topic is not relevant for this platform, or that the platform does not support the API that is listed.")
.gif "A checkmark indicates that the information in this topic is relevant for this platform, and that any API listed is also supported on this platform.")
8/27/2008
In Windows Embedded CE 6.0, the kernel and OEM code are divided into the following three components:
Oal.exe
This contains the startup code and the OEM adaptation layer (OAL) implementation. This component was previously named Kern.exe.
You can statically link the Kernel Independent Transport Layer (KITL) to create OalKitl.exe, but this model is being deprecated in Windows Embedded CE 6.0. OalKitl.exe was called KernlKitl.exe in previous versions of Windows Embedded CE.
KernKitlProf.exe has no equivalent in Windows Embedded CE 6.0. You no longer need to build a profiling OAL over a non-profiling OAL. If your OAL supports profiling, you should always include it in the final, shipping image. The kernel detects and uses OAL profiling if it is available. For more information, see Implementing Profiling Support in the OAL.Kernel.dll
This contains the OAL-independent kernel implementation.Kitl.dll
This contains the platform-specific KITL support.Note
Microsoft recommends that OEMs move KITL support out of the OAL and into Kitl.dll. All Microsoft sample board support packages (BSPs) will follow this model.
The goals for this design are to:
- Minimize OAL changes
- Clearly define the functions that the OAL can and cannot use
- Provide version information between components to provide forward compatibility
This model provides the following advantages:
- Allows Microsoft to update the kernel for retail devices without going through the OEM because the kernel is no longer dependent on the OAL.
- Simplifies the debugging process with an instrumented kernel. You only need to include a new instrumented Kernel.dll into the release directory and then re-make the run-time image.
- Provides OEMs with a binary-only version of the platform, which they can give to their customers.
- Makes loadable KITL possible.
- Enables all communication between the OEM code and the kernel to take place through well-defined interfaces.
For more information about BSP processes and changes in Windows Embedded CE 6.0, see BSP Implementation Guide.
For more information about the data structures you can use to share information between the kernel and the OAL, see BSP Data Structures.
BSP Catalog File Migration
For more information about how to migrate a Catalog item (.cec) file to the new format, see Migrating a Catalog Item.
BSP Migration Scenarios
The BSP migration guide covers the following migration scenarios:
- Scenario 1: Separate kernel, OAL, and KITL
For more information, see How to Separate the Kernel, OAL, and KITL.
In this scenario, you need to adopt the new OAL directory structure. In Windows Embedded CE 6.0, the OAL directory structure in Windows CE 5.0 was modified to reflect the separation of the OAL, KITL, and the kernel. Microsoft recommends that OEMs adopt the new directory structure when migrating their BSPs to Windows Embedded CE 6.0. The new directory structure is optional.
When you create a new directory for the migrated BSP, create it under the PLATFORM directory. For example, create a new BSP directory located at %_WINCEROOT%\PLATFORM\<My_Migrated_BSP>. For more information, see Windows Embedded CE 6.0 BSP Directory Structure. - Scenario 2: Separate kernel and OAL
For more information, see How to Separate the Kernel and OAL and Link KITL to the OAL.
In this scenario, you need to leave KITL statically-linked to the OAL. You should not adopt the new directory structure.
Microsoft recommends that you follow the first migration scenario although the second scenario requires less migration effort. In both cases, the separation between the kernel, OAL, and KITL is made apparent to the OEM by linking to migration stub libraries.