WinCE 6.0 MOC Introduction - synnex download/moc...WinCE 6.0 MOC Introduction Victor Lin Field Application Engineer SYNNEX INTERNATIONAL CORP. (02)25063320-2231 [email protected]

WinCE 6.0 MOCIntroduction

Victor LinField Application EngineerSYNNEX INTERNATIONAL CORP.(02)[email protected]

SYNNEX

OverviewToolkit.OS Architecture.Memory Architecture.Driver Development.Application Development.

SYNNEX

Toolkit

SYNNEX

SYNNEX

Runtime Image of the CE 6.0 Operating System

Application Layer

OS Layer

OEM Layer (BSP)

Application ServicesKernel

DriversOEM Adaptation Layer (OAL)

Process Specific Definition Files

Windows CEApplication

Custom Application

Internet ClientServices

NK.B

IN

SYNNEX

Visual Studio 2005 Platform Builder

Solution Platforms

Connectivity Status

Connectivity Device Name

Tabbed Output Windows

Debug tool status

indicators

Output Selection

CodeEditorProject

Tree

SYNNEX

Visual Studio 2005 Platform Builder

CE OS Design – Major Menu OptionsProject – Creation or management of projectsBuild – Build options for the OS Design Debug – Access to Debug OptionsTarget – configuration and specifics of the target device. 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 completeZero errors on a build is the goal

SYNNEX

CE 6.0 Build Steps

Build process consists of 5 major phasesInitial step should not normally be used

Build Demo tool (Blddemo.bat)Interface to unified build system

Build

Dem

o Too

l (b

lddem

o.bat)

Post-Sysgen Build

Sysgen

Build Release Dir

Make Run-Time Image

1

2

3

4

0Pre-Sysgen Build

SYNNEX

Build Phases

1

System Generation - SYSGENFilters and combines modules and components based on OS Design settingsPost-Sysgen Build – BUILDBuilds Source Code for the BSP and subprojectsBuild Release Directory - BUILDRELCopies files into the Flat Release Directory

Make Run-time Image – MAKEIMGGenerates the OS Run-Time Image from the files in the Release Directory

1

2

3

4

4

3

2

SYNNEX

System Generation Phase

SysgenGenerates system configuration based on chosen Catalog items in OS design

Build

Dem

o Too

l (b

lddem

o.bat)Post-Sysgen Build

Sysgen

Build Release Dir

Make Run-Time Image

1

2

3

4

0Pre-Sysgen Build

SYNNEX


Complete header and source code

files

Complete system libraries

Module definitions (.def)

System-specific

header files

Linked libraries

Specific .def files

SYSGEN

SYNNEX


%__PROJROOT%\CESYSGEN

aaa.Exeaaa.Dll

MAKEFILE

zzzz.libyyy_lib.lib

SYNNEX


FilteringUses @CESYSGEN comment tags to filter files based on component settingsRun 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


Cesysgen\Oak\FilesOak\Files\Common\*.*Cesysgen\Ddk\IncDdk\Inc\*.*Cesysgen\Oak\IncOak\Inc\*.*Cesysgen\Sdk\IncSdk\Inc\*.*

Output directory in %_PROJECTROOT%

Input files from %_COMMONPUBROOT%

Filtering

SYNNEX

Post-Sysgen Build Phase

Post-Sysgen Build Phase Compile source code in BSP and user subprojects

Build

Dem

o Too

l (b

lddem

o.bat)

Post-Sysgen Build

Sysgen

Build Release Dir

Make Run-Time Image

1

2

3

4

0Pre-Sysgen Build

SYNNEX

Post-Sysgen Build Phase

Compile platform source codeUses Build.exe toolCompiles and links source code in $(_WINCEROOT)\PLATFORM\COMMONCompiles and links source code in BSP

Bootloader, drivers, OAL etc

Compiles and links source code in subprojectsUses filtered OS components

Libraries, header files

SYNNEX

Build Release Directory Phase

Build Release Directory Phase (BUILDREL)Copy output files to staging directory in preparation for making OS run-time image

Build

Dem

o Too

l (b

lddem

o.bat)

Post-Sysgen Build

Sysgen

Build Release Dir

Make Run-Time Image

1

2

3

4

0Pre-Sysgen Build

SYNNEX


Copy files to release directoryCopies OS binaries and configuration files from the OS design directory to the release directoryCopies project binaries and configuration files from the OS design directory to the release directoryCopies BSP binaries and configuration files from the BSP directory to the release directory

SYNNEX


Binaries automatically copied to release directory when built ifWINCEREL environment variable is set

No need to run entire buildrel phase for a single changed binaryMust run buildrel at least once

Hard link vs. xcopyCopy performed using hard link by default

Major performance enhancement

Do not edit files directly in release directorySome editors will cause original source file to changeUnexpected file corruption

Force xcopy with BUILDREL_USE_COPY environment variable if necessary

SYNNEX

Make Run-Time Image Phase

Make Run-Time Image Phase (MAKEIMG)Create operating system image

Build

Dem

o Too

l (b

lddem

o.bat)

Post-Sysgen Build

Sysgen

Build Release Dir

Make Run-Time Image

1

2

3

4

0Pre-Sysgen Build

SYNNEX

Make Run-Time Image Phase

Merges release folder files to create the Windows CE imageBased on a set of configuration files

ProcessMerge configuration files:All .BIB files into CE.BIB All .reg files into REGINIT.INIAll .dat files into INITOBJ.DAT All .db files into INITDB.INICompress reginit.ini in a binary registry file (DEFAULT.FDF)Replace resources in .exe and .dll for language adaptationFrom ce.BIB, combine binaries and files into a Windows CE image (NK.BIN)

SYNNEX

Build Phases

Not all build steps must be performed on every changeThese are guidelines onlyEfficient use of build steps comes only with experience

YesYesYesYes

MaybeYesYesMaybe

YesYesMaybeYes

NoYesNoNo

Change code in subproject

Add New Item from Catalog

Change Device Memory Layout

Change code in BSP

Sysgen

Post-Sysgen Build

Build Release Dir

Make Run-time Image

SYNNEX

Build Types

