OAL Migration (Windows CE 5.0)

  • Article

Send Feedback

The OEM adaptation layer (OAL) is the layer of code between the Windows CE kernel and the hardware of your target device. For more information, see Developing an OEM Adaptation Layer.

This topic provides information about changes you must make to your OAL for it to be fully compatible with Windows CE 5.0. The changes are groupd by the Windows CE version for to which they apply.

Windows CE 5.0

For Windows CE 5.0, you can make the following optional changes to the OAL:

  • Migrate your existing OAL to a production-quality OAL.

    For more information, see Production-Quality OAL.

    If you have an existing OAL, you are not required to use the production-quality OAL or migrate to the new OAL model. If you have an OAL that works in previous versions of Windows CE, it will still work in Windows CE 5.0 with some minor modifications. For example, the DIRS files drive the structure so you can still give any name to the folders. Also, if you use any of the CSP libraries from earlier versions of Windows CE, you will need to adjust your build to use the new libraries. For more information about the new library structure, see BSP and CSP Directory Layout.

  • Implement the variable tick scheduler.

    For more information, see Implementation of the Variable Tick Scheduler.

Windows CE .NET 4.2 and later

For Windows CE .NET 4.2 and later, you must make the following changes to the OAL:

  • Implement the OEMCacheRangeFlush function in the OAL to resolve references in the kernel.

    You can implement the OEMCacheRangeFlush function by linking with the appropriate libraries or by implementing a version of the OEMCacheRangeFlush function that calls your existing FlushDCache, FlushICache, and ClearTLB functions.

  • Implement the SPI_GETPLATFORMVERSION IOCTL.

    SPI_GETPLATFORMVERSION is used in conjunction with the SPI_GETPLATFORMTYPE IOCTL to assign a version number to a run-time image. For more information, see Implementation of the SPI_GETPLATFORMVERSION IOCTL.

Windows CE .NET 4.0 and later

For Windows CE .NET 4.0 and later, you must make the following changes to the OAL:

  • Implement a variable system timer tick in the OAL.

    A variable system timer tick improves power management on your BSP. For implementation examples, see the sample BSPs. The variable system timer tick function is implemented in your OAL. For more information, see System Timer.

  • Set the x86 page tables to provide a valid OEMAddressTable structure.

    In Windows CE 5.0, the x86 page tables are set up in the same way as ARM page tables, requiring the x86 hardware platform to provide a valid OEMAddressTable structure back to the kernel. The OEMAddressTable defines virtual-to-physical mapping.

  • Update IRQ-to-SYSINTR mappings.

    The PCI bus driver requires the ability to obtain and manage the translations for SYSINTR and interrupt request (IRQ) values.

    The following table shows the functions to implement for the PCI bus driver. These functions are exposed through the OAL IOCTLs listed below.

    Function Description
    OEMTranslateIrq Takes an IRQ value and returns a logical interrupt, or SYSINTR, value. If the IRQ maps to more than one SYSINTR, the first mapping is returned.
    OEMTranslateSysIntr Takes a SYSINTR value and returns the corresponding IRQ.
    OEMRequestSysIntr Requests a new logical interrupt, SYSINTR, value for the specified IRQ. This sets up a new mapping in the OAL.
    OEMGetInterrupt Requests an IRQ value for the device location specified.

  • Implement the following OAL IOCTLs:

    Power Manager IOCTLs:

    VMINI IOCTLs:

    KITL IOCTLs:

    CEDDK IOCTLs:

    Filesys.exe IOCTLs:

    Processor IOCTLs:

    Other OAL IOCTLs:

  • Enable KITL in the BSP or enable KITL to migrate from Ethernet debugging (EDBG) to KITL. The following list shows how to do this:

    • Use the Halkitl.c file from a similar OS design.

      Configure function callback pointers to use the EDBG driver for your run-time image.

    • In your OAL, enumerate only KITL devices and any special debugging or other devices that must be set up by the OAL.

      After enumerating these devices, use the PCIReg function call in conjunction with IOCTL_HAL_INITREGISTRY to populate the registry with information on KITL and other debugging devices.

    • Call KitlInit or InitDebugEther, which calls KitlInit.

      Which you do depends on the Halkitl.c version you use. For more information about how to implement InitDebugEther, see the code example in Active and Passive KITL.

    If you enable KITL and your implementation does not work, even when all code is in place, check PLATFORM_STRING in your boot loader and OAL. The problem might be caused by a mismatch between the name in your boot loader and the name in your OAL. Microsoft recommends that you define PLATFORM_STRING somewhere in the header file or in Halkitl.c.

  • Support KITL transport.

    To support passive KITL, pass pCfgData->KitlTransport to the OAL. You can obtain this data from the Platform Builder user selections in the boot loader. Use it to decide on the argument to KitlInit.

    If your SDB has more than one Ethernet port, use one port for product Ethernet and another one for EDBG.

    If your standard development board (SDB) only has one Ethernet port, you can implement one of the following solutions to support the KITL transport:

    • A KITL-based debug Ethernet driver in your boot loader.

      Use the native Ethernet port for debugging and downloading, and then add virtual network miniport (VMINI) support above the debug Ethernet driver to implement Ethernet sharing. This allows both product and EDBG on the same Ethernet connection. For more information, see %_WINCEROOT%\Public\Common\Oak\Drivers\EthDbg\VBridge\Readme.txt.

    • An EDBG driver for downloading.

      Switch to serial debug from the IDE. This assumes that you have implemented the serial debug interface in your boot loader.

  • Enable interrupt service routines (ISRs).

    Your ISRs should call NKCallIntChain on shared interrupts and interrupts that are supported on installable ISRs. For details, see Installable ISRs.

  • Set up and initialize built-in devices.

    Populate the registry with the correct I/O resources information for all the built-in and debug devices on the target device. When the system boots, the bus enumerator enumerates the registry and loads all the built-in devices. For more information, see Bus Enumerator.

    I/O resource information includes memory windows such as MemBase and MemLen, I/O windows such as IoBase and IoLen, the interrupt request number (IRQ), and the SYSINTR value that the ISR returns.

    The initial state of the I/O Resource Manager is set in the registry and should indicate that resources used by the built-in devices are already in use. The I/O Resource Manager tracks the current resources available in the system and then manages all further I/O resource requests and allocations by bus drivers. For more information, see I/O Resource Manager.

  • Implement the dwReschedTime variable.

    The dwReschedTime variable has been added to the OAL to determine if the kernel should schedule a thread to run. This global variable stores the time, in ticks, when you must trigger a reschedule event. For more information, see System Timer.

  • (Optional) Add a hive-based registry.

    If your target device has persistent storage and it supports the suspend without memory refresh state, use a hive-based registry. Replace the RAM-based registry with the hive-based registry in your BSP, adjust the registry keys in your Platform.reg file, and implement a registry flushing strategy.

    For more information, see Hive-Based Registry and RAM-Based Registry.

  • (Optional) Remove CreateStaticMapping space.

See Also

Production-Quality OAL | Kernel Migration | Boot Loader Migration | BSP Migration | Migrating a Board Support Package | Debugging and Testing

Send Feedback on this topic to the authors

Feedback FAQs

© 2006 Microsoft Corporation. All rights reserved.