WinCE 6.

0 MOC
Introduction
Victor Lin
Field Application Engineer
SYNNEX INTERNATIONAL CORP.
(02)25063320-2231
victorlin@synnex.com.tw

SYNNEX
Overview
Toolkit.
OS Architecture.
Memory Architecture.
Driver Development.
Application Development.

SYNNEX
Toolkit

SYNNEX
Runtime Image of the CE 6.0 Operating System

Application Windows CE Custom Internet Client

Layer Application Application Services

Application Services

NK.BIN
OS Layer
Kernel

OEM Adaptation Layer (OAL)

OEM Layer Drivers
(BSP) Process Specific Definition Files

SYNNEX
Visual Studio 2005 Platform Builder
Solution
Platforms
Connectivity
Status

Connectivity
Device Name

Code
Editor
Project
Tree

Debug tool
status
indicators

Output
Selection Tabbed Output
Windows

SYNNEX
Visual Studio 2005 Platform Builder

CE OS Design – Major Menu Options

y Project – Creation or management of projects
y Build – Build options for the OS Design
y Debug – Access to Debug Options
y Target – configuration and specifics of the target device.
y Tools – Includes the CE Device Emulator Manager

SYNNEX
Building the Run-time Image

Build Æ Build TrainingOSDesign

SYNNEX
Building the Run-time Image

Builds can take an extended amount of time to complete

Zero errors on a build is the goal

SYNNEX
CE 6.0 Build Steps

Pre-Sysgen Build 0

Build Demo Tool

(blddemo.bat)
Sysgen 1

Post-Sysgen Build 2

Build Release Dir 3

Make Run-Time Image 4

Build process consists of 5 major phases

y Initial step should not normally be used
Build Demo tool (Blddemo.bat)
y Interface to unified build system
SYNNEX
Build Phases

1 System Generation - SYSGEN

Filters and combines modules and
components based on OS Design
1 settings
2
2 Post-Sysgen Build – BUILD
Builds Source Code for the BSP and
3 subprojects
3 Build Release Directory - BUILDREL
Copies files into the Flat Release
Directory
4 Make Run-time Image – MAKEIMG

4 Generates the OS Run-Time Image

from the files in the Release Directory

SYNNEX
System Generation Phase

Pre-Sysgen Build 0

Build Demo Tool

(blddemo.bat)
Sysgen 1

Post-Sysgen Build 2

Build Release Dir 3

Make Run-Time Image 4

Sysgen
y Generates system configuration based on chosen
Catalog items in OS design

SYNNEX
System Generation Phase

Complete header System-

and source code specific
files header files

Complete Linked
system libraries SYSGEN libraries

Module Specific .def

definitions (.def) files

SYNNEX
System Generation Phase

%__PROJROOT%\CESYSGEN

MAKEFILE

yyy_lib.lib zzzz.lib

aaa.Exe
aaa.Dll

SYNNEX
 System Generation Phase

Filtering
y Uses @CESYSGEN comment tags to filter files based
on component settings
y Run from inside
%__PROJROOT%\CESYSGEN\MAKEFILE

// @CESYSGEN IF [!]<Component> [[OR | || | AND | &&] [!]Component]

// @CESYSGEN ELSE
// @CESYSGEN ELSE IF [!]<Component> [[OR | || | AND | &&] [!]Component]
// @CESYSGEN ELSEIF [!]<Component> [[OR | || | AND | &&] [!]Component]
// @CESYSGEN ENDIF

SYNNEX
System Generation Phase

Filtering

Input files from Output directory in

%_COMMONPUBROOT% %_PROJECTROOT%
Sdk\Inc\*.* Cesysgen\Sdk\Inc
Oak\Inc\*.* Cesysgen\Oak\Inc
Ddk\Inc\*.* Cesysgen\Ddk\Inc
Oak\Files\Common\*.* Cesysgen\Oak\Files

SYNNEX
Post-Sysgen Build Phase

Pre-Sysgen Build 0

Build Demo Tool

(blddemo.bat)
Sysgen 1

Post-Sysgen Build 2

Build Release Dir 3

Make Run-Time Image 4

Post-Sysgen Build Phase

y Compile source code in BSP and user subprojects

SYNNEX
Post-Sysgen Build Phase

Compile platform source code

y Uses Build.exe tool
y Compiles and links source code in
$(_WINCEROOT)\PLATFORM\COMMON
y Compiles and links source code in BSP
Bootloader, drivers, OAL etc
y Compiles and links source code in subprojects
y Uses filtered OS components
Libraries, header files

SYNNEX
Build Release Directory Phase

Pre-Sysgen Build 0

Build Demo Tool

(blddemo.bat)
Sysgen 1

Post-Sysgen Build 2

Build Release Dir 3

Make Run-Time Image 4

Build Release Directory Phase (BUILDREL)

y Copy output files to staging directory in preparation for
making OS run-time image

SYNNEX
Build Release Directory Phase

Copy files to release directory

y Copies OS binaries and configuration files from the OS
design directory to the release directory
y Copies project binaries and configuration files from the
OS design directory to the release directory
y Copies BSP binaries and configuration files from the BSP
directory to the release directory

SYNNEX
Build Release Directory Phase

Binaries automatically copied to release directory when built if

WINCEREL environment variable is set
y No need to run entire buildrel phase for a single changed binary
y Must run buildrel at least once
Hard link vs. xcopy
y Copy performed using hard link by default
Major performance enhancement
y Do not edit files directly in release directory
Some editors will cause original source file to change
Unexpected file corruption
y Force xcopy with BUILDREL_USE_COPY environment variable if
necessary

SYNNEX
Make Run-Time Image Phase

Pre-Sysgen Build 0

Build Demo Tool

(blddemo.bat)
Sysgen 1

Post-Sysgen Build 2

Build Release Dir 3

Make Run-Time Image 4

Make Run-Time Image Phase (MAKEIMG)

y Create operating system image

SYNNEX
Make Run-Time Image Phase

Merges release folder files to create the Windows CE image

y Based on a set of configuration files
Process
y Merge configuration files:
All .BIB files into CE.BIB
All .reg files into REGINIT.INI
All .dat files into INITOBJ.DAT
All .db files into INITDB.INI
y Compress reginit.ini in a binary registry file (DEFAULT.FDF)
y Replace resources in .exe and .dll for language adaptation
y From ce.BIB, combine binaries and files into a Windows CE image
(NK.BIN)

SYNNEX
Build Phases

Change code Change Device Add New Item Change code

in BSP Memory from Catalog in subproject
Layout

Sysgen No No Yes No

Post-Sysgen Build Yes Maybe Yes Yes

Build Release Dir Maybe Yes Yes Maybe

Make Run-time Image Yes Yes Yes Yes

Not all build steps must be performed on every change

y These are guidelines only
y Efficient use of build steps comes only with experience

SYNNEX
Build Types

debug build - a run-time image that usually includes

debug information
release (retail) build - a run-time image that does not
include debug messages that are used during the
development process.
ship – the final product that will be shipped to customers
that contains no debug code. Also some errors are
suppressed that are displayed during the development
process.

SYNNEX
The Build Tool Of The
Build System

SYNNEX
Build.exe – The Build Tool

Build.exe \MyProj
DIRs DIRS
\Proj1
Sources
Nmake.exe Makefile
Sources

Build.Exe parses DIRS and SOURCES to determine

what to build, then calls NMake
NMake.exe uses the data in Sources (via a makefile) to
determine how to build

SYNNEX
 DIRS Files

DIRS
y Contains a list of “project subdirectories”
y Text file that lists subdirectories containing other DIRS or SOURCES
files
y BUILD.EXE will read the contents of DIRS files to determine what
subdirectories to enter
y Supports * wildcard
DIRS=\
Display \
Mouse \
Keyboard \

SYNNEX
SOURCES

SOURCES is the text file that is included into makefile.def to

provide target specific information to the build

MAKEFILE

Local MAKEFILE.DEF
%_MAKEENVROOT%
Project
Folder

SOURCES

SYNNEX
SOURCES

SOURCES
y List of source code files for the project
TARGETNAME
y Name of output target (without extension)
TARGETTYPE
y PROGRAM – (.EXE) Application
y DYNLINK – (.DLL) Dynamic Link Library
y LIBRARY – (.LIB) Static library

SYNNEX
SOURCES

TARGETLIBS
y List of libraries to include in the target
Not used when TARGETTYPE=LIBRARY
Typically used for import libs from DLLs
SOURCELIBS
y List of source libraries to include in target
RELEASETYPE
y Indicates where build output file should be placed
LOCAL, OAK, PLATFORM

SYNNEX
SOURCES

POSTLINK_PASS_CMD
y Specifies a command to run after link completes
Usually a BAT file, often useful for copying raw data files to
%_FLATRELEASEDIR% as there is no custom BUILDREL
support for PBPXML projects
PRELINK_PASS_CMD
y Specifies a command to run BEFORE linking the final
output

SYNNEX
SOURCES