debug build - a run-time image that usually includes debug informationrelease (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.

The Build Tool Of The Build System

SYNNEX

SYNNEX

Build.exe – The Build Tool

Build.Exe parses DIRS and SOURCES to determine what to build, then calls NMakeNMake.exe uses the data in Sources (via a makefile) to determine how to build

Build.exe

Nmake.exeSources

DIRs \MyProjDIRS\Proj1

SourcesMakefile

SYNNEX

DIRS Files

DIRSContains a list of “project subdirectories”Text file that lists subdirectories containing other DIRS or SOURCES filesBUILD.EXE will read the contents of DIRS files to determine whatsubdirectories to enterSupports * 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

SOURCES

MAKEFILE.DEF%_MAKEENVROOT%

MAKEFILE

Local Project Folder

SYNNEX

SOURCES

SOURCESList of source code files for the project

TARGETNAMEName of output target (without extension)

TARGETTYPEPROGRAM – (.EXE) ApplicationDYNLINK – (.DLL) Dynamic Link LibraryLIBRARY – (.LIB) Static library

SYNNEX

SOURCES

TARGETLIBSList of libraries to include in the target

Not used when TARGETTYPE=LIBRARYTypically used for import libs from DLLs

SOURCELIBSList of source libraries to include in target

RELEASETYPEIndicates where build output file should be placed

LOCAL, OAK, PLATFORM

SYNNEX

SOURCES

POSTLINK_PASS_CMDSpecifies 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_CMDSpecifies a command to run BEFORE linking the final output

SYNNEX

SOURCES

Visual Studio 2005 contains SOURCES editorRight click on subproject and select PropertiesMost SOURCES functionality exposed

SYNNEX

MAKEFILE.DEF

Default MAKE rules for most aspects of the buildProvides standard rules for various types of targetsIncludes project SOURCES fileReduces amount of MAKEFILE “code” needed for each projectLocated in %_MAKEENVROOT%

%_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

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_COMMONPUBROOT__PROJROOT_ISVINCPATH_OEMINCPATH

SYNNEX

Mapping the IDE to the Command Line

Build MenuBuild Solution

blddemo –qRebuild Solution

blddemo clean –qBuild <OS Design project name>

blddemo -qRebuild <OS Design project name>

blddemo clean -qCopy Files to Release Directory

buildrelMake Run-Time Image

makeimg

SYNNEX


Build | Advanced Build Commands MenuSysgen

blddemo –qClean Sysgen

blddemo clean –qBuild and Sysgen Not Recommended

blddemoRebuild and Clean Sysgen Not Recommended

blddemo clean cleanplat -cBuild Current BSP and Subprojects

blddemo –qbspRebuild Current BSP and Subprojects

Blddemo –qbsp -c

SYNNEX


Targeted Build – BSPBuild

set wincerel=1&&build

Rebuildset wincerel=1&&build -c

SysgenSysgenPlatform %_TARGETPLATROOT% preproc&&SysgenPlatform %_TARGETPLATROOT% postproc

Build and Sysgenblddemo –qbsp

Rebuild and Sysgenblddemo –qbsp -c

SYNNEX


Targeted Build – SubprojectApplies to all sources subprojects

Includes sources subprojects in BSP

BuildSet wincerel=1&&build

RebuildSet wincerel=1&&build -c

SYNNEX


Build | Global Build SettingsApplies to builds initiated from the IDE menuModifies build behavior

Copy Files to Release Directory after BuildMake Run-Time Image After Build

Build | Targeted Build SettingsApplies to targeted builds initiated from the Solution ExplorerModifies build behavior

Make Run-Time Image After Building

SYNNEX

Downloading the Run-time Image

Configuration – Connectivity Options

SYNNEX


Configuration – Connectivity Options

SYNNEX


Download – Attach Device

SYNNEX


Note that during the download, the directory for the specific runtime image NK.BIN file is shown

SYNNEX


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.

Debug windows in Visual StudioRemote ToolsProgram 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 LineRUN from the Target Device’s Start Button.

Target Control Windows explorer

Target | Run Programs

SYNNEX

Remote Tools

Remote Zoom ToolRemote File ViewerRemote System Information ToolRemote Spy Tool Remote Performance MonitorRemote Kernel Tracker

CE 6.0 Directory Structure

SYNNEX

SYNNEX

Environment Variables in the Build

%_WINCEROOT% - Root of the Windows CE build installTypically C:\WINCE600

%_PUBLICROOT% - %_WINCEROOT%\PUBLIC%_PLATROOT% - %_WINCEROOT%\PLATFORMMany others

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 DirectoriesC:\WINCE600\OSDesignsC:\WINCE600\OTHERSC:\WINCE600\PLATFORMC:\WINCE600\PUBLICC:\WINCE600\SDK C:\WINCE600\PRIVATE

SYNNEX

Directory Structure

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

SYNNEX

The PLATFORM DirectoryIs located at the path %_WINCEROOT%\PLATFORMIs different for different hardwareplatformsContains Hardware Platform-specificBoard Support Platform (BSP) filesContains subdirectories that each represent a Windows CE–specific platform adaptation

\WINCE600\PLATFORM

SYNNEX

\WINCE600\PUBLIC

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

SYNNEX

\WINCE600\PRIVATE

Private DirectoryOption at installationAgree to separate Shared Source licenseIncludes full Kernel source code among others

Can ship modified versions of the private code with your productPremium (“Almost everything”) Source availableGWES componentsFilesys componentsOthers

SYNNEX

\WINCE600\PRIVATE

The Private Directory located at %_WINCEROOT%\PrivateContains 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 compilersDevelopment toolsMiscellaneous utilities

SYNNEX

\WINCE600\Others

The Others Directory is located at the path %_WINCEROOT%\OTHERS and contains subdirectories:

ATL8 DOTNETV2 EDBSQLCE20VISUALSTUDIO

SYNNEX


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

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

Common Shared Files: C:\Program Files\Common Files\Microsoft Shared

SYNNEX


Project Default DirectoriesVisual Studio 2005 Default OS Projects Dir C:\WINCE600\OSDesigns

Visual Studio 2005 Code Top Level Projects Dir C:\Documents and Settings\LoginName\My Documents\Visual Studio 2005\Projects

Board Support Package

SYNNEX

SYNNEX

BSP Overview

Acronym ReviewOEM - Original Equipment ManufacturerOAL - OEM Adaptation LayerBSP - Board Support PackageKITL – Kernel Independent Transport Layer

SYNNEX

BSP Overview

What does a BSP contain?Bootloader - Initializes hardware and launches the operating systemOAL – Hardware specific routines supporting OS kernel for interrupt handling, memory mapping etcDrivers for custom hardware devices not already supported by Platform BuilderConfiguration filesRequires circuit level design information

SYNNEX

BSP Overview

PLATFORM DirectoryContains all BSPs

Microsoft sample reference platformsThird party platformsYour BSP

Common DirectorySource code for libraries of routines available for use by BSPsContains implementations for many BSP requirementsNo platform specific dependencies

Platform Common Code Of Board Support Package

SYNNEX

SYNNEX

Platform Common Code

ArchitectureImplemented in \WINCE600\PLATFORM\COMMON

Organized by CPU dependency and functionExposed to BSP as libraries

Referenced with _PLATCOMMONLIB in sources file_PLATCOMMONLIB = (_PLATFORMROOT)\common\libBSP links to individual libraries as needed

SYNNEX


OrganizationCommon Code

\WINCE600\PLATFORM\COMMON\SRC\COMMONNo CPU dependenciesCPU independent modules, e.g.

• bootloader framework • kitl• PCI• interrupt framework• timer framework

SYNNEX


OrganizationCPU Architecture Specific

\WINCE600\PLATFORM\COMMON\SRC\<arch>ARM, MIPS, SHX, X86

May be further divided into sub architecture and common codeContains routines that are common to all CPUs in a particular architecture/familyCPU architecture dependent modules, e.g.

• cache routines• abort handlers• memory map support• architecture specific interrupt support

SYNNEX


OrganizationSystem On Chip (SOC) Specific

\WINCE600\PLATFORM\COMMON\SRC\SOC\<soc_vendor_version>E.g. PXA27X_MS_V1

Contains routines that support specific peripherals and CPU resources in a particular SOCMost CPU specific Common code is located in this areaSupposed to be hardware implementation independent

SYNNEX


DocumentationHeader Files

\WINCE600\PLATFORM\COMMON\INC\#include <oal.h>

Platform Builder DocumentationBringing Up a Hardware Platform

Developing a Board Support PackageDeveloping an OEM Adaptation Layer

Production-Quality OALSource code

Always the best documentation

SYNNEX


Using the Common codeLeverage an existing BSP that uses the Common code

Some Common code implementations dictate architecture of other BSP componentsEasier to implement with working example

Implement BSP specific callbacksBSP has interdependencies with Common code

Reference individual Common libraries in sources fileTARGETLIBS=$(TARGETLIBS) \

(_PLATCOMMONLIB)\$(_CPUINDPATH)\oal_cache_pxa27x_ms_v1.lib \

BSP Components Of Board Support Package

SYNNEX

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 devicePurpose

Initialize hardwarePerform any device specific action that needs to occur prior to booting the operating systemLoad the operating system image into memoryJump to the operating system entry point

Typically implemented as a separate componentWill have its own .bib file

SYNNEX

Bootloader

Each bootloader is uniqueWindowsCE does not impose any restrictions or requirements on loader code except to call OS entry point with MMU off and hardware properly initializedOEMs have unique needs for custom bootloader functionality

Support custom user interface for low level device managementDiagnosticsLoad operating system from various resources

BLCOMMON library provides one possible implementation frameworkDo 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 simpleInitialize hardwareCall BootloaderMain()Implement required callbacks

Use other Common libraries as neededSupports integration with Platform Builder tools

Download images across debug connectionExtensible

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 hardwarePurpose

Handles interrupts, timers, power management, etc.Implements the operating system entry point Essentially is the kernel “process” containing kernel mode DLLs

SYNNEX

OAL

ArchitectureOAL is a separate component

-No longer statically linked as part of OS kernelOAL must implement set of required functionsOAL and Kernel each expose interface as export table - Can only call exported functions

SYNNEX

OAL

OAL Directory StructureSRC\OAL\OALLIB

Contains BSP specific OAL functionsBuilds as library that will eventually link with others to create OAL

SRC\OAL\OALEXEContains sources file with build instructions for OAL.EXELinks OAL.LIB along other Microsoft supplied libraries to createOAL.EXEOAL.EXE is renamed to NK.EXE during build process

SYNNEX

OAL – Required Function Interface

Implement using Common libraries Common libraries provide implementation for many required OAL functionsLibraries may require callback functions implemented in BSP to handle BSP specific functionalityLibraries may require custom data structures to be implemented in BSPOAL architecture based on Common libraries called Production Quality OAL (PQOAL)

Implement directlyNo requirement to use Common codeCan selectively choose functionality from Common code

May be a good choice for BSPs derived from a non PQOAL source

SYNNEX

OAL – Common Functions

OEMInitDebugSerialFirst call to OEM code by kernelOpportunity to initialize serial debug communications

OEMInitSecond call to OEM code by kernelVery early in boot sequence

No system calls allowedSingle threadedNo blockingException handlers not available

Initialize all necessary hardware interfaces, OS timer etcRegister ISRs (except ARM)Initialize Kitl

SYNNEX


OEMInterruptEnableEnables specified interrupt based on interrupt identifierCalled by InterruptInitialize and InterruptMask

OEMInterruptDisableDisables specified interrupt based on interrupt identifierCalled by InterruptDisable and InterruptMask

OEMInterruptDoneUnmasks specified interrupt based on interrupt identifierCalled by InterruptDone

OEMInterruptHandler (ARM only)Interrupt handler function (ISR)Returns interrupt identifier corresponding to interrupt source

SYNNEX


OEMIdleCalled when no threads are scheduled to runOpportunity to place CPU in low power state

OEMPowerOffCalled in response to SetSystemPowerState()POWER_STATE_OFFPOWER_STATE_SUSPEND POWER_STATE_CRITICAL

Place CPU in lowest power “suspend” state

SYNNEX


OEMIoControlCalled in response to KernelIoControlGeneric IOCTL interface for the kernelSome standard IOCTLs must be implementedCan be extended by the OEMImplements interrupt identifier management

SYNNEX

OAL – Common IOCTLs

IOCTL_HAL_INIT_RTCResets the realtime clock

IOCTL_HAL_GET_DEVICE_INFOSupports SystemParametersInfo function

IOCTL_HAL_REQUEST_IRQReturns IRQ based on device location

IOCTL_HAL_REQUEST_SYSINTRReturns interrupt identifier based on IRQ

IOCTL_HAL_REBOOTWarm boots the target device

SYNNEX


OEMSetRealTime/OEMGetRealTimeCalled by the kernel to get/set the real time clockCalled in response to Get/SetSystemTime

OEMSetAlarmTimeSet the Real Time Clock alarm

SYNNEX

Drivers

Most CPUs have peripherals or expansion bus interface that can support peripherals

A particular hardware platform may require drivers for a subset of available peripheralsMicrosoft provides driver support for many peripherals

Some drivers fully implemented outside of the BSPSome drivers require BSP support for platform specific implementations

Drivers not fully implemented by Microsoft must be provided in BSP

SRC\DRIVERS

SYNNEX

Drivers

Drivers are found in several placesPUBLIC tree

\PUBLIC\COMMON\OAK\DRIVERSProvided by MicrosoftBus agnostic driversExternal 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

Contains support for peripherals that exist on CPU siliconSome SOC drivers may be fully implemented in Common codeOther drivers may require some BSP support for platform specificfunctionality

BSPCustom devices that don’t have driver support from MicrosoftDrivers obtained from third partiesCloned (copied) versions of Microsoft provided driversHardware specific (PDD) implementations

Miscellaneous Files Of Board Support Package

SYNNEX

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

Binary Image Builder (*.bib)Specify files to be included in the run-time imageSpecify memory configuration and use

Registry (*.reg)Specify the initial registry

File System (*.dat)Specify the initial directory structure

Database (*.db)Specify initial database contents

Configuration Files

SYNNEX

Configuration Files: .BIB Files

MEMORY section Partitions the memory into two types

RAMIMAGE Contains OS image (‘ROM’), supports XIPRAM Program and Data memory

CONFIG sectionContains settings that control certain kernel featuresContains settings that control characteristics of the build output file

Name Start address Size(bytes) Type-----------------------------------------------NK 8C800000 00800000 RAMIMAGERAM 8C050000 007B0000 RAM

Name Start address Size(bytes) Type-----------------------------------------------NK 8C800000 00800000 RAMIMAGERAM 8C050000 007B0000 RAM

SYNNEX

The Configuration Files: .BIB Files

MODULES sectionLists modules to include in the run-time imageComponents in this section will be configured to XIPOnly executable modules can be listed here

FILES sectionOther modules to be included in the run-time imageCan include both executable modules and data filesWill be managed by the object store file system

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

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

SYNNEX

FILES – Config.bib

MEMORY SectionRAMIMAGE Type

Specifies memory range OS will execute fromVirtual Addresses

Corresponds to mapping in OEMAddressTable (ARM, X86) or fixed static mapping (other processors)

Could be RAM or ROMVirtual memory range must be physically contiguousMust be aligned on 64KB boundarySize must be 64KB granularityMust be large enough to contain the entire operating system image

SYNNEX


MEMORY SectionRAM Type

Specifies memory range available for program and storage (working RAM)Virtual Addresses

Corresponds to mapping in OEMAddressTable (ARM, X86) or fixed static mapping (other processors)

Must be RAMVirtual memory range must be physically contiguousMust be aligned on 64KB boundarySize must be 64KB granularity

SYNNEX


MEMORY SectionRESERVED Type

Ignored by build toolsDocument use of other memory regions

BootloaderDMA buffersFramebufferEtc

SYNNEX


CONFIG SectionAUTOSIZE

Allows boundary between RAM/RAMIMAGE sections to be dynamically determinedMakes efficient use of RAM resourcesOnly works with images running entirely from RAM

SYNNEX

FILES – Platform.bib

Lists BSP components to be included in the imageModules Section

Components in this section will XIP if not compressedCan only include executable components, no data filesComponents can’t be accessed as files because header information is stripped away

FILES SectionComponents in this section are included with full headersCan be manipulated as filesExecutable code will be paged into memory for execution

Flags specify component characteristicsE.g. USER/KERNEL, Hidden, System etc

All components end up in \WINDOWS directory

SYNNEX

Configuration Files: .REG Files

Define default registry settingsCOMMON.REG, IE.REG, WCEAPPS.REG, WCESHELL.REG: define registry settings for Windows CE modulesPLATFORM.REG: platform-dependent registry settings, such as device driver entriesPROJECT.REG: defines registry settings relative to your project

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

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

SYNNEX

BIB REG Editor VS2005

SYNNEX

The Configuration Files: .DAT Files

Define directory structuresAll files are located in \Windows (ROM)Filesystem parses information provided by .dat files to create and populate additional RAM directory structureResults in multiple copies of files

Example:Root:-Directory(“Program Files”)Directory(“\Program Files”):-Directory(“My Projects”)

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

Root:-Directory(“Program Files”)Directory(“\Program Files”):-Directory(“My Projects”)

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

SYNNEX

The Configuration Files: .DB Files

Define databases in the object storeVarious OS components create databases for their own usePlatform.db adds BSP specific database entriesProject.db adds OS design specific database entriesMerged into initdb.ini and included in the image

Creating a New BSP Of Board Support Package

SYNNEX

SYNNEX

Creating a New BSP

Always start with a reference BSPDon’t attempt to create a BSP entirely from scratchFind a reference BSP that most closely matches your target hardware platform

CPU vendorMicrosoft reference BSPsThird party systems integrator

SYNNEX

Creating a New BSP

Clone the source BSPThis preserves the original BSP

Original reference remains intactChanges made by source vendor do not overwrite your changesNever modify code you did not clone!

Use the Clone Tool provided in Platform BuilderTools->Platform Builder for CE 6.0->Clone BSP

SYNNEX

Creating a New BSP

Port the BSPUpdate areas of the BSP that differ from your target hardware

Requires a thorough understanding of your hardware implementationMust analyze the entire BSP code base

Memory map System initializationInterruptsGPIO configurationPeripheral implementation

Difficulty varies depending on how close the reference BSP matches target hardware and quality of original BSPNot a trivial task

SYNNEX

Creating a New BSP

Update BSP FeaturesImplement the unique requirements your device requires

Bootloader featuresCustom driversSupport new OS features

Build/Test/Ship!

The SDK Of Customizing the OS

Design

SYNNEX

SYNNEX

SDK

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

Platform Builder

OS Design ExtensionsRun-time Files

Platform Manager

Headers and Libraries

SDK Documentation

Custom SDK

Microsoft Embedded Development Software

Visual Studio 2005

SYNNEX

SDK Development Steps

Build OS Design – create a run-time imageConfigure the SDK – use the SDK Wizard to configure basic settingsBuild the SDK - created SDK is a Microsoft Windows Installer (MSI) packageInstall 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)

