Wince6.0 Developer Guide

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

SYNNEX

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

SYNNEX

Toolkit SYNNEX

Runtime Image of the CE 6.0 Operating System

OS Layer

OEM Layer (BSP)

Windows CE Application

Custom Application

Internet Client Services

Application Services Kernel OEM Adaptation Layer (OAL)

NK.BIN

Application Layer

Drivers

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

Build Demo Tool (blddemo.bat)

CE 6.0 Build Steps Pre-Sysgen Build

0

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 settings

1 2 2

Post-Sysgen Build – BUILD Builds Source Code for the BSP and subprojects

3 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

Build Demo Tool (blddemo.bat)

System Generation Phase

Pre-Sysgen Build

0

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 and source code files

Systemspecific header files

Complete system libraries

Linked libraries

Module definitions (.def)

SYSGEN

Specific .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 [!] [[OR | || | AND | &&] [!]Component] // @CESYSGEN ELSE // @CESYSGEN ELSE IF [!] [[OR | || | AND | &&] [!]Component] // @CESYSGEN ELSEIF [!] [[OR | || | AND | &&] [!]Component] // @CESYSGEN ENDIF

SYNNEX

System Generation Phase Filtering

Input files from %_COMMONPUBROOT% Sdk\Inc\*.* Oak\Inc\*.* Ddk\Inc\*.* Oak\Files\Common\*.*

Output directory in %_PROJECTROOT% Cesysgen\Sdk\Inc Cesysgen\Oak\Inc Cesysgen\Ddk\Inc Cesysgen\Oak\Files SYNNEX

Build Demo Tool (blddemo.bat)

Post-Sysgen Build Phase

Pre-Sysgen Build

0

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 Demo Tool (blddemo.bat)

Build Release Directory Phase Pre-Sysgen Build

0

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

Build Demo Tool (blddemo.bat)

Make Run-Time Image Phase

Pre-Sysgen Build

0

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 in BSP

Change Device Memory Layout

Add New Item from Catalog

Change code in subproject

Sysgen

No

No

Yes

No

Post-Sysgen Build

Yes

Maybe

Yes

Yes

Build Release Dir

Maybe

Yes

Yes

Maybe

Yes

Yes

Yes

Yes

Make Run-time Image

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

DIRs

Nmake.exe Sources

\MyProj DIRS \Proj1 Sources Makefile

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 Project Folder

MAKEFILE.DEF %_MAKEENVROOT%

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 blddemo -q

y Rebuild 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

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 RAM

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

Name Start Size(bytes) Type Name Startaddress address Size(bytes) Type --------------------------------------------------------------------------------------------NK 8C800000 00800000 RAMIMAGE NK 8C800000 00800000 RAMIMAGE RAM 8C050000 007B0000 RAM RAM 8C050000 007B0000 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 Path Memory ;Name Path MemoryType Type --------------------------------------------------------------------------------------------------------Tahoma.ttf $(_FLATRELEASEDIR)\Tahoma.ttf NK SHU Tahoma.ttf $(_FLATRELEASEDIR)\Tahoma.ttf NK 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 (OAL)

Run-time Libraries

Custom SDK Platform Manager Run-time Files

SDK Documentation

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

Windows CE Application

Shell

ServicesD.EXE

Udevice.EXE

Udevice.EXE

Service 1

User Mode Driver 1

User Mode Driver n

Service 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 KERNEL.DLL OAL

DEVMGR.DLL

FILESYS.DLL GWES.DLL FSDMGR.DLL

Drivers

Networking DLLs

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 KERNEL.DLL OAL

DEVMRG.DLL Drivers

FILESYS.DLL GWES.DLL FSDMGR.DLL

Networking DLLs

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 KERNEL.DLL

DEVMGR.DLL

GWES.DLL FSDMGR.DLL

Drivers

OAL RAM ROM

FILESYS.DLL

Networking DLLs

KCOREDLL.DLL IRQ

CPU Control USB

SDIO

Touch Display Keyboard

OEM

PAN WAN 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

Windows CE Application

Shell

ServicesD.EXE

Udevice.EXE

Udevice.EXE

Service 1

User Mode Driver 1

User Mode Driver n

Service n

Win32 CE APIs – COREDLL / WINSOCK / COMMCTRL / COMMDLG KERNEL.DLL OAL

DEVMGR.DLL

FILESYS.DLL GWES.DLL

Drivers

FSDMGR.DLL

Networking DLLs

KCOREDLL.DLL

OAL Component

SYNNEX

CE 6.0 Architecture

Windows CE Application

Shell

ServicesD.EXE

Udevice.EXE

Udevice.EXE

Service 1

User Mode Driver 1

User Mode Driver n

Service n

Win32 CE APIs – COREDLL / WINSOCK / COMMCTRL / COMMDLG KERNEL.DLL