Visual Studio 2005 contains SOURCES editor

y Right click on subproject and select Properties
y Most SOURCES functionality exposed

SYNNEX
MAKEFILE.DEF

Default MAKE rules for most aspects of the build

Provides standard rules for various types of targets
Includes project SOURCES file
Reduces amount of MAKEFILE “code” needed for each
project
Located in %_MAKEENVROOT%
y %_WINCEROOT%\public\common\OAK\misc

SYNNEX
SOURCES.CMN

Common SOURCES file settings applied to all

SOURCES projects in a sub folder (listed in a DIRS file)
Placed at root of DIRS tree
y Build.exe will walk back up directories until no parent
DIRS is found and look for SOURCES.CMN in the folder
with the top level DIRS file
Commonly used in BSPs and PUBLIC folders
y _COMMONPUBROOT
y __PROJROOT
y _ISVINCPATH
y _OEMINCPATH

SYNNEX
Mapping the IDE to the Command Line

Build Menu
y Build Solution
blddemo –q
y Rebuild Solution
blddemo clean –q
y Build <OS Design project name>
blddemo -q
y Rebuild <OS Design project name>
blddemo clean -q
y Copy Files to Release Directory
buildrel
y Make Run-Time Image
makeimg

SYNNEX
Mapping the IDE to the Command Line

Build | Advanced Build Commands Menu

y Sysgen
blddemo –q
y Clean Sysgen
blddemo clean –q
y Build and Sysgen Not Recommended
blddemo
y Rebuild and Clean Sysgen Not Recommended
blddemo clean cleanplat -c
y Build Current BSP and Subprojects
blddemo –qbsp
y Rebuild Current BSP and Subprojects
Blddemo –qbsp -c

SYNNEX
Mapping the IDE to the Command Line

Targeted Build – BSP

y Build
set wincerel=1&&build
y Rebuild
set wincerel=1&&build -c
y Sysgen
SysgenPlatform %_TARGETPLATROOT% preproc&&SysgenPlatform %_TARGETPLATROOT% postproc

y Build and Sysgen

blddemo –qbsp
y Rebuild and Sysgen
blddemo –qbsp -c

SYNNEX
Mapping the IDE to the Command Line

Targeted Build – Subproject

y Applies to all sources subprojects
Includes sources subprojects in BSP
y Build
Set wincerel=1&&build
y Rebuild
Set wincerel=1&&build -c

SYNNEX
Mapping the IDE to the Command Line

Build | Global Build Settings

y Applies to builds initiated from the IDE menu
y Modifies build behavior
Copy Files to Release Directory after Build
Make Run-Time Image After Build
Build | Targeted Build Settings
y Applies to targeted builds initiated from the Solution
Explorer
y Modifies build behavior
Make Run-Time Image After Building

SYNNEX
Downloading the Run-time Image

Configuration – Connectivity Options

SYNNEX
Downloading the Run-time Image

Configuration – Connectivity Options

SYNNEX
Downloading the Run-time Image

Download – Attach Device

SYNNEX
Downloading the Run-time Image

Note that during the download, the directory for the

specific runtime image NK.BIN file is shown

SYNNEX
Downloading the Run-time Image

The downloaded NK.BIN file will be loaded by the

Target Device and the CE desktop will appear.

SYNNEX
Testing and Debugging the Run-time Image

After deploying the Run-time image,

CE 6.0 offers a wide choice of testing
and debug tools.
y Debug windows in Visual Studio
y Remote Tools
y Program launch options

SYNNEX
Debug Windows

Debug Windows – CE 6.0 uses the standard Visual

Studio debug windows and offers the full compliment of
debug functionality

SYNNEX
Program Launch Options

Command Line
y RUN from the Target Device’s Start Button.
Target Control Window
s explorer
Target | Run Programs

SYNNEX
Remote Tools

Remote Zoom Tool

Remote File Viewer
Remote System Information Tool
Remote Spy Tool
Remote Performance Monitor
Remote Kernel Tracker

SYNNEX
CE 6.0 Directory
Structure

SYNNEX
Environment Variables in the Build

%_WINCEROOT% - Root of the Windows CE build install

y Typically C:\WINCE600
%_PUBLICROOT% - %_WINCEROOT%\PUBLIC
%_PLATROOT% - %_WINCEROOT%\PLATFORM
Many others
y Use ‘set’ in a command prompt build window to see a list
of the environment variables currently set.

SYNNEX
CE Development System Directory Structure

Main CE 6.0 Directories

y C:\WINCE600\OSDesigns
y C:\WINCE600\OTHERS
y C:\WINCE600\PLATFORM
y C:\WINCE600\PUBLIC
y C:\WINCE600\SDK
y C:\WINCE600\PRIVATE

SYNNEX
Directory Structure

OSDesigns Directory
y Located at the path
%_WINCEROOT%\OSDesigns
y Contains OS Design projects
and subprojects

SYNNEX
\WINCE600\PLATFORM

The PLATFORM Directory

y Is located at the path
%_WINCEROOT%\PLATFORM
y Is different for different hardware
platforms
y Contains Hardware Platform-specific
Board Support Platform (BSP) files
y Contains subdirectories that each
represent a Windows CE–specific
platform adaptation

SYNNEX
\WINCE600\PUBLIC

The PUBLIC Directory

y Contains a set of components
and configurations that are hardware
platform independent.
y Is located at the path
%_WINCEROOT%\PUBLIC

SYNNEX
\WINCE600\PRIVATE

Private Directory
y Option at installation
Agree to separate Shared Source license
Includes full Kernel source code among others
y Can ship modified versions of the private code with your
product
y Premium (“Almost everything”) Source available
GWES components
Filesys components
Others

SYNNEX
\WINCE600\PRIVATE

The Private Directory

y located at
%_WINCEROOT%\Private
y Contains Premium Shared Source
if available

SYNNEX
\WINCE600\SDK

The SDK Directory is located at the path

%_WINCEROOT%\SDK
Contains tools to support Platform Builder
Processor compilers
Development tools
Miscellaneous utilities

SYNNEX
\WINCE600\Others

The Others Directory is located at the path

%_WINCEROOT%\OTHERS and contains subdirectories:
y ATL8
y DOTNETV2
y EDB
y SQLCE20
y VISUALSTUDIO

SYNNEX
CE Development System Directory Structure

Visual Studio Directories

y Visual Studio PB Plug-in Dir:
C:\Program Files\Microsoft Platform
Builder\6.00

y Visual Studio SmartDevice Dir:

C:\Program Files\Microsoft Visual Studio
8\SmartDevices

y Common Shared Files:

C:\Program Files\Common Files\Microsoft Shared

SYNNEX
CE Development System Directory Structure

Project Default Directories

y Visual Studio 2005 Default OS Projects Dir
C:\WINCE600\OSDesigns

y Visual Studio 2005 Code Top Level Projects Dir

C:\Documents and
Settings\LoginName\
My Documents\Visual Studio
2005\Projects

SYNNEX
Board Support
Package

SYNNEX
BSP Overview

Acronym Review
y OEM - Original Equipment Manufacturer
y OAL - OEM Adaptation Layer
y BSP - Board Support Package
y KITL – Kernel Independent Transport Layer

SYNNEX
BSP Overview

What does a BSP contain?

y Bootloader - Initializes hardware and launches the
operating system
y OAL – Hardware specific routines supporting OS kernel
for interrupt handling, memory mapping etc
y Drivers for custom hardware devices not already
supported by Platform Builder
y Configuration files
y Requires circuit level design information

SYNNEX
BSP Overview

PLATFORM Directory
Contains all BSPs
y Microsoft sample reference platforms
y Third party platforms
y Your BSP
Common Directory
y Source code for libraries of routines available for use by
BSPs
y Contains implementations for many BSP requirements
y No platform specific dependencies

SYNNEX
Platform Common Code Of
Board Support Package

SYNNEX
Platform Common Code

Architecture
Implemented in \WINCE600\PLATFORM\COMMON
y Organized by CPU dependency and function
Exposed to BSP as libraries
y Referenced with _PLATCOMMONLIB in sources file
y _PLATCOMMONLIB = (_PLATFORMROOT)\common\lib
y BSP links to individual libraries as needed

SYNNEX
Platform Common Code

Organization
Common Code
y \WINCE600\PLATFORM\COMMON\SRC\COMMON
y No CPU dependencies
y CPU independent modules, e.g.
• bootloader framework
• kitl
• PCI
• interrupt framework
• timer framework

SYNNEX
Platform Common Code

Organization
CPU Architecture Specific
y \WINCE600\PLATFORM\COMMON\SRC\<arch>
ARM, MIPS, SHX, X86
y May be further divided into sub architecture and common code
y Contains routines that are common to all CPUs in a particular
architecture/family
y CPU architecture dependent modules, e.g.
• cache routines
• abort handlers
• memory map support
• architecture specific interrupt support

SYNNEX
Platform Common Code