Operating System Internals

SYNNEX

SYNNEX

CE 6.0 Architecture – User Processes

Shell – Standard or custom interface for the deviceServicesD.EXE has the ability to host n number of ServicesUDevice.EXE has the ability to host n number of user mode drivers

Windows CEApplication Shell

ServicesD.EXE Udevice.EXE Udevice.EXE

UserMode

Driver 1

UserMode

Driver n

Win32 CE APIs – COREDLL / WINSOCK / COMMCTRL / COMMDLG

Service1

Servicen

SYNNEX

CE 6.0 Architecture – Kernel

FILESYS.DLL – Init sequence, Object Store, notifications etcFSDMGR.DLL – File system support GWES.DLL – Graphics, Windowing, and Events SubsystemNetworking DLLs – NDIS based networking servicesDEVMGR.DLL provides device driver servicesKITL.DLL (Optional)

KERNEL.DLL DEVMGR.DLLGWES.DLL

FILESYS.DLL


OALDrivers FSDMGR.DLL

NetworkingDLLs

KCOREDLL.DLL

SYNNEX

CE 6.0 Architecture – Kernel

The Kernel contains base OS servicesAPI 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

KERNEL.DLL DEVMRG.DLLGWES.DLL

FILESYS.DLL



NetworkingDLLs

