Windows Embedded CE 6.0 KITL in PQOAL


In Windows Embedded CE 6.0, the kernel and OEM code are divided into the following three components:

In previous versions the OAL and the Kernel where linked together in one executable (kern.exe) which would possibly include KITL support (in this case the executable was kernkitl.exe).

From Windows CE 5.0 Microsoft introduced the concept of Production Quality OAL : one of the benefits of this design is that you can take advantage from a set of libraries which can be shared among specific BSP’s.

For example, if you look at %_WINCEROOT%\PLATFORM\COMMON\SRC tree you can find a directory structure like the following:

  • COMMON: common code which is processor architecture independent.
  • ARM, MIPS, SHX, X86: code which depends on the specific processor architecture but not on the specific implementation.
  • SOC: code which depends on the specific processor

With this structure the single BSP should contain only the code which is really specific for the specific board.

The PQOAL architecture extends even to KITL: in this scenario KITL.dll is made up essentially by the following components:

  • BSP specific KITL code (built from %_WINCEROOT%\PLATFORM\<BSP>\KITL)
  • KITL specific device code (built from %_WINCEROOT%\PLATFORM\<BSP>\SRC\COMMON\ETHDBG) (see NOTE 1)
  • Common OAL KITL library (oal_kitl.lib, built from %_WINCEROOT%\PLATFORM\COMMON\SRC\COMMON\KITL)
  • KITL core library (kitlcore.lib, built from %_WINCEROOT%\PRIVATE\WINCEOS\COREOS\NK\KITL)



1. OEMInit()

This function, called by the kernel, invokes KITLIoctl (IOCTL_KITL_STARTUP, NULL, 0, NULL, 0, NULL) which simply calls OEMKitlStartup()

2. OEMKitlStartup()

The function sets up:

  • KITL device name
  • OAL_KITL_ARGS structure: retrieved from data – normally called BSP_ARGS (see NOTE 1)   setup by the boot loader since the KITL device is normally the same used by the boot loader to download the OS image, or hardcoded in the OAL. The structure contains:
    • KITL flags describing some KITL functionalities (use interrupt or polling, etc.)
    • Location of the KITL hardware device in terms of its interface, bus number, and logical location
    • Communication parameters: for a serial interface baud rate, parity, etc. ; for an ethernet interface MAC, IP, …

These information are passed to OALKitlInit with a NULL terminated array of OAL_KITL_DEVICE structures – normally called g_kitlDevices (see NOTE 1); each element defines one of the available KITL devices on the platform; each device is represented by its type (OAL_KITL_TYPE_SERIAL, OAL_KITL_TYPE_ETH,…), physical location and by a structure which defines the function pointers to handle the KITL device according to the device type: for example if KITL device is an ethernet chip the structure holds a pointer to an OAL_KITL_ETH_DRIVER structure. These entry points are typically shared among KITL and the boot loader and are defined in %_WINCEROOT%\PLATFORM\<BSP>\SRC\COMMON\ETHDBG.

3. OALKitlInit(LPCSTR deviceId, OAL_KITL_ARGS *pArgs, OAL_KITL_DEVICE *pDevice)

This function, if KITL flags include OAL_KITL_FLAGS_ENABLED, calls OALKitlFindDevice(DEVICE_LOCATION *pDevLoc, OAL_KITL_DEVICE *pDevice) which checks if the KITL device specified in OAL_KITL_ARGS is supported – i.e. it is present in the OAL_KITL_DEVICE array; if this is the case KitlInit is called.

4. KitlInit(BOOL fStartKitl)

This function, if fStartKitl is TRUE (which means that OAL_KITL_FLAGS_PASSIVE flag is not set) calls StartKitl(TRUE).

5. StartKitl (BOOL fInit)

This function calls OEMKitlInit to initialize a KITLTRANSPORT structure;


This function calls the KITL device initialization function according to the KITL device type (for example OALKitlEthInit if the device is OAL_KITL_TYPE_ETH or OALKitlSerialInit if the device is OAL_KITL_TYPE_SERIAL). The function initializes the KITL hardware and fills the KITLTRANSPORT structure with pointers to functions which are used to perform several actions (for example send or receive a KITL frame) over the specific transport: remember that KITL stands for Kernel Independent Transport Layer so using the KITLTRANSPORT pointers to functions abstracts the transport from the specific device.

7. The control is back to StartKitl which tries to connect to the desktop (i.e. Platform Builder). If the connection is established the function tries to enable the interrupt handling for the KITL device to achieve a better performance. The interrupt handler is not used if you specified KITL_SYSINTR_NOINTR in KITLTRANSPORT::Interrupt or if you specified that KITL has to run in passive mode.

8. Back from StartKitl the KITL has been setup and the control is finally back to OEMInit the to the kernel which will continue to boot the operating system.


With the PQOAL design the BSP specific code required to setup KITL may be reduced to implement OEMKitlStartup and the functions used to communicate with the actual KITL device. In some case you may need to customize the common KITL library: for example CEPC KITL adds to the common KITL library the support for PCI since the ethernet device on an x86 board will be probably interfaced on that bus

 NOTE 0: This post is about KITL initialization at system startup. When KITL reinitializes after a suspend/resume cycle some steps are skipped or performed in a different way

 NOTE 1: This name is typically used but it is not mandatory

This entry was posted in Windows Embedded CE and tagged . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s