Organization
System On Chip (SOC) Specific
y \WINCE600\PLATFORM\COMMON\SRC\SOC\<soc_vendor_version>
E.g. PXA27X_MS_V1

y Contains routines that support specific peripherals and

CPU resources in a particular SOC
y Most CPU specific Common code is located in this area
y Supposed to be hardware implementation independent

SYNNEX
Platform Common Code

Documentation
Header Files
y \WINCE600\PLATFORM\COMMON\INC\
#include <oal.h>
Platform Builder Documentation
Bringing Up a Hardware Platform
Developing a Board Support Package
Developing an OEM Adaptation Layer
Production-Quality OAL
Source code
y Always the best documentation

SYNNEX
Platform Common Code

Using the Common code

Leverage an existing BSP that uses the Common code
y Some Common code implementations dictate
architecture of other BSP components
y Easier to implement with working example
Implement BSP specific callbacks
y BSP has interdependencies with Common code
Reference individual Common libraries in sources file
TARGETLIBS=$(TARGETLIBS) \
(_PLATCOMMONLIB)\$(_CPUINDPATH)\oal_cache_pxa27x_ms_v1.lib \

SYNNEX
BSP Components Of Board
Support Package

SYNNEX
BSP Directory Structure

CATALOG - Contains the catalog file

that exposes the BSP to the Platform
Builder IDE
CESYSGEN – Contains configuration
files used during SYSGEN phase
FILES – Contains platform
configuration files including registry
and BIB files
SRC - Contains source code for BSP

SYNNEX
Bootloader

The Bootloader is the first software component that runs

on a target hardware device
Purpose
y Initialize hardware
y Perform any device specific action that needs to occur
prior to booting the operating system
y Load the operating system image into memory
y Jump to the operating system entry point
Typically implemented as a separate component
y Will have its own .bib file

SYNNEX
Bootloader

Each bootloader is unique

WindowsCE does not impose any restrictions or requirements on
loader code except to call OS entry point with MMU off and
hardware properly initialized
OEMs have unique needs for custom bootloader functionality
y Support custom user interface for low level device management
y Diagnostics
y Load operating system from various resources
BLCOMMON library provides one possible implementation
framework
Do not assume that a bootloader will be implemented following
any particular standard

SYNNEX
Bootloader

Bootloader Framework (BLCOMMON)

Components located in
WINCE600\PLATFORM\COMMON\SRC\COMMON\BOOT
Base framework simple
y Initialize hardware
y Call BootloaderMain()
y Implement required callbacks
Use other Common libraries as needed
Supports integration with Platform Builder tools
y Download images across debug connection
Extensible

SYNNEX
Bootloader

Startup

Main

BootloaderMain
OEMDebugInit

OEMPlatformInit

OEMPreDownload

DownloadImage

OEMWriteFlash

OEMLaunch

BLCommon Basic Flow

SYNNEX
OAL

The OAL (OEM Abstration Layer) is the platform specific

interface between the kernel and the device hardware
Purpose
y Handles interrupts, timers, power management, etc.
y Implements the operating system entry point
y Essentially is the kernel “process” containing kernel
mode DLLs

SYNNEX
OAL

Architecture
y OAL is a separate component
-No longer statically linked as part of OS kernel

y OAL must implement set of required functions

y OAL and Kernel each expose interface as export table
- Can only call exported functions

SYNNEX
OAL

OAL Directory Structure

y SRC\OAL\OALLIB
Contains BSP specific OAL functions
Builds as library that will eventually link with others to create OAL
y SRC\OAL\OALEXE
Contains sources file with build instructions for OAL.EXE
Links OAL.LIB along other Microsoft supplied libraries to create
OAL.EXE
OAL.EXE is renamed to NK.EXE during build process

SYNNEX
OAL – Required Function Interface

Implement using Common libraries

y Common libraries provide implementation for many required OAL
functions
y Libraries may require callback functions implemented in BSP to
handle BSP specific functionality
y Libraries may require custom data structures to be implemented in
BSP
y OAL architecture based on Common libraries called Production
Quality OAL (PQOAL)
Implement directly
y No requirement to use Common code
y Can selectively choose functionality from Common code
May be a good choice for BSPs derived from a non PQOAL source

SYNNEX
OAL – Common Functions

OEMInitDebugSerial
y First call to OEM code by kernel
y Opportunity to initialize serial debug communications
OEMInit
y Second call to OEM code by kernel
y Very early in boot sequence
No system calls allowed
Single threaded
No blocking
Exception handlers not available
y Initialize all necessary hardware interfaces, OS timer etc
y Register ISRs (except ARM)
y Initialize Kitl

SYNNEX
OAL – Common Functions

OEMInterruptEnable
y Enables specified interrupt based on interrupt identifier
y Called by InterruptInitialize and InterruptMask
OEMInterruptDisable
y Disables specified interrupt based on interrupt identifier
y Called by InterruptDisable and InterruptMask
OEMInterruptDone
y Unmasks specified interrupt based on interrupt identifier
y Called by InterruptDone
OEMInterruptHandler (ARM only)
y Interrupt handler function (ISR)
y Returns interrupt identifier corresponding to interrupt source

SYNNEX
OAL – Common Functions

OEMIdle
y Called when no threads are scheduled to run
y Opportunity to place CPU in low power state
OEMPowerOff
y Called in response to SetSystemPowerState()
POWER_STATE_OFF
POWER_STATE_SUSPEND
POWER_STATE_CRITICAL
y Place CPU in lowest power “suspend” state

SYNNEX
OAL – Common Functions

OEMIoControl
y Called in response to KernelIoControl
y Generic IOCTL interface for the kernel
y Some standard IOCTLs must be implemented
y Can be extended by the OEM
y Implements interrupt identifier management

SYNNEX
OAL – Common IOCTLs

IOCTL_HAL_INIT_RTC
y Resets the realtime clock
IOCTL_HAL_GET_DEVICE_INFO
y Supports SystemParametersInfo function
IOCTL_HAL_REQUEST_IRQ
y Returns IRQ based on device location
IOCTL_HAL_REQUEST_SYSINTR
y Returns interrupt identifier based on IRQ
IOCTL_HAL_REBOOT
y Warm boots the target device

SYNNEX
OAL – Common Functions

OEMSetRealTime/OEMGetRealTime
y Called by the kernel to get/set the real time clock
y Called in response to Get/SetSystemTime
OEMSetAlarmTime
y Set the Real Time Clock alarm

SYNNEX
Drivers

Most CPUs have peripherals or expansion bus interface

that can support peripherals
y A particular hardware platform may require drivers for a
subset of available peripherals
y Microsoft provides driver support for many peripherals
Some drivers fully implemented outside of the BSP
Some drivers require BSP support for platform specific
implementations
y Drivers not fully implemented by Microsoft must be
provided in BSP
SRC\DRIVERS

SYNNEX
Drivers

Drivers are found in several places

y PUBLIC tree
\PUBLIC\COMMON\OAK\DRIVERS
Provided by Microsoft
Bus agnostic drivers
External peripherals (not on CPU silicon)
MDDs for various common driver types
e.g. Wave, Touch, Serial

SYNNEX
Drivers

Drivers are found in several places (con’t)

Platform Common
y Contains support for peripherals that exist on CPU silicon
y Some SOC drivers may be fully implemented in Common code
y Other drivers may require some BSP support for platform specific
functionality
BSP
y Custom devices that don’t have driver support from Microsoft
y Drivers obtained from third parties
y Cloned (copied) versions of Microsoft provided drivers
y Hardware specific (PDD) implementations

SYNNEX
Miscellaneous Files Of
Board Support Package

SYNNEX
Catalog File

Catalog Items View

SYNNEX
Platform Batch File

deviceemulator.bat
<snip>
REM -----------------------------------------------
REM Select which KITL transport to use.
REM
REM -----------------------------------------------
set BSP_KITL_ETHERNET=
set BSP_KITL_DMA=1
set IMGNOSIR=1
set IMG_RESERVERAMFMD=1
set IMGSDKCERTS=1
set IMGHEADSET=1
<snip>

SYNNEX
Configuration Files

Binary Image Builder (*.bib)

y Specify files to be included in the run-time image
y Specify memory configuration and use
Registry (*.reg)
y Specify the initial registry
File System (*.dat)
y Specify the initial directory structure
Database (*.db)
y Specify initial database contents

SYNNEX
Configuration Files: .BIB Files

MEMORY section
y Partitions the memory into two types
RAMIMAGE Contains OS image (‘ROM’), supports XIP
RAM Program and Data memory

Name
Name Start
Startaddress
address Size(bytes)
Size(bytes) Type
Type
-----------------------------------------------
-----------------------------------------------
NK
NK 8C800000
8C800000 00800000
00800000 RAMIMAGE
RAMIMAGE
RAM
RAM 8C050000
8C050000 007B0000
007B0000 RAM
RAM
CONFIG section
y Contains settings that control certain kernel features
y Contains settings that control characteristics of the build output file

SYNNEX
 The Configuration Files: .BIB Files