KCOREDLL.DLL

SYNNEX

CE 6.0 Architecture - Hardware

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


FILESYS.DLL



NetworkingDLLs

KCOREDLL.DLL

RAMROM

IRQControlCPU USB SDIO Touch Display

Keyboard OEM PAN WANLAN MAN

SYNNEX

CE 6.0 Architecture



UserMode

Driver 1

UserMode

Driver n


Service1

Servicen


FILESYS.DLL


NetworkingDLLs

KCOREDLL.DLL

OAL Component

SYNNEX

CE 6.0 Architecture



UserMode

Driver 1

UserMode

Driver n


Service1

Servicen


FILESYS.DLL


NetworkingDLLs

KCOREDLL.DLL

Microsoft OEM ISV

SYNNEX

Applications, Processes & Threads

ApplicationA logical group of executable code

ProcessA process is a single instance of an applicationStatic context within which one or more threads executeUp to 32,000 processes loaded simultaneously

ThreadBasic unit of execution managed by the schedulerEach process has at least one thread called the primary threadNumber of threads limited by maximum number of handles in a process

Operating System Internals Memory

Architecture

SYNNEX

SYNNEX

Memory Architecture Overview

Memory Overview Virtual Memory ModelProgram Memory

Heaps and StacksProcesses, Threads and Memory

Memory System Tools

SYNNEX

Memory Overview

Memory TypesRandom Access Memory (RAM)Read Only Memory (ROM)

What Uses Memory? Bootloader

Operating SystemApplications

Object Store - File system, Registry, DatabasesShared heapMemory Mapped Files

SYNNEX

Memory Overview

Operating System Image Requires SpaceThe operating system image itself is located in RAM or ROM at runtimeOften copied to RAM in totality from a storage location (hard drive, flash memory) by the bootloaderRAM occupied by the OS image is not available for application useCould be in located in ROM and not copied to RAM

SYNNEX

Memory Overview

eXecute In Place (XIP)Allows execution of programs from directly from their location in the OS image in memoryLoader does not need to copy into RAM and fixupaddressesPreserves limited RAM resources especially when XIP from ROM

SYNNEX

Memory Overview

User Settable Program vs. Storage MemoryProgram Memory is available for application use 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 MemorySingle 32-bit (4 Gigabyte) flat virtual memory address spacePermits efficient use of physical memory with protection