DEVMGR.DLL

OAL

Microsoft

FILESYS.DLL GWES.DLL FSDMGR.DLL

Drivers

Networking DLLs

KCOREDLL.DLL

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

512 MB

64 MB RAM

Uncached

32 MB Flash

A000 0000

32 MB Flash

64 MB RAM

8000 0000

04000000

Address Translation

User Space

2 GB User

64 MB Flash 00000000

512 MB

82000000

Cached

32 MB Flash

0000 0000

SYNNEX

Virtual Memory Map

2 GB kernel space

Kernel Filesystem GWES Drivers

..

..

User DLLs

Process code

..

2 GB VM per process

..

Memory mapped files

32 K processes SYNNEX

Kernel Memory Space

CPU Specific VM Kernel VM (if supported by CPU) 256 MB

Kernel Space 2 Gigabytes Fixed mapping independent of user space

Kernel VM 256 MB Object Store (128 MB) Kernel XIP DLLs (128 MB) 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 Gigabytes Each process has its own mapping

Shared User DLLs 512 MB

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 Heap

Primary Thread Stack Additional Thread Stack

Each Process has at least one heap Each Thread has a stack

Additional Thread 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 Thread 1

Thread 1 P=0 Thread 2 P=252

Thread 2

Thread 3 P=252

Thread 2 Thread 3

t1

t2

t3

Thread 3

t4

t5

t7

t6

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 0 - 96

Component 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 Restoration Inversion

High Priority

Thread 1 Thread 3

Thread 1

Preempt

Medium Priority

Thread 2

Thread 2

Preempt

Low Priority

Thread 3

Resource Owner:

Thread 3

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

1

Device

Event

Interrupt ID

Interrupt

KERNEL.DLL Exception Handler

Interrupt Service Thread (IST)

3

4

2 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 1

ISR 2

ISR 3

Shared Interrupt Line

Bar Code Scanner

Power Switch

WiFi 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

Notification Message Queue

Application Application APIs Power Manager APIs Driver APIs

Power Manager (pm.dll)

Drivers

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 D1 D2 D3 D4

Full on Low on Standby Sleep Off

Full functionality Full functionality, reduced performance Partial power, auto wakeup on request Partial power, can wake up 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 UserIdle SystemIdle Suspend

User actively using device User passively using the device User not using the device 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 UserIdle SystemIdle Suspend

D0 D1 D2 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 DeviceIoControl

DevicePowerNotify 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 DLL

French DLL

English DLL

Spanish 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 Interface (DDI)

Device Driver 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 Interface

Stream Interface

Stream Interface (DDI) NDIS Wrapper

NDIS Miniport

MDD Monolithic Stream Interface Driver

NDIS Wrapper

NDIS 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

Window CE Kernel

OAL

Device Manager

Stream Interface Driver (Loaded at Boot up)

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 xxx_Init xxx_DeInit xxx_Open xxx_Close xxx_IOControl xxx_Read xxx_Write xxx_Seek xxx_PowerOn xxx_PowerOff

Called When The driver is initialized (loaded) The driver is de-initialized (unloaded) Application calls CreateFile Application calls CloseHandle Application calls DeviceIoControl Application calls ReadFile Application calls WriteFile Application calls SetFilePointer OS resumes from suspend state OS enters suspend state SYNNEX

User Mode Driver Framework SYNNEX

User Memory Space

User and Kernel Mode Drivers

Kernel Memory Space

Marshalling

Windows CE Application

Shell

ServicesD.EXE

Udevice.EXE

Udevice.EXE

Service 1

User Mode Driver 1

User Mode Driver n

Service n

Win32 CE APIs – COREDLL / WINSOCK / COMMCTRL / COMMDLG

KERNEL.DLL OAL

DEVMRG.DLL Drivers

FILESYS.DLL GWES.DLL FSDMGR.DLL

Networking DLLs

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

User Mode

1

XXX_Init(…)

User Mode Driver

ActivateDeviceEx HANDLE 10 Returned

udevice.exe CreateProcess(,,Volume Name)

XXX_Init forwarded to UM Driver Host

Kernel Mode

6

Device Manager 1

10

3

2 5

8

9

4

7

9

Device Context

Reflector Service

HANDLE 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

DEVFLAGS_UNLOAD

0x00000001

Driver unloads after a call to the XXX_Init entry point

DEVFLAGS_NOLOAD

0x00000004

Driver is not loaded

DEVFLAGS_NAKEDENTRIES

0x00000008

Driver entry points do not have an XXX Prefix prepended

DEVFLAGS_BOOTPHASE_1

0x00001000

Driver is loaded during system phase one.

DEVFLAGS_IRQ_EXCLUSIVE

0x00000100

Bus Driver loads the driver only when 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