MODULES section
y Lists modules to include in the run-time image
y Components in this section will be configured to XIP
y Only executable modules can be listed here
FILES section
y Other modules to be included in the run-time image
y Can include both executable modules and data files
y Will be managed by the object store file system

;Name
;Name Path
Path Memory
MemoryType
Type
-----------------------------------------------------
-----------------------------------------------------
Tahoma.ttf
Tahoma.ttf $(_FLATRELEASEDIR)\Tahoma.ttf
$(_FLATRELEASEDIR)\Tahoma.ttf NK
NK SHU
SHU

SYNNEX
FILES – Config.bib

MEMORY Section
RAMIMAGE Type
y Specifies memory range OS will execute from
y Virtual Addresses
Corresponds to mapping in OEMAddressTable (ARM, X86) or fixed static
mapping (other processors)
y Could be RAM or ROM
y Virtual memory range must be physically contiguous
y Must be aligned on 64KB boundary
y Size must be 64KB granularity
y Must be large enough to contain the entire operating system image

SYNNEX
FILES – Config.bib

MEMORY Section
RAM Type
y Specifies memory range available for program and
storage (working RAM)
y Virtual Addresses
Corresponds to mapping in OEMAddressTable (ARM, X86) or
fixed static mapping (other processors)
y Must be RAM
y Virtual memory range must be physically contiguous
y Must be aligned on 64KB boundary
y Size must be 64KB granularity

SYNNEX
FILES – Config.bib

MEMORY Section
RESERVED Type
y Ignored by build tools
y Document use of other memory regions
Bootloader
DMA buffers
Framebuffer
Etc

SYNNEX
FILES – Config.bib

CONFIG Section
AUTOSIZE
y Allows boundary between RAM/RAMIMAGE sections to
be dynamically determined
y Makes efficient use of RAM resources
y Only works with images running entirely from RAM

SYNNEX
FILES – Platform.bib

Lists BSP components to be included in the image

y Modules Section
Components in this section will XIP if not compressed
Can only include executable components, no data files
Components can’t be accessed as files because header information is
stripped away
y FILES Section
Components in this section are included with full headers
Can be manipulated as files
Executable code will be paged into memory for execution
Flags specify component characteristics
y E.g. USER/KERNEL, Hidden, System etc
All components end up in \WINDOWS directory

SYNNEX
Configuration Files: .REG Files

Define default registry settings

y COMMON.REG, IE.REG, WCEAPPS.REG,
WCESHELL.REG: define registry settings for Windows
CE modules
y PLATFORM.REG: platform-dependent registry settings,
such as device driver entries
y PROJECT.REG: defines registry settings relative to your
project

[HKEY_LOCAL_MACHINE\init]
[HKEY_LOCAL_MACHINE\init]
“Launch10”=“shell.exe”
“Launch10”=“shell.exe”
“Launch20”=“device.dll”
“Launch20”=“device.dll”

SYNNEX
BIB REG Editor VS2005

SYNNEX
The Configuration Files: .DAT Files

Define directory structures

y All files are located in \Windows (ROM)
y Filesystem parses information provided by .dat files to
create and populate additional RAM directory structure
y Results in multiple copies of files
Example:
Root:-Directory(“Program
Root:-Directory(“ProgramFiles”)
Files”)
Directory(“\Program
Directory(“\ProgramFiles”):-Directory(“My
Files”):-Directory(“MyProjects”)
Projects”)

Root:-Directory(“My
Root:-Directory(“MyDocuments”)
Documents”)
Directory(“\My
Directory(“\MyDocuments”):-File(“MyFile.doc”,“\
Documents”):-File(“MyFile.doc”,“\
Windows\Myfile.doc”)
Windows\Myfile.doc”)

SYNNEX
The Configuration Files: .DB Files

Define databases in the object store

y Various OS components create databases for their own
use
y Platform.db adds BSP specific database entries
y Project.db adds OS design specific database entries
y Merged into initdb.ini and included in the image

SYNNEX
Creating a New BSP Of
Board Support Package

SYNNEX
Creating a New BSP

Always start with a reference BSP

Don’t attempt to create a BSP entirely from scratch
Find a reference BSP that most closely matches your
target hardware platform
y CPU vendor
y Microsoft reference BSPs
y Third party systems integrator

SYNNEX
Creating a New BSP

Clone the source BSP

This preserves the original BSP
y Original reference remains intact
y Changes made by source vendor do not overwrite your
changes
y Never modify code you did not clone!
Use the Clone Tool provided in Platform Builder
y Tools->Platform Builder for CE 6.0->Clone BSP

SYNNEX
Creating a New BSP

Port the BSP

Update areas of the BSP that differ from your target hardware
y Requires a thorough understanding of your hardware implementation
y Must analyze the entire BSP code base
Memory map
System initialization
Interrupts
GPIO configuration
Peripheral implementation
y Difficulty varies depending on how close the reference BSP matches
target hardware and quality of original BSP
y Not a trivial task

SYNNEX
Creating a New BSP

Update BSP Features

Implement the unique requirements your device requires
y Bootloader features
y Custom drivers
y Support new OS features
Build/Test/Ship!

SYNNEX
 The SDK Of
Customizing the OS
Design

SYNNEX
SDK

Platform Builder
CE 6.0 OS Design OEM Adaptation Layer Run-time Libraries
(OAL)

Custom SDK
Platform Manager SDK Documentation

Run-time Files Headers and Libraries OS Design Extensions

Microsoft Embedded Development Software

Visual Studio 2005

SYNNEX
SDK Development Steps

Build OS Design – create a run-time image

Configure the SDK – use the SDK Wizard to configure
basic settings
Build the SDK - created SDK is a Microsoft Windows
Installer (MSI) package
Install the SDK on Visual Studio 2005

SYNNEX
Configuring the SDK Options - General

Configurable SDK properties

SYNNEX
Configuring the SDK Options - Install

Configurable MSI install properties

SYNNEX
Configuring the SDK Options – CPU Families

Configuring CPU family supported by SDK

SYNNEX
Configuring the SDK – Adding User-defined Files

Add additional folders from the SDK’s Properties Pages

SYNNEX
Building an SDK

From the Build menu, choose Build All SDKs.

SYNNEX
Installing the SDK

Installing the SDK on other development machines

(with VS 2005 SP1)

SYNNEX
Operating System
Internals

SYNNEX
CE 6.0 Architecture – User Processes

ServicesD.EXE Udevice.EXE Udevice.EXE

Windows CE User User
Shell Service Service
Application Mode Mode
1 n
Driver 1 Driver n

Win32 CE APIs – COREDLL / WINSOCK / COMMCTRL / COMMDLG

Shell – Standard or custom interface for the device

ServicesD.EXE has the ability to host n number of
Services
UDevice.EXE has the ability to host n number of user
mode drivers

SYNNEX
CE 6.0 Architecture – Kernel

Win32 CE APIs – COREDLL / WINSOCK / COMMCTRL / COMMDLG

DEVMGR.DLL FILESYS.DLL
KERNEL.DLL Networking
GWES.DLL
DLLs
Drivers FSDMGR.DLL
OAL
KCOREDLL.DLL

FILESYS.DLL – Init sequence, Object Store, notifications etc

FSDMGR.DLL – File system support
GWES.DLL – Graphics, Windowing, and Events Subsystem
Networking DLLs – NDIS based networking services
DEVMGR.DLL provides device driver services
KITL.DLL (Optional)

SYNNEX
CE 6.0 Architecture – Kernel

Win32 CE APIs – COREDLL / WINSOCK / COMMCTRL / COMMDLG

DEVMRG.DLL FILESYS.DLL
KERNEL.DLL Networking
GWES.DLL
DLLs
Drivers FSDMGR.DLL
OAL
KCOREDLL.DLL

The Kernel contains base OS services

API calls from modules loaded in the Kernel use
K.COREDLL.DLL to get to other kernel services.
K.COREDLL.DLL- kernel equivalent to COREDLL.DLL

SYNNEX
CE 6.0 Architecture - Hardware

Win32 CE APIs – COREDLL / WINSOCK / COMMCTRL / COMMDLG

DEVMGR.DLL FILESYS.DLL
KERNEL.DLL Networking
GWES.DLL
DLLs
Drivers FSDMGR.DLL
OAL
KCOREDLL.DLL

RAM IRQ Touch Display PAN WAN

CPU Control USB SDIO OEM
ROM Keyboard LAN MAN

Hardware connects to the operating system through

standard interfaces: device drivers.
There is great flexibility in the types of hardware that CE
6.0 supports
SYNNEX
CE 6.0 Architecture

ServicesD.EXE Udevice.EXE Udevice.EXE

Windows CE User User
Shell Service Service
Application Mode Mode
1 n
Driver 1 Driver n

Win32 CE APIs – COREDLL / WINSOCK / COMMCTRL / COMMDLG

DEVMGR.DLL FILESYS.DLL
KERNEL.DLL Networking
GWES.DLL
DLLs
Drivers FSDMGR.DLL
OAL
KCOREDLL.DLL