Virtual AddressingMemory Management Unit (MMU) “owns” physical memoryVirtual addresses translated to physical addresses by MMUA valid virtual address must map to a physical addressStatic or Dynamically mapped virtual addressingAll CE components use virtual, not physical addresses

Physical AddressingUsed 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

2 GBUser

512 MBUncached

512 MBCached

Physical Memory Virtual Memory

04000000

82000000

8000 0000

A000 0000

C000 0000

00000000 0000 0000

FFFF FFFF

AddressTranslation

Kernel Space

UserSpace

32 MB Flash

64 MB Flash

64 MB RAM

32 MB Flash

64 MB RAM

32 MB Flash

SYNNEX

Virtual Memory Map

2 GBkernelspace

Process code

Memory mapped files

User DLLs

KernelFilesystem

GWESDrivers

. . . .

. . . .

32 Kprocesses

2 GB VMper

process

SYNNEX

Kernel Memory Space

Kernel Space 2 Gigabytes

Fixed mapping

independent of user space

CPU Specific VM

Kernel VM(if supported by CPU)

256 MB

Kernel VM256 MB

Object Store (128 MB)Kernel XIP DLLs (128 MB)

Static MappedUncached

512 MB

Static MappedCached512 MB

SYNNEX

User Memory Space

User Space 2 Gigabytes

Each process has its own

mapping

Shared System Heap255 MB

RAM Backed Mapfiles256 MB

Shared User DLLs512 MB

Process Space1 GB process

SYNNEX

Program MemoryProgram Memory

RAM available for use by OS/Drivers/ApplicationsData RAM, does not include code pagesMajor Types of Program Memory

HeapThe primary area of memory used by the application

Stack Storage area for variables referenced in a program

RAM available for use by OS/Drivers/ApplicationsData RAM, does not include code pagesMajor Types of Program Memory

HeapThe primary area of memory used by the application

Stack Storage area for variables referenced in a program

SYNNEX

Program Memory - Heap

Heap CharacteristicsDynamic memory allocationProcessor-independent (hides memory paging)Automatically allocates memory and commits pages on demand

SYNNEX

Program Memory - Heap

Types of Heap MemoryLocal Heap (Default)

Reserves virtual memory at process load timeCommits physical pages on demand

Private HeapReserves initial fixed size or expandable (disjointed) heap spaceSerialization for mutual exclusion of multiple threads

Shared HeapWritable to kernel and read only to user processesVisible to all user processes

Remote HeapShared between user processes

SYNNEX

Program Memory - Stack

CreationDefault stack allocated for each thread at creationAll threads of a process have same stack size by defaultDefault thread stack size override with /STACK linker switchIndividual 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

Each Process has at least one heapEach Thread has a stack

Heap

Process

Stack

Primary Thread

Stack

Additional Thread

Stack

Additional Thread

Operating System Internals Threads and Scheduling

SYNNEX

SYNNEX

Threads

Scheduler provides efficient context switching among threadsEach process has one or more threadsEach thread has its own context (stack, priority, etc)Predictable sequence of thread execution based on priority

SYNNEX

Processes and Threads

Priority-based SchedulingPreemptive scheduling within 256 priority levelsRound-robin scheduling of threads on same priorityPriority 0 (or highest priority) threads run to completion

SYNNEX

Scheduler – Quantum Time Slicing

Same priority threads run in round-robin fashionSwitch threads when blockedSwitch threads after quantum has elapsedProgrammable quantum from 1 to N ms, default 100 ms

Thread 1

t1

Thread 3 P=252

Thread 1 P=0

Thread 2 P=252

t2 t3 t4 t5 t6 t7

Thread 1

Thread 2 Thread 2

Thread 3 Thread 3

SYNNEX

Thread Priority Map

Used by the default Windows Embedded CE–based device drivers

97-152

Mapped to other non-real-time priorities248-255

Typically reserved for non-real-time drivers153-247

Typically reserved for real-time drivers 0 - 96ComponentPriority

SYNNEX

Priority Inversion

Thread 3

High Priority

Medium Priority

Low Priority

Thread 3Resource Owner:

Thread 2

Thread 1

Thread 1

OS PriorityInversion

Preempt

Preempt

OS PriorityRestoration

Thread 3

Thread 3 Thread 1

Thread 2

SYNNEX

Thread APIs

Thread CreationCreateThreadCreates a new thread at normal priority

Thread PriorityCeGetThreadPriorityGet current priority level of a thread

CeSetThreadPrioritySet priority level of a thread

SetThreadPriorityLegacy function

GetThreadPriorityLegacy function

SYNNEX

Thread Blocking APIs

Thread Blocking APIsSleep (n) – minimum number of milliseconds to suspend executionSleep(0) – relinquish remainder of quantum to other threads with the same prioritySleepTillTick – suspend execution until next system tickWaitForSingleObject – block until specified kernel object is signaledWaitForMultipleObjects – block until one of a set of specified kernel objects is signaled

Operating System Internals Interrupt

Model

SYNNEX

SYNNEX

Interrupt Model

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

KERNEL.DLLException Handler

Device Interrupt Service Routine (ISR)

InterruptService Thread(IST)

Inte

rrupt

Event

1

2

3 4

Inte

rrupt

ID

SYNNEX

Interrupt Service Routine (ISR)

Registered to an IRQCalled to handle the hardware interruptAcknowledges hardware and determines Interrupt IDReturns Interrupt ID (SYSINTR) to kernelStatic (built into NK.EXE) or Installable (chained in) via Kernel callMust be written to run quickly with no outside dependencies

SYNNEX

Interrupt Service Thread (IST)

Thread registered to handle an interruptPerforms majority of interrupt handling taskCreated by a device driverStandard thread that waits for interrupt eventsScheduled like any other thread in the systemPerforms device-specific servicing for Interrupt ID Signals completion of interrupt processing to hardware

SYNNEX

ISRs And ISTs Work Together

ISRs and ISTs work as pairsISR identifies and masks interrupt quicklyIST handles the bulk of the work

Synchronized by using an Event ObjectIST creates an Event Object mapped to SYSINTR IDIST blocks on event with WaitForSingleObjectISR returns SYSINTR to kernelKernel 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 timeTypically used for shared interruptsThere must already be an ISR registered for that IRQ supporting shared interrupts

ISR implemented in a DLLLoaded into kernel by LoadIntChainHandlerOAL ISR MUST call NKCallIntChain for all shared IRQs

SYNNEX

Shared Interrupts Using Chaining

Some platforms designed to have several devices use same interrupt lineOne interrupt that is shared by allMultiple ISRs chained to handle shared interruptsEach ISR, in turn, determines if it owns the interrupt

ISR1

ISR3

ISR2

Shared Interrupt Line

Bar CodeScanner

PowerSwitch

WiFiReceive

Operating System Components Power

Management

SYNNEX

SYNNEX

Concepts – Role of the Power Manager

What is the Power Manager?OS component responsible for meeting the power needs of the system efficientlyApplication Interface

Applications communicate their power needsApplications can choose to receive notification of power relatedevents

Device InterfaceIndividual devices request their desired power state based on needPM determines actual device power statesDevices must operate in state set by Power Manager

SYNNEX

Concepts – Role of the Power Manager

ApplicationApplication

Power Manager Power Manager APIsAPIs

