Post on 16-Oct-2020
WinCE 6.0 MOCIntroduction
Victor LinField Application EngineerSYNNEX INTERNATIONAL CORP.(02)25063320-2231victorlin@synnex.com.tw
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
System Generation Phase
Complete header and source code
files
Complete system libraries
Module definitions (.def)
System-specific
header files
Linked libraries
Specific .def files
SYSGEN
SYNNEX
System Generation Phase
%__PROJROOT%\CESYSGEN
aaa.Exeaaa.Dll
MAKEFILE
zzzz.libyyy_lib.lib
SYNNEX
System Generation Phase
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
System Generation Phase
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
Build Release Directory Phase
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
Build Release Directory Phase
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
Mapping the IDE to the Command Line
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
Mapping the IDE to the Command Line
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
Mapping the IDE to the Command Line
Targeted Build – SubprojectApplies to all sources subprojects
Includes sources subprojects in BSP
BuildSet wincerel=1&&build
RebuildSet wincerel=1&&build -c
SYNNEX
Mapping the IDE to the Command Line
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
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.
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
CE Development System Directory Structure
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
CE Development System Directory Structure
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
Platform Common Code
OrganizationCommon Code
\WINCE600\PLATFORM\COMMON\SRC\COMMONNo CPU dependenciesCPU independent modules, e.g.
• bootloader framework • kitl• PCI• interrupt framework• timer framework
SYNNEX
Platform Common Code
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
Platform Common Code
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
Platform Common Code
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
Platform Common Code
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
OAL – Common Functions
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
OAL – Common Functions
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
OAL – Common Functions
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
OAL – Common Functions
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
FILES – Config.bib
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
FILES – Config.bib
MEMORY SectionRESERVED Type
Ignored by build toolsDocument use of other memory regions
BootloaderDMA buffersFramebufferEtc
SYNNEX
FILES – Config.bib
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
Win32 CE APIs – COREDLL / WINSOCK / COMMCTRL / COMMDLG
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
Win32 CE APIs – COREDLL / WINSOCK / COMMCTRL / COMMDLG
OALDrivers FSDMGR.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
KERNEL.DLL DEVMGR.DLLGWES.DLL
FILESYS.DLL
Win32 CE APIs – COREDLL / WINSOCK / COMMCTRL / COMMDLG
OALDrivers FSDMGR.DLL
NetworkingDLLs
KCOREDLL.DLL
RAMROM
IRQControlCPU USB SDIO Touch Display
Keyboard OEM PAN WANLAN MAN
SYNNEX
CE 6.0 Architecture
Windows CEApplication Shell
ServicesD.EXE Udevice.EXE Udevice.EXE
UserMode
Driver 1
UserMode
Driver n
Win32 CE APIs – COREDLL / WINSOCK / COMMCTRL / COMMDLG
Service1
Servicen
KERNEL.DLL DEVMGR.DLLGWES.DLL
FILESYS.DLL
OALDrivers FSDMGR.DLL
NetworkingDLLs
KCOREDLL.DLL
OAL Component
SYNNEX
CE 6.0 Architecture
Windows CEApplication Shell
ServicesD.EXE Udevice.EXE Udevice.EXE
UserMode
Driver 1
UserMode
Driver n
Win32 CE APIs – COREDLL / WINSOCK / COMMCTRL / COMMDLG
Service1
Servicen
KERNEL.DLL DEVMGR.DLLGWES.DLL
FILESYS.DLL
OALDrivers FSDMGR.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 Management
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
Device Power Management
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 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 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 and Power Management
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 and Power Management
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
Internationalization
Platform localization optionsLocalization vs. InternationalizationChanging the language of your operating system
SYNNEX
Internationalization
Locale Support ArabicEnglish (U.S.)English (Worldwide)FrenchGermanHebrewIndicJapaneseKoreanSimplified ChineseTraditional ChineseThai
SYNNEX
Internationalization
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
Windows CEApplication Shell
ServicesD.EXE Udevice.EXE Udevice.EXE
UserMode
Driver 1
UserMode
Driver n
Win32 CE APIs – COREDLL / WINSOCK / COMMCTRL / COMMDLG
Service1
Servicen
KERNEL.DLL DEVMRG.DLLGWES.DLL
FILESYS.DLL
OALDrivers FSDMGR.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