OAL Component

SYNNEX
CE 6.0 Architecture

ServicesD.EXE Udevice.EXE Udevice.EXE

Windows CE User User
Shell Service Service
Application Mode Mode
1 n
Driver 1 Driver n

Win32 CE APIs – COREDLL / WINSOCK / COMMCTRL / COMMDLG

DEVMGR.DLL FILESYS.DLL
KERNEL.DLL Networking
GWES.DLL
DLLs
Drivers FSDMGR.DLL
OAL
KCOREDLL.DLL

Microsoft OEM ISV

SYNNEX
Applications, Processes & Threads

Application
y A logical group of executable code
Process
y A process is a single instance of an application
y Static context within which one or more threads execute
y Up to 32,000 processes loaded simultaneously
Thread
y Basic unit of execution managed by the scheduler
y Each process has at least one thread called the primary thread
y Number of threads limited by maximum number of handles in a
process

SYNNEX
Operating System
Internals Memory
Architecture

SYNNEX
Memory Architecture Overview

Memory Overview
Virtual Memory Model
Program Memory
y Heaps and Stacks
y Processes, Threads and Memory
Memory System Tools

SYNNEX
Memory Overview

Memory Types
y Random Access Memory (RAM)
y Read Only Memory (ROM)
What Uses Memory?
y Bootloader
y Operating System
y Applications
y Object Store - File system, Registry, Databases
y Shared heap
y Memory Mapped Files

SYNNEX
Memory Overview

Operating System Image Requires Space

y The operating system image itself is located in RAM or
ROM at runtime
y Often copied to RAM in totality from a storage location
(hard drive, flash memory) by the bootloader
y RAM occupied by the OS image is not available for
application use
y Could be in located in ROM and not copied to RAM

SYNNEX
Memory Overview

eXecute In Place (XIP)

y Allows execution of programs from directly from their
location in the OS image in memory
y Loader does not need to copy into RAM and fixup
addresses
y Preserves limited RAM resources especially when XIP
from ROM

SYNNEX
Memory Overview

User Settable Program vs. Storage Memory

y Program Memory is available for application use
y Storage Memory is used just for system object store
which contains the file system, the system database and
the registry.

SYNNEX
Virtual Memory Architecture

Virtual Memory
y Single 32-bit (4 Gigabyte) flat virtual memory address space
y Permits efficient use of physical memory with protection
Virtual Addressing
y Memory Management Unit (MMU) “owns” physical memory
y Virtual addresses translated to physical addresses by MMU
y A valid virtual address must map to a physical address
y Static or Dynamically mapped virtual addressing
y All CE components use virtual, not physical addresses
Physical Addressing
y Used by CPU before MMU is activated during power-up and by bus
mastering components such as DMA controllers.

SYNNEX
Virtual Address Mapping – Static Mapping Example

Physical Memory Virtual Memory FFFF FFFF

Kernel
Space

C000 0000

Uncached
32 MB Flash

512 MB
64 MB RAM
A000 0000

512 MB
Cached
32 MB Flash
82000000
32 MB Flash 64 MB RAM
04000000 8000 0000

64 MB Flash

User
2 GB
Address User
Translation Space
00000000 0000 0000

SYNNEX
Virtual Memory Map

Kernel
2 GB Filesystem
kernel GWES
space Drivers

Memory
mapped files

2 GB VM

..
User DLLs
per

..
process

..
..
Process code

32 K
processes
SYNNEX
Kernel Memory Space

CPU Specific VM

Kernel VM
(if supported by CPU)
256 MB
Kernel Space Kernel VM
2 Gigabytes 256 MB
Fixed
Object Store (128 MB)
mapping
Kernel XIP DLLs (128 MB)
independent
of user space Static Mapped
Uncached
512 MB

Static Mapped
Cached
512 MB

SYNNEX
User Memory Space

Shared System Heap

255 MB

RAM Backed Mapfiles

256 MB

User Space 2 Shared User DLLs

Gigabytes 512 MB
Each process
has its own
mapping

Process Space
1 GB process

SYNNEX
Program Memory

RAM available for use by OS/Drivers/Applications

Data RAM, does not include code pages
Major Types of Program Memory
y Heap
The primary area of memory used by the application
y Stack
Storage area for variables referenced in a program

SYNNEX
Program Memory - Heap

Heap Characteristics
y Dynamic memory allocation
y Processor-independent (hides memory paging)
y Automatically allocates memory and commits pages on
demand

SYNNEX
Program Memory - Heap

Types of Heap Memory

Local Heap (Default)
y Reserves virtual memory at process load time
y Commits physical pages on demand
Private Heap
y Reserves initial fixed size or expandable (disjointed) heap space
y Serialization for mutual exclusion of multiple threads
Shared Heap
y Writable to kernel and read only to user processes
y Visible to all user processes
Remote Heap
y Shared between user processes

SYNNEX
Program Memory - Stack

Creation
y Default stack allocated for each thread at creation
y All threads of a process have same stack size by default
y Default thread stack size override with /STACK linker
switch
y Individual threads can be created dynamically with
unique stack size
Note: CE 6.0 compiler automatically inserts code to detect
buffer overruns on the stack with the /GS switch

SYNNEX
Program Memory - Processes and Threads

Process
Primary Thread
Heap
Stack

Additional Thread

Stack

Each Process has at least

one heap
Additional Thread
Each Thread has a stack
Stack

SYNNEX
Operating System Internals
Threads and Scheduling

SYNNEX
Threads

Scheduler provides efficient context switching among

threads
Each process has one or more threads
Each thread has its own context (stack, priority, etc)
Predictable sequence of thread execution based on
priority

SYNNEX
Processes and Threads

Priority-based Scheduling
y Preemptive scheduling within 256 priority levels
y Round-robin scheduling of threads on same priority
y Priority 0 (or highest priority) threads run to completion

SYNNEX
Scheduler – Quantum Time Slicing

Thread 1 P=0 Thread 1 Thread 1

Thread 2 P=252 Thread 2 Thread 2

Thread 3 P=252 Thread 3 Thread 3

t1 t2 t3 t4 t5 t6 t7

Same priority threads run in round-robin fashion

Switch threads when blocked
Switch threads after quantum has elapsed
Programmable quantum from 1 to N ms, default 100 ms
SYNNEX
Thread Priority Map

Priority Component
0 - 96 Typically reserved for real-time drivers

97-152 Used by the default Windows Embedded

CE–based device drivers

153-247 Typically reserved for non-real-time drivers

248-255 Mapped to other non-real-time priorities

SYNNEX
Priority Inversion

OS Priority OS Priority
Inversion Restoration

High Priority Thread 1 Thread 3 Thread 1

Preempt
Medium Priority Thread 2 Thread 2

Preempt
Low Priority Thread 3 Thread 3

Resource Owner: Thread 3 Thread 1

SYNNEX
Thread APIs

Thread Creation
y CreateThread
Creates a new thread at normal priority
Thread Priority
y CeGetThreadPriority
Get current priority level of a thread
y CeSetThreadPriority
Set priority level of a thread
y SetThreadPriority
Legacy function
y GetThreadPriority
Legacy function

SYNNEX
Thread Blocking APIs

Thread Blocking APIs

y Sleep (n) – minimum number of milliseconds to suspend
execution
y Sleep(0) – relinquish remainder of quantum to other
threads with the same priority
y SleepTillTick – suspend execution until next system tick
y WaitForSingleObject – block until specified kernel
object is signaled
y WaitForMultipleObjects – block until one of a set of
specified kernel objects is signaled

SYNNEX
Operating System
Internals Interrupt
Model

SYNNEX
Interrupt Model

Interrupt
KERNEL.DLL Service
Event Thread
Exception Handler
(IST)
4
3

Interrupt ID
Interrupt

2
Device Interrupt Service Routine (ISR)

Interrupt Processing
1. Device raises registered hardware interrupt
2. Kernel gets exception, calls associated Interrupt Service Routine (ISR)
3. Interrupt Service Routine (ISR) quickly deals with pending interrupt
4. Interrupt Service Thread (IST) in driver is signaled to process interrupt

SYNNEX
Interrupt Service Routine (ISR)

Registered to an IRQ
Called to handle the hardware interrupt
Acknowledges hardware and determines Interrupt ID
Returns Interrupt ID (SYSINTR) to kernel
Static (built into NK.EXE) or Installable (chained in) via
Kernel call
Must be written to run quickly with no outside
dependencies

SYNNEX
Interrupt Service Thread (IST)

Thread registered to handle an interrupt

Performs majority of interrupt handling task
Created by a device driver
Standard thread that waits for interrupt events
Scheduled like any other thread in the system
Performs device-specific servicing for Interrupt ID
Signals completion of interrupt processing to
hardware

SYNNEX
ISRs And ISTs Work Together

ISRs and ISTs work as pairs