DriversDriversPowerPower

ManagerManager(pm(pm.dll.dll))

NotificationNotificationMessageMessageQueueQueue

Driver Driver APIsAPIs

Application Application APIsAPIs

SYNNEX

Concepts – Device Power States

Device Power StatesPower level of a given device

Device in this context means individual hardware peripheral

Fixed number of predefined statesD0 Full on Full functionalityD1 Low on Full functionality, reduced performanceD2 Standby Partial power, auto wakeup on requestD3 Sleep Partial power, can wake upD4 Off No power

Devices may implement a subset of statesDevice determines how a particular state is implemented

SYNNEX

Concepts – System Power States

System Power StatesNamed power states for entire system

Defined by the OEMAct as global setting for device power states

Set maximum device power states Default implementation provided by Microsoft

On User actively using deviceUserIdle User passively using the deviceSystemIdle User not using the deviceSuspend Device powered down

SYNNEX

Concepts - System Power States

System power states map to device power states in the registryDefault mapping for all devices

Default implementationOn D0UserIdle D1SystemIdle D2Suspend D3

Individual devices can have exceptions to defaultExample: Suspend state maps to D4 for NDIS devices

OEM can easily modify device power state to system power state mapping using the default Power Manager implementation

SYNNEX

Concepts – Activity Timers

Activity TimersNamed timers implemented by Power Manager

Configurable in registryAny number of timers can be implementedGeneral purpose mechanism that can be used by any component

Implemented with named eventsUsed by default Power Manager implementation

PM implements two timers for its own useUsed to determine user and system activitySome OS components reset timers to indicate activity

GWES, Networking

SYNNEX

Power Manager Implementation

Power Manager implementation provided by MicrosoftWINCE600\PUBLIC\COMMON\OAK\DRIVERS\PMMDD/PDD modelPDD defines the supported system power statesPDD contains logic that determines when/how to transition between system power statesOEMs 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

Decision logic implemented in PDDDefault implementation based on activity timers

UserActivity timerSystemActivity timer

Timer settings exposed to user with control panel applet

SYNNEX

Device Power Management

Power Manager support optional in driverPM only controls drivers that are Power Manager awareDrivers not required to support Power ManagerDevices must advertise that they support the Power Manager interface for PM control

Iclass registry entry with Power Manager GUIDAdvertiseInterface with Power Manager GUID

SYNNEX


Device Power State ChangesDrivers may not change power state unless instructed to by Power ManagerDrivers should manage power within a power state on their ownDrivers can request that the Power Manager change their state

Power Manager may change to requested state, another state, or no change at allDrivers must not assume that their request will be honored

SYNNEX


Drivers communicate power needs with DevicePowerNotifyPower Manager sets device state with DeviceIoControl

Drivers must expose stream interface

PowerPowerManagerManagerPM.DLLPM.DLL

Device DriverDevice Driver

PM APIsPM APIs

DeviceIoControlDeviceIoControlDevicePowerNotifyDevicePowerNotify

SYNNEX


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 eventsRequestPowerNotifications/StopPowerNotificationsNotifications generated by Power Manager

Uses point to point message queues

Applications register for desired event typeSystem power state transitionsChange between AC/DC power sourcesResume occurredBattery power status field has changed

Notification only, no opportunity to modify, delay or block event

SYNNEX


Applications can request a system power state changeSetSystemPowerState will instruct the Power Manager to change power states

Specify by nameSpecify by “hint” (bitmask)

System power states are OEM defined, so applications may not know state names

Power manager chooses most appropriate state based on hintHint bitmasks defined by Microsoft for standard state types

Power Manager may restrict applications from entering certain system power states

SYNNEX


Applications can set power requirement for a deviceApplication calls SetPowerRequirement to request a specific device maintain a minimum power stateAllows device to be at a higher power state than system power state would otherwise allowApplication should call ReleasePowerRequirement as soon as possible to allow normal power management to continue

SYNNEX

Application Power Management APIs

GetSystemPowerStateRetrieve the current system power state

SetSystemPowerStateRequest a particular system power state

SetPowerRequirementRequest specific device to maintain minimum power level

ReleasePowerRequirementRelease device requirement

RequestPowerNotificationsRequest notification when certain types of power related events occur

StopPowerNotificationsNo longer have a need to receive power notifications

SYNNEX

Idle Power Management

Kernel knows when no threads are runningCalls OEMIdle to put the CPU in lower power states

Must be supported by CPU

Transparent to rest of system and userIndependent of Power ManagerSmall change here = big change in Standby time

Majority of time spent is in OEMIdle

SYNNEX

Suspend/Resume

SuspendLowest possible power stateDevice is off from user perspective, but maintains volatile memoryMust be supported by cpu

Resume“Instant on”Returns to state that existed prior to entering suspendTransparent to applications

SYNNEX

Suspend/Resume

Power Manager implements suspend/resume sequenceInitiated in response to SetSystemPowerStateDrivers participate in suspend/resume process

Includes drivers that are not managed by Power Manager

Applications can initiate suspend sequence if permitted by Power Manager implementationApplications have no opportunity to block or otherwise participate in the suspend sequence

SYNNEX

Suspend/Resume

Suspend PathPM disables all PM-aware non-block driversPM calls IOCTL_HAL_PRESUSPENDPM notifies file systemsPM disables all PM-aware block driversSystem goes “single threaded”Kernel calls all legacy xxx_PowerDown functionsKernel calls OEMPowerOff

SYNNEX

Suspend/Resume

Resume PathCPU wakes up and continues executing OEMPowerOff returnsKernel calls all legacy xxx_PowerUp routinesSystem goes multi-threadedPM enables PM-aware block driversPM enables file systemsPM enables remaining PM-aware drivers

Operating System Components

Internationalization

SYNNEX

SYNNEX


Platform localization optionsLocalization vs. InternationalizationChanging the language of your operating system

SYNNEX


Locale Support ArabicEnglish (U.S.)English (Worldwide)FrenchGermanHebrewIndicJapaneseKoreanSimplified ChineseTraditional ChineseThai

SYNNEX


Adding localesSelecting codepages

SYNNEX

Multilingual User Interface

Allows users to change the language of the user interface (UI)Single core binary that includes the system default languageOne resource dynamic–link library (DLL) for each additional target language

CE OSCE OS

GermanGermanDLLDLL

FrenchFrenchDLLDLL

EnglishEnglishDLLDLL

SpanishSpanishDLLDLL

SYNNEX

Internationalization Components

National Language Support (NLS)Multilingual User Interface (MUI)Unicode Script Processor for Complex ScriptsInput Method Manager (IMM)Handwriting Recognizer Engine (HWX)Keyboards and Fonts for Many LanguagesAdditional language specific components

Device Driver Concepts

SYNNEX

SYNNEX

Driver

Application

What is a Device Driver?

A device driver is software that abstracts the functionality of a physical or virtual device

CE 6.0

Device

SYNNEX

Device Driver Categories

Drivers are classified in a number of different waysNative vs Stream

Who loads the driver

User vs KernelWhere the driver is loaded

Monolithic vs Layered (MDD/PDD)How the driver is architected

Built In vs Dynamic/InstallableWhen the driver is loaded

Driver FamilyWAV/Miniport/Touch/Display/Serial etc

SYNNEX