y ISR identifies and masks interrupt quickly
y IST handles the bulk of the work
Synchronized by using an Event Object
y IST creates an Event Object mapped to SYSINTR ID
y IST blocks on event with WaitForSingleObject
y ISR returns SYSINTR to kernel
y Kernel sets Event, unblocking IST
If the IST is the highest priority runnable thread, it
will be scheduled to run immediately

SYNNEX
Installable ISRs

Allows a driver to install an ISR at run time

y Typically used for shared interrupts
y There must already be an ISR registered for that IRQ
supporting shared interrupts
ISR implemented in a DLL
Loaded into kernel by LoadIntChainHandler
OAL ISR MUST call NKCallIntChain for all shared IRQs

SYNNEX
Shared Interrupts Using Chaining

ISR ISR ISR

1 2 3

Shared Interrupt Line

Bar Code Power WiFi

Scanner Switch Receive

Some platforms designed to have several devices use same

interrupt line
One interrupt that is shared by all
Multiple ISRs chained to handle shared interrupts
Each ISR, in turn, determines if it owns the interrupt

SYNNEX
 Operating System
Components Power
Management

SYNNEX
Concepts – Role of the Power Manager

What is the Power Manager?

y OS component responsible for meeting the power needs
of the system efficiently
y Application Interface
Applications communicate their power needs
Applications can choose to receive notification of power related
events
y Device Interface
Individual devices request their desired power state based on need
PM determines actual device power states
Devices must operate in state set by Power Manager

SYNNEX
Concepts – Role of the Power Manager

Application
Notification
Message Application
APIs
Queue

Power Manager
APIs

Driver
APIs

Power
Manager Drivers
(pm.dll)

SYNNEX
Concepts – Device Power States

Device Power States

y Power level of a given device
Device in this context means individual hardware peripheral
y Fixed number of predefined states
D0 Full on Full functionality
D1 Low on Full functionality, reduced performance
D2 Standby Partial power, auto wakeup on request
D3 Sleep Partial power, can wake up
D4 Off No power
y Devices may implement a subset of states
y Device determines how a particular state is implemented

SYNNEX
Concepts – System Power States

System Power States

y Named power states for entire system
Defined by the OEM
Act as global setting for device power states
y Set maximum device power states
y Default implementation provided by Microsoft
On User actively using device
UserIdle User passively using the device
SystemIdle User not using the device
Suspend Device powered down

SYNNEX
Concepts - System Power States

System power states map to device power states in the registry

yDefault mapping for all devices
Default implementation
On D0
UserIdle D1
SystemIdle D2
Suspend D3
yIndividual devices can have exceptions to default
Example: Suspend state maps to D4 for NDIS devices
yOEM can easily modify device power state to system power state
mapping using the default Power Manager implementation

SYNNEX
Concepts – Activity Timers

Activity Timers
y Named timers implemented by Power Manager
Configurable in registry
Any number of timers can be implemented
General purpose mechanism that can be used by any component
y Implemented with named events
y Used by default Power Manager implementation
PM implements two timers for its own use
Used to determine user and system activity
Some OS components reset timers to indicate activity
GWES, Networking

SYNNEX
Power Manager Implementation

Power Manager implementation provided by Microsoft

y WINCE600\PUBLIC\COMMON\OAK\DRIVERS\PM
y MDD/PDD model
y PDD defines the supported system power states
y PDD contains logic that determines when/how to
transition between system power states
y OEMs can modify PDD to meet unique device
requirements
Different system power state needs

SYNNEX
Power Manager Implementation

Power Manager determines when to change system

power states
y Decision logic implemented in PDD
y Default implementation based on activity timers
UserActivity timer
SystemActivity timer
y Timer settings exposed to user with control panel applet

SYNNEX
Device Power Management

Power Manager support optional in driver

y PM only controls drivers that are Power Manager aware
y Drivers not required to support Power Manager
y Devices must advertise that they support the Power
Manager interface for PM control
Iclass registry entry with Power Manager GUID
AdvertiseInterface with Power Manager GUID

SYNNEX
Device Power Management

Device Power State Changes

y Drivers may not change power state unless instructed to
by Power Manager
y Drivers should manage power within a power state on
their own
y Drivers can request that the Power Manager change their
state
Power Manager may change to requested state, another state, or
no change at all
Drivers must not assume that their request will be honored

SYNNEX
Device Power Management

Drivers communicate power needs with DevicePowerNotify

Power Manager sets device state with DeviceIoControl
yDrivers must expose stream interface

Power
Manager
PM.DLL

PM APIs

DevicePowerNotify DeviceIoControl

Device Driver

SYNNEX
Device Power Management

Device State Code Sample

case IOCTL_POWER_SET:
// update device registers
...
deviceDx = *(PCEDEVICE_POWER_STATE) pOutBuf;
fBoostRequested = FALSE;
fReductionRequested = FALSE;
break;

SYNNEX
Applications and Power Management

Applications can request notification of Power events

y RequestPowerNotifications/StopPowerNotifications
y Notifications generated by Power Manager
Uses point to point message queues
y Applications register for desired event type
System power state transitions
Change between AC/DC power sources
Resume occurred
Battery power status field has changed
y Notification only, no opportunity to modify, delay or block
event

SYNNEX
Applications and Power Management

Applications can request a system power state change

y SetSystemPowerState will instruct the Power Manager
to change power states
Specify by name
Specify by “hint” (bitmask)
y System power states are OEM defined, so applications
may not know state names
Power manager chooses most appropriate state based on hint
Hint bitmasks defined by Microsoft for standard state types
y Power Manager may restrict applications from entering
certain system power states

SYNNEX
Applications and Power Management

Applications can set power requirement for a device

y Application calls SetPowerRequirement to request a
specific device maintain a minimum power state
y Allows device to be at a higher power state than system
power state would otherwise allow
y Application should call ReleasePowerRequirement as
soon as possible to allow normal power management to
continue

SYNNEX
Application Power Management APIs

GetSystemPowerState
y Retrieve the current system power state
SetSystemPowerState
y Request a particular system power state
SetPowerRequirement
y Request specific device to maintain minimum power level
ReleasePowerRequirement
y Release device requirement
RequestPowerNotifications
y Request notification when certain types of power related events
occur
StopPowerNotifications
y No longer have a need to receive power notifications

SYNNEX
Idle Power Management

Kernel knows when no threads are running

y Calls OEMIdle to put the CPU in lower power states
Must be supported by CPU
y Transparent to rest of system and user
y Independent of Power Manager
y Small change here = big change in Standby time
Majority of time spent is in OEMIdle

SYNNEX
Suspend/Resume

Suspend
y Lowest possible power state
y Device is off from user perspective, but maintains volatile
memory
y Must be supported by cpu
Resume
y “Instant on”
y Returns to state that existed prior to entering suspend
y Transparent to applications

SYNNEX
Suspend/Resume

Power Manager implements suspend/resume sequence

y Initiated in response to SetSystemPowerState
y Drivers participate in suspend/resume process
Includes drivers that are not managed by Power Manager
y Applications can initiate suspend sequence if permitted
by Power Manager implementation
y Applications have no opportunity to block or otherwise
participate in the suspend sequence

SYNNEX
Suspend/Resume

Suspend Path
y PM disables all PM-aware non-block drivers
y PM calls IOCTL_HAL_PRESUSPEND
y PM notifies file systems
y PM disables all PM-aware block drivers
y System goes “single threaded”
y Kernel calls all legacy xxx_PowerDown functions
y Kernel calls OEMPowerOff

SYNNEX
Suspend/Resume

Resume Path
y CPU wakes up and continues executing
y OEMPowerOff returns
y Kernel calls all legacy xxx_PowerUp routines
y System goes multi-threaded
y PM enables PM-aware block drivers
y PM enables file systems
y PM enables remaining PM-aware drivers

SYNNEX
 Operating System
Components
Internationalization

SYNNEX
Internationalization

Platform localization options

yLocalization vs. Internationalization
yChanging the language of your operating system

SYNNEX
Internationalization

Locale Support
Arabic
English (U.S.)
English (Worldwide)
French
German
Hebrew
Indic
Japanese
Korean
Simplified Chinese
Traditional Chinese
Thai

SYNNEX
Internationalization

Adding locales
Selecting codepages

SYNNEX
Multilingual User Interface

German French
DLL DLL

English Spanish
DLL DLL
CE OS

Allows users to change the language of the user

interface (UI)
Single core binary that includes the system default
language
One resource dynamic–link library (DLL) for each
additional target language
SYNNEX
Internationalization Components

National Language Support (NLS)

Multilingual User Interface (MUI)
Unicode Script Processor for Complex Scripts
Input Method Manager (IMM)
Handwriting Recognizer Engine (HWX)
Keyboards and Fonts for Many Languages
Additional language specific components

SYNNEX
Device Driver
Concepts

SYNNEX
What is a Device Driver?

Application

Driver
CE 6.0

Device

A device driver is software that abstracts the functionality

of a physical or virtual device
SYNNEX
Device Driver Categories