MDD/PDD or Layered DriversModel Device Driver + Platform Device Driver = DriverSample implementations provided by MicrosoftMDD implements functionality common to all similar devicesMDD implements defined architecture for specific driversMDD can often be used unmodifiedMDD calls PDD functions for hardware specific functionalityPDD must be customized to match target hardwareInterface to PDD is sometimes called DDSIProvides for code reuse, ease of implementationCan be less efficient due to layering

Monolithic vs Layered

SYNNEX

Monolithic DriversDoes not leverage high level shared library of interface routinesWritten to implement requirements as efficiently as possibleCan have increased or otherwise unique feature set (not dependent on MDD implementation)Less code reuse, more complex developmentCan be more efficient due to streamlined functions

Monolithic vs. Layered

SYNNEX

Hybrid DriversMDDs are not immutable. Clone and modify as necessaryModified MDDs are often used to implement missing feature requirementsMaintains ease of development benefits by starting with existing high level driver implementation

Monolithic vs. Layered

SYNNEX

NativeFixed set of native device classes defined by CE

•Keyboard•Display•Touch

Drivers loaded directly by GWES, not managed by deviceEach has its own model

Native vs. Stream

SYNNEX

Native Device Driver Model

Monolithic Native Driver

Device Driver Interface (DDI)

Graphics, Windowing, and Events System (GWES)

MDD

PDD

Device Driver Interface (DDI)

Device

SYNNEX

Native vs. Stream

Stream DriversLoaded and managed by Device ManagerSupport any type of physical or virtual deviceDevice Manager imposes minimum interface requirements (driver entry points and behavior)Stream model applies to most driversExposed to applications through filesystem APIs Can be loaded at boot or dynamically

SYNNEX

Stream Interface Device Driver Model

Monolithic Stream

Interface Driver

Stream Interface

Stream Interface

NDIS Wrapper

Device Manager

Stream Interface

(DDI)

MDD

NDIS NDIS Wrapper

NDIS Miniport

PDD

Device

Stream Driver Architecture

SYNNEX

SYNNEX

Device File Names

Drivers can be accessed as special file system deviceThree different namespaces provide different features

Share common 3 letter prefixLegacy

Example: “COM1:”

Device Example: “\$device\COM1”

Bus Example: “\$bus\PCMCIA_0_0_0”

Named interface not required

SYNNEX

Device File Names

Legacy NamespaceOriginal naming conventionUsed by most legacy driversConsists of Prefix followed by Index (0-9)

Limited to 10 instances of a particular prefix (COM0 -COM9)

Prefix included in driver entry pointsUnless special registry flag is set

SYNNEX

Device File Names

DeviceSimilar to Legacy namespaceConsists of Prefix followed by numberProvides support for more than 10 devices

“\$device\COM27”

SYNNEX

Device File Names

BusTypically used with client drivers loaded by a bus driverProvides mechanism to differentiate between IO and bus control operationsProvides mechanism for more sophisticated driver loading/unloading/power management features

SYNNEX

Stream Driver Architecture

Application

File System

Stream Interface Driver

(Loaded at Boot up)Window CE

Kernel

DeviceManager

Hardware Platform Built-inDevice

HardwareSoftware

Interrupt EventsOAL

CreateFile

SYNNEX

Implementing Generic Stream Drivers

How do you implement a Stream Driver?Select a device file name prefixImplement the required entry pointsCreate the *.DEF fileCreate the registry values necessary to load your driver

SYNNEX

Stream Entry Points: Init, Deinit

XXX_InitCalled when Device Manager loads the driverInitialize necessary resources Perform memory mappingInitialize IST

XXX_DeinitCalled when Device Manager unloads the driverFrees allocated resources, stops the IST

SYNNEX

Stream Entry Points: Open, Close

XXX_OpenCalled in response to CreateFile on device nameProvides handle for use by other IO functionsAllocate resources for open context and prepare for operation

XXX_CloseCalled in response to CloseHandleClean up open context

SYNNEX

Stream Entry Points: Read, Write and Seek

XXX_ReadCalled in response to ReadFile

XXX_WriteCalled in response to WriteFile

XXX_SeekCalled in response to SetFilePointer

SYNNEX

Stream Entry Points: IOControl

XXX_IOControlCalled in response to DeviceIoControlProvides mechanism supporting custom driver operationsWorkhorse of most driversI/O control code identifies the operationI/O control code is device-specific

SYNNEX

Stream Entry Points: PowerUp, PowerDown

XXX_PowerDownCallback notifying device that OS is suspendingAllows driver to perform any desired operations necessary to go into low power mode

XXX_PowerUpCallback notifying device that OS is resumingAllows driver to perform any desired operations necessary to exit low power mode

SYNNEX

Stream Entry Points: PreClose, PreDeinit

XXX_PreCloseCalled prior to XXX_Close when application calls CloseHandleProvides opportunity for driver to wake sleeping threads Eliminates potential race condition with multiple threads

XXX_PreDeinitCalled prior to XXX_Deinit when driver unloadsProvides opportunity for driver to mark handle as invalidEliminates potential race condition with multiple threads

SYNNEX

Stream Driver Interfaces – Entry Points

Application calls DeviceIoControlxxx_IOControl

OS resumes from suspend statexxx_PowerOnOS enters suspend statexxx_PowerOff

Application calls SetFilePointerxxx_SeekApplication calls WriteFilexxx_WriteApplication calls ReadFilexxx_Read

Application calls CloseHandlexxx_CloseApplication calls CreateFilexxx_OpenThe driver is de-initialized (unloaded) xxx_DeInitThe driver is initialized (loaded)xxx_InitCalled When Function

User Mode Driver Framework

SYNNEX

SYNNEX

User and Kernel Mode Drivers



UserMode

Driver 1

UserMode

Driver n


Service1

Servicen

KERNEL.DLL DEVMRG.DLLGWES.DLL

FILESYS.DLL


NetworkingDLLs

K.COREDLL.DLL

User

Mem

ory S

pace

Kern

el Me

mor

y Spa

ce

Marshalling

SYNNEX

User vs. Kernel Mode Drivers – Kernel Mode

Default driver modelRun in kernel memory spaceLink to kernel version of coredll, k.coredll.dll

Automatic, no need to change build rulesHighest performance

Fast access to kernel APIsDirect access to user buffers

Must be robustDriver crash could corrupt kernel

SYNNEX

User vs. Kernel Mode Drivers – User Mode

Also managed by Device managerHosted by udevice.exeClose compatibility with kernel mode driversUM Drivers lose Kernel privileges

No access to kernel structures or memoryCannot call certain kernel only APIsRestricted access to other kernel APIs

Increases system stabilityExamples

Expansion buses like USB and SDIO

SYNNEX

Improved stabilityUser-Mode Drivers are isolated from other driversKernel is isolated from user-mode drivers

Increased securityKernel protected from compromised driversLower privileges restrain a compromised driver

RecoverabilitySystem can recover after a driver crash Driver can be restarted without rebooting

User Mode Driver Framework

SYNNEX

Loading a User Mode Driver

1

User ApplicationUser Mode Driver Host Process

udevice.exe User Mode DriverUser Mode Driver

Parent Bus Driver

Reflector ServiceDevice Manager

1

2

3 9

8

10

User Mode

Kernel Mode