Drivers are classified in a number of different ways

y Native vs Stream
Who loads the driver
y User vs Kernel
Where the driver is loaded
y Monolithic vs Layered (MDD/PDD)
How the driver is architected
y Built In vs Dynamic/Installable
When the driver is loaded
y Driver Family
WAV/Miniport/Touch/Display/Serial etc

SYNNEX
Monolithic vs Layered

MDD/PDD or Layered Drivers

y Model Device Driver + Platform Device Driver = Driver
y Sample implementations provided by Microsoft
y MDD implements functionality common to all similar devices
y MDD implements defined architecture for specific drivers
y MDD can often be used unmodified
y MDD calls PDD functions for hardware specific functionality
y PDD must be customized to match target hardware
y Interface to PDD is sometimes called DDSI
y Provides for code reuse, ease of implementation
y Can be less efficient due to layering

SYNNEX
Monolithic vs. Layered

Monolithic Drivers
y Does not leverage high level shared library of interface
routines
y Written to implement requirements as efficiently as
possible
y Can have increased or otherwise unique feature set (not
dependent on MDD implementation)
y Less code reuse, more complex development
y Can be more efficient due to streamlined functions

SYNNEX
Monolithic vs. Layered

Hybrid Drivers
y MDDs are not immutable. Clone and modify as
necessary
y Modified MDDs are often used to implement missing
feature requirements
y Maintains ease of development benefits by starting with
existing high level driver implementation

SYNNEX
Native vs. Stream

Native
y Fixed set of native device classes defined by CE
•Keyboard
•Display
•Touch
y Drivers loaded directly by GWES, not managed by device
y Each has its own model

SYNNEX
Native Device Driver Model

Graphics, Windowing, and Events System (GWES)

Device Driver Device Driver
Interface (DDI) Interface (DDI)

MDD
Monolithic
Native Driver
PDD

Device

SYNNEX
Native vs. Stream

Stream Drivers
y Loaded and managed by Device Manager
y Support any type of physical or virtual device
y Device Manager imposes minimum interface
requirements (driver entry points and behavior)
y Stream model applies to most drivers
y Exposed to applications through filesystem APIs
y Can be loaded at boot or dynamically

SYNNEX
Stream Interface Device Driver Model

Device Manager

Stream Stream Stream

Interface Interface Interface
(DDI)
NDIS Wrapper

MDD NDIS
Miniport
Monolithic
Stream NDIS Wrapper
Interface NDIS
Driver
PDD

Device

SYNNEX
Stream Driver
Architecture

SYNNEX
Device File Names

Drivers can be accessed as special file system device

Three different namespaces provide different features
y Share common 3 letter prefix
y Legacy
Example: “COM1:”
y Device
Example: “\$device\COM1”
y Bus
Example: “\$bus\PCMCIA_0_0_0”
Named interface not required

SYNNEX
Device File Names

Legacy Namespace
y Original naming convention
y Used by most legacy drivers
y Consists of Prefix followed by Index (0-9)
Limited to 10 instances of a particular prefix (COM0 -
COM9)
y Prefix included in driver entry points
Unless special registry flag is set

SYNNEX
Device File Names

Device
y Similar to Legacy namespace
y Consists of Prefix followed by number
y Provides support for more than 10 devices
“\$device\COM27”

SYNNEX
Device File Names

Bus
y Typically used with client drivers loaded by a bus driver
y Provides mechanism to differentiate between IO and bus
control operations
y Provides mechanism for more sophisticated driver
loading/unloading/power management features

SYNNEX
Stream Driver Architecture

Application
CreateFile

File System
Stream Interface
Driver
(Loaded at Boot up)
Device
Window CE
Manager
Kernel
OAL
Interrupt Events

Software
Hardware

Hardware Platform Built-in

Device

SYNNEX
Implementing Generic Stream Drivers

How do you implement a Stream Driver?

y Select a device file name prefix
y Implement the required entry points
y Create the *.DEF file
y Create the registry values necessary to load your driver

SYNNEX
Stream Entry Points: Init, Deinit

XXX_Init
y Called when Device Manager loads the driver
y Initialize necessary resources
y Perform memory mapping
y Initialize IST
XXX_Deinit
y Called when Device Manager unloads the driver
y Frees allocated resources, stops the IST

SYNNEX
Stream Entry Points: Open, Close

XXX_Open
y Called in response to CreateFile on device name
y Provides handle for use by other IO functions
y Allocate resources for open context and prepare for
operation
XXX_Close
y Called in response to CloseHandle
y Clean up open context

SYNNEX
Stream Entry Points: Read, Write and Seek

XXX_Read
y Called in response to ReadFile
XXX_Write
y Called in response to WriteFile
XXX_Seek
y Called in response to SetFilePointer

SYNNEX
Stream Entry Points: IOControl

XXX_IOControl
y Called in response to DeviceIoControl
y Provides mechanism supporting custom driver
operations
y Workhorse of most drivers
y I/O control code identifies the operation
y I/O control code is device-specific

SYNNEX
Stream Entry Points: PowerUp, PowerDown

XXX_PowerDown
y Callback notifying device that OS is suspending
y Allows driver to perform any desired operations
necessary to go into low power mode
XXX_PowerUp
y Callback notifying device that OS is resuming
y Allows driver to perform any desired operations
necessary to exit low power mode

SYNNEX
Stream Entry Points: PreClose, PreDeinit

XXX_PreClose
y Called prior to XXX_Close when application calls
CloseHandle
y Provides opportunity for driver to wake sleeping threads
y Eliminates potential race condition with multiple threads
XXX_PreDeinit
y Called prior to XXX_Deinit when driver unloads
y Provides opportunity for driver to mark handle as invalid
y Eliminates potential race condition with multiple threads

SYNNEX
Stream Driver Interfaces – Entry Points

Function Called When

xxx_Init The driver is initialized (loaded)
xxx_DeInit The driver is de-initialized (unloaded)
xxx_Open Application calls CreateFile
xxx_Close Application calls CloseHandle
xxx_IOControl Application calls DeviceIoControl
xxx_Read Application calls ReadFile
xxx_Write Application calls WriteFile
xxx_Seek Application calls SetFilePointer
xxx_PowerOn OS resumes from suspend state
xxx_PowerOff OS enters suspend state
SYNNEX
User Mode Driver
Framework

SYNNEX
 User and Kernel Mode Drivers

User Memory Space

ServicesD.EXE Udevice.EXE Udevice.EXE
Windows CE User User
Shell Service Service
Application Mode Mode
1 n
Driver 1 Driver n

Marshalling Win32 CE APIs – COREDLL / WINSOCK / COMMCTRL / COMMDLG

Kernel Memory Space

DEVMRG.DLL FILESYS.DLL
KERNEL.DLL Networking
GWES.DLL
DLLs
Drivers FSDMGR.DLL
OAL
K.COREDLL.DLL

SYNNEX
User vs. Kernel Mode Drivers – Kernel Mode

Default driver model

Run in kernel memory space
Link to kernel version of coredll, k.coredll.dll
y Automatic, no need to change build rules
Highest performance
y Fast access to kernel APIs
y Direct access to user buffers
Must be robust
y Driver crash could corrupt kernel

SYNNEX
User vs. Kernel Mode Drivers – User Mode

Also managed by Device manager

Hosted by udevice.exe
Close compatibility with kernel mode drivers
UM Drivers lose Kernel privileges
y No access to kernel structures or memory
y Cannot call certain kernel only APIs
y Restricted access to other kernel APIs
Increases system stability
Examples
y Expansion buses like USB and SDIO

SYNNEX
User Mode Driver Framework

Improved stability
y User-Mode Drivers are isolated from other drivers
y Kernel is isolated from user-mode drivers
Increased security
y Kernel protected from compromised drivers
y Lower privileges restrain a compromised driver
Recoverability
y System can recover after a driver crash
y Driver can be restarted without rebooting

SYNNEX
 Loading a User Mode Driver

User Mode Driver Host Process

User Application XXX_Init(…) 8

ActivateDeviceEx User Mode Driver

HANDLE udevice.exe
1 10 Returned CreateProcess(,,Volume Name)
User Mode

Kernel Mode XXX_Init forwarded 4 9 Device

to UM Driver Host 3 7
Context
6 2
Device Manager Reflector Service
5 9

10 HANDLE
1 Returned

Parent Bus Driver

SYNNEX
Registry For User Mode Driver

User Mode Driver Host process is launched and

managed by registry settings
Example of the registry keys for Group ID 3
[HKEY_LOCAL_MACHINE\Drivers\ProcGroup_0003]
"ProcName"="udevice.exe"
"ProcVolPrefix"="$udevice"

[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Ethman]
"Prefix"="ETM"
"Dll"="ethman.dll"
"Index"=dword:1
; WZCSVC must be started before ethman
"Order"=dword:2A
; Flags==12 is DEVFLAGS_LOADLIBRARY and DEVFLAGS_LOAD_AS_USERPROC
"Flags"=dword:12
"UserProcGroup"=dword:3 ; // default to group 3