ActivateDeviceEx

CreateProcess(,,Volume Name)

4

56

7

XXX_Init(…)

9

Device Context

10

HANDLE Returned

HANDLE Returned

XXX_Init forwarded to UM Driver Host

SYNNEX

Registry For User Mode Driver

User Mode Driver Host process is launched and managed by registry settingsExample 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

Use K flag to fix up to kernel spaceRemove K flag to fix up to user spaceUse Q flag to fix up both places

Driver in FILES section can be loaded into user or kernel space

Device Driver Concepts Interrupts

SYNNEX

SYNNEX

Interrupt Terminology

ISR – Interrupt Service RoutineRuns in OALIdentifies interrupt source and returns Interrupt ID to kernelMinimal processing – identify and mask interrupt

IST – Interrupt Service ThreadRuns in device driverSignaled by kernel when ISR returns corresponding Interrupt IDPerforms bulk of processing necessary to handle interrupt

SYNNEX

Interrupt Terminology

IRQHardware identifier indicating interrupt sourceInterpretation specific to BSPCould map to multiple SYSINTRs (shared interrupts)

SYSINTRSoftware identifier indicating interrupt sourceMapped to a single IRQ by the OAL Associated with Event object by InterruptInitializeReturned by ISR to kernel

SYNNEX

Setup Interrupt

SYSINTR value needed to associate with interruptMight be hard coded into driver (non portable)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 OALCreate Event object

Normal event objectWill be signaled by the kernel when ISR returns SYSINTR

Associate event with SYSINTR (InterruptInitialize)Configures kernel with SYSINTR<->Event mapping

SYNNEX

Interrupt Service Thread

Create IST thread using CreateThreadIST is just a secondary thread in the host process

Adjust thread priority using CeSetThreadPriorityRetrieve thread priority from registry if available

IST loopBlock on event using WaitForSingleObjectProcess interrupt when event is signaledCall InterruptDone to unmask interrupt

SYNNEX

Installable ISRs

Allows a driver to install an ISR at run timeSupports driver installation after image creationOAL agnostic to device(s) using IRQOAL must support interrupt chaining on that IRQ

NKCallIntChainTypically used for shared interruptsSupports custom functionality in ISR

Example: High speed serial port driver

SYNNEX

Installable ISRs

ISR implemented in a DLLAll code must be contained in the DLL and cannot have dependent DLLsCannot link implicitly to other DLLs

NOMIPS16CODE=1

Must disable C run time library NOLIBC=1

SYNNEX

Installable ISRs - APIs

LoadIntChainHandlerLoads DLL into kernelRegisters for particular IRQIndicates handler function within DLL

FreeIntChainHandlerUnload interrupt handler

KernelLibIoControlIST interface to ISR

SYNNEX

Generic Installable ISR (GIISR)

Suitable for many devicesProvided by MicrosoftReads register to determine interrupt statusConfigurable

Register/Port addressRegister/Port sizeMemory vs. IOMask

Loading Stream Drivers

SYNNEX

SYNNEX

Driver loading controlled by registry keysWhen the driver loadsHow the driver loadsParameters passed to the driver

Drivers loaded with call to ActivateDeviceExTakes handle to registry key as parameter

Different loading requirements supportedCan be loaded automatically at boot (Built In)Can be loaded dynamically (Plug and Play)

Driver Loading

SYNNEX

Dll [Required] Specifies the name of the driver DLL

Prefix [Optional]Specifies the file name for the device driver

Order [Optional] Specifies order to load driver

Index [Optional] Specifies the device index (x in COMx:)

IClass [Optional] Specifies GUID(s) for device class(es) for use by PnP notification system

Flags [Optional] Specifies load flags for the driver

Driver Registry Settings

SYNNEX

Driver Registry Settings – Flags Parameter

Loads a driver into user mode0x00000010DEVFLAGS_LOAD_AS_USERPROC

Bus Driver loads the driver only when it has exclusive access to the IRQ.0x00000100DEVFLAGS_IRQ_EXCLUSIVE

Driver is loaded during system phase one.0x00001000DEVFLAGS_BOOTPHASE_1

Driver entry points do not have an XXX Prefix prepended0x00000008DEVFLAGS_NAKEDENTRIES

Driver is not loaded0x00000004DEVFLAGS_NOLOAD

Driver unloads after a call to the XXX_Init entry point0x00000001DEVFLAGS_UNLOAD

DescriptionValueFlag

SYNNEX

Driver Registry Settings – Bus Information

InterfaceTypeSpecifies 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)

BusNumberBus 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 andPlay Bus Driver or configured by the system OEMIoBase

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

IoLenSpecifies the length of each I/O window needed by the device

MemBaseSpecifies 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

MemLenSpecifies the length of each memory mapped window needed by the device

SYNNEX

Driver Registry Settings – Interrupts

IRQSpecifies the physical IRQ used by the device

SYSINTRSpecifies 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.

IsrDllSpecifies a DLL to containing an installable interrupt handler

IsrHandlerSpecifies the ISR handler in the ISR DLL

SYNNEX

Bus Drivers

What is a Bus Driver?Load drivers for the devices on their respective busesProvides Device Manager with enough information to

create bus-relative names and enable device handlesProvides bus level services for the bus

Examples are:USBPCI (PCIBus.dll)PCMCIA (Pcmcia.dll)Bus Enumerator (BusEnum.dll)

SYNNEX

Bus Enumerator

Bus Driver used by Device ManagerStarts top level driver loading process“Bus” consists of registry subkeysLoads drivers listed in subkeysLoads other bus drivers and unmanaged driversCan be re-entered

SYNNEX

Reads registry HKEY_LOCAL_MACHINE\Drivers for “RootKey” value

Usually: "RootKey"="Drivers\\BuiltIn"Calls ActivateDeviceEx on the registry path specified in “RootKey”

Example:

Bus Enumerator (BusEnum) driver loads drivers below it

Device Manager – Loading Drivers at Boot

[HKEY_LOCAL_MACHINE\Drivers\BuiltIn]"Dll"="BusEnum.dll""BusName"="BuiltIn""Flags"=dword:8

SYNNEX

Sample Registry

Example:[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\AmdNorFMD]

"Dll"="amdnord.dll""Prefix"=“DSK""Flags"=dword:00010000"Order"=dword:2

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

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

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

Application Development

SYNNEX

SYNNEX

Application Development Options

LanguagesC, C++, C#, VB and Assembler

FrameworksWIN32MFC, ATL, WTL, STL.NET Compact Framework

SYNNEX

.NET Managed Applications

Supported by the Compact FrameworkLanguages all compile to Intermediate Language format to run on Common Language Runtime (CLR)

C# application developmentVisual Basic .NET application development

SYNNEX

Native Applications

Must be rebuilt for each new CPU or PlatformDeveloper manages system resourcesWIN32 runs without extra support filesCan access all operating system services and APIsMust be rebuilt to run on desktop systemsSupports COM, ActiveX programming

SYNNEX

Managed Applications

Built once for all devicesRuntime engine manages system resourcesRequires runtime support files (.NET CF)Applications access the services exposed by the Compact FrameworkMay Run directly on desktop without rebuilding

~Thank You~

SYNNEX

WinCE MOC Training PartnerBsquare

TechWare

巨匠

WinCE information and training data download

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