SYNNEX
BIB File Issues

Driver in MODULES section of BIB file must be fixed

up properly to run in either User or Kernel mode
y Use K flag to fix up to kernel space
y Remove K flag to fix up to user space
y Use Q flag to fix up both places
Driver in FILES section can be loaded into user or
kernel space

SYNNEX
 Device Driver
Concepts Interrupts

SYNNEX
Interrupt Terminology

ISR – Interrupt Service Routine

y Runs in OAL
y Identifies interrupt source and returns Interrupt ID to
kernel
y Minimal processing – identify and mask interrupt
IST – Interrupt Service Thread
y Runs in device driver
y Signaled by kernel when ISR returns corresponding
Interrupt ID
y Performs bulk of processing necessary to handle
interrupt

SYNNEX
Interrupt Terminology

IRQ
y Hardware identifier indicating interrupt source
y Interpretation specific to BSP
y Could map to multiple SYSINTRs (shared interrupts)
SYSINTR
y Software identifier indicating interrupt source
y Mapped to a single IRQ by the OAL
y Associated with Event object by InterruptInitialize
y Returned by ISR to kernel

SYNNEX
Setup Interrupt

SYSINTR value needed to associate with interrupt

y Might be hard coded into driver (non portable)
y Use DDKReg_GetIsrInfo to retrieve from registry
Use SYSINTR value directly if it exists
Use Irq with IOCTL_HAL_REQUEST_SYSINTR to retrieve SYSINTR
from OAL
Create Event object
y Normal event object
y Will be signaled by the kernel when ISR returns SYSINTR
Associate event with SYSINTR (InterruptInitialize)
y Configures kernel with SYSINTR<->Event mapping

SYNNEX
Interrupt Service Thread

Create IST thread using CreateThread

y IST is just a secondary thread in the host process
Adjust thread priority using CeSetThreadPriority
y Retrieve thread priority from registry if available
IST loop
y Block on event using WaitForSingleObject
y Process interrupt when event is signaled
y Call InterruptDone to unmask interrupt

SYNNEX
Installable ISRs

Allows a driver to install an ISR at run time

y Supports driver installation after image creation
y OAL agnostic to device(s) using IRQ
y OAL must support interrupt chaining on that IRQ
NKCallIntChain
Typically used for shared interrupts
Supports custom functionality in ISR
y Example: High speed serial port driver

SYNNEX
Installable ISRs

ISR implemented in a DLL

y All code must be contained in the DLL and cannot have
dependent DLLs
y Cannot link implicitly to other DLLs
NOMIPS16CODE=1
y Must disable C run time library
NOLIBC=1

SYNNEX
Installable ISRs - APIs

LoadIntChainHandler
y Loads DLL into kernel
y Registers for particular IRQ
y Indicates handler function within DLL
FreeIntChainHandler
y Unload interrupt handler
KernelLibIoControl
y IST interface to ISR

SYNNEX
Generic Installable ISR (GIISR)

Suitable for many devices

Provided by Microsoft
Reads register to determine interrupt status
Configurable
y Register/Port address
y Register/Port size
y Memory vs. IO
y Mask

SYNNEX
Loading Stream
Drivers

SYNNEX
Driver Loading

Driver loading controlled by registry keys

y When the driver loads
y How the driver loads
y Parameters passed to the driver
Drivers loaded with call to ActivateDeviceEx
y Takes handle to registry key as parameter
Different loading requirements supported
y Can be loaded automatically at boot (Built In)
y Can be loaded dynamically (Plug and Play)

SYNNEX
Driver Registry Settings

Dll [Required]
y Specifies the name of the driver DLL
Prefix [Optional]
y Specifies the file name for the device driver
Order [Optional]
y Specifies order to load driver
Index [Optional]
y Specifies the device index (x in COMx:)
IClass [Optional]
y Specifies GUID(s) for device class(es) for use by PnP notification
system
Flags [Optional]
y Specifies load flags for the driver

SYNNEX
Driver Registry Settings – Flags Parameter

Flag Value Description

Driver unloads after a call to the

DEVFLAGS_UNLOAD 0x00000001
XXX_Init entry point

DEVFLAGS_NOLOAD 0x00000004 Driver is not loaded

Driver entry points do not have an

DEVFLAGS_NAKEDENTRIES 0x00000008
XXX Prefix prepended

Driver is loaded during system phase

DEVFLAGS_BOOTPHASE_1 0x00001000
one.
Bus Driver loads the driver only when
DEVFLAGS_IRQ_EXCLUSIVE 0x00000100
it has exclusive access to the IRQ.

DEVFLAGS_LOAD_AS_USERPROC 0x00000010 Loads a driver into user mode

SYNNEX
Driver Registry Settings – Bus Information

InterfaceType
y Specifies the Interface (Bus) type used for a device
See INTERFACE_TYPE enumeration in CEDDK.H for a complete
list of interface types defined by Microsoft. (You can define new
ones if you need to)
BusNumber
y Bus Instance number
Uniquely identifies the specific bus in case there is more than one
of the specified type in the system

SYNNEX
Driver Registry Settings – Memory and I/O
Windows
Memory and I/O Window information may be populated by a Plug and
Play Bus Driver or configured by the system OEM
IoBase
y Specifies the bus relative base of an I/O mapped window used by the
device.
Multiple windows specified using a binary array of 32bit values, one for each
window needed
IoLen
y Specifies the length of each I/O window needed by the device
MemBase
y Specifies the bus relative base of a memory mapped window used by
the device.
Multiple windows specified using a binary array of 32bit values, one for each
window needed
MemLen
y Specifies the length of each memory mapped window needed by the
device
SYNNEX
Driver Registry Settings – Interrupts

IRQ
y Specifies the physical IRQ used by the device
SYSINTR
y Specifies a Logical interrupt Identifier
Typically allocated by a bus driver for shared IRQs, the Device driver reads
this value and if present uses the one provided by the bus driver. Otherwise
the driver should use the IRQ to request a new logical ID.
IsrDll
y Specifies a DLL to containing an installable interrupt handler
IsrHandler
y Specifies the ISR handler in the ISR DLL

SYNNEX
Bus Drivers

What is a Bus Driver?

yLoad drivers for the devices on their respective buses
yProvides Device Manager with enough information to
create bus-relative names and enable device handles
yProvides bus level services for the bus
Examples are:
y USB
y PCI (PCIBus.dll)
y PCMCIA (Pcmcia.dll)
y Bus Enumerator (BusEnum.dll)

SYNNEX
Bus Enumerator

Bus Driver used by Device Manager

y Starts top level driver loading process
y “Bus” consists of registry subkeys
y Loads drivers listed in subkeys
y Loads other bus drivers and unmanaged drivers
y Can be re-entered

SYNNEX
 Device Manager – Loading Drivers at Boot

Reads registry HKEY_LOCAL_MACHINE\Drivers for

“RootKey” value
y Usually: "RootKey"="Drivers\\BuiltIn"
Calls ActivateDeviceEx on the registry path specified in
“RootKey”
y Example:
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn]
"Dll"="BusEnum.dll"
"BusName"="BuiltIn"
"Flags"=dword:8

y Bus Enumerator (BusEnum) driver loads drivers below it

SYNNEX
Sample Registry

Example:
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\AmdNorFMD]
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\AmdNorFMD]
"Dll"="amdnord.dll"
"Dll"="amdnord.dll"
"Prefix"=“DSK"
"Prefix"=“DSK"
"Flags"=dword:00010000
"Flags"=dword:00010000
"Order"=dword:2
"Order"=dword:2

[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Backlight]
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Backlight]
"Dll"=“backlight.dlll"
"Dll"=“backlight.dlll"
"Prefix"=“BKL“
"Prefix"=“BKL“
"Order"=dword:1
"Order"=dword:1

SYNNEX
 Application
Development

SYNNEX
Application Development Options

Languages
y C, C++, C#, VB and Assembler
Frameworks
y WIN32
y MFC, ATL, WTL, STL
y .NET Compact Framework

SYNNEX
.NET Managed Applications

Supported by the Compact Framework

Languages all compile to Intermediate Language format
to run on Common Language Runtime (CLR)
y C# application development
y Visual Basic .NET application development

SYNNEX
Native Applications

Must be rebuilt for each new CPU or Platform

Developer manages system resources
WIN32 runs without extra support files
Can access all operating system services and APIs
Must be rebuilt to run on desktop systems
Supports COM, ActiveX programming

SYNNEX
Managed Applications

Built once for all devices

Runtime engine manages system resources
Requires runtime support files (.NET CF)
Applications access the services exposed by the
Compact Framework
May Run directly on desktop without rebuilding

SYNNEX
 ~Thank You~
WinCE MOC Training Partner
ƒ Bsquare
ƒ TechWare
ƒ 巨匠

WinCE information and training data download

http://www.synnex.com.tw/oem_cover.htm

SYNNEX