• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
WinCE
 

WinCE

on

  • 3,447 views

 

Statistics

Views

Total Views
3,447
Views on SlideShare
3,391
Embed Views
56

Actions

Likes
3
Downloads
0
Comments
0

2 Embeds 56

http://hedieuhanhwince.blogspot.com 42
http://www.slideshare.net 14

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

WinCE WinCE Presentation Transcript

  • Windows CE Driver Architecture Jay Loney Program Manager Windows CE Drivers JayLoney @ Microsoft.com
  • Agenda
    • Driver Architecture
      • Device, Regenum, Loading Model, Power management
      • Windows CE versus WDM
    • Memory and CEDDK
    • Basic Interrupt Architecture
    • Windows CE .NET’s Installable ISRs (IISR)
    • Bus Drivers
  • Windows CE Architecture OEM Hardware Embedded Shell Applications WIN32 APIs COREDLL, WINSOCK, OLE, COMMCTRL, COMMDLG, WININET, TAPI Windows CE Shell Services Remote Connectivity Kernel Library IrDA GWES Device Manager File Manager TCP/IP OAL Bootloader Drivers Device drivers File drivers Microsoft OEM ISV Network drivers
  • What Is A Driver In Windows CE
    • Simply a DLL with a well defined set of entry points
    • Hosted by a Device Manager process space (sometimes GWES)
    • Interface to apps via CreateFile (Streams – optional)
    • Typically handle interrupts via dedicated thread (IST)
    • Synchronization between apps and ISTs via criticalsections and mutexes
    • Driver can have multiple simultaneous threads active
  • Driver Architecture
  • Types Of Drivers
  • Native Versus Stream Loading Mechanism
    • Generally Native device drivers are loaded in the GWES process space by registry keys
    • Bus drivers loaded by Device.exe using registry
    • Installable, Stream, and Hybrid drivers in Device.exe by either bus driver or Registry Enumerator
  • Device Manager
    • User-level process that runs continously
    • Separate application that interacts with the kernel, the registry and stream interface driver DLLs
    • Provides ActivateDevice and DeactivateDevice APIs
  • Device Manager
    • Contains the IO Resource Manager
    • Loads the registry enumerator (RegEnum.dll) which in turn loads the drivers based on the registry
    • Provides power notification callbacks
      • Tracks all loaded devices and issues device interface notifications for insertion and removal
  • Device Manager
    • Device Driver Loading Process
    DEVICE.EXE Kernel I/O Resource Manager (part of Device.exe) REGENUM.DLL PCIBUS.DLL loads loads loads DEVICE.EXE I/O Resource Manager (part of Device.exe) REGENUM.DLL PCIBUS.DLL
  • Registry Enumerator
    • Registry Enumerator is RegEnum.dll
    • Device.exe loads the Registry Enumerator from HKEY_LOCAL_MACHINEDriversRootKey
    • Registry Enumerator scans the registry for more drivers to load
    • Registry Enumerator is re-entrant and supports hierarchical usage
    • When it gets unloaded, it also unloads anything it directly loaded
    • Registry Enumerator examines the first level of keys just below the key passed to it, according to Order
    • Registry Enumerator invokes ActivateDeviceEx on each subkey it finds
  • Driver Registry Keys
    • Registry Enumerator examines the SubKeys as defined below
      • Order – Smallest value gets loaded first
      • dll – Which DLL to load
      • Prefix – Three letter stream interface name, used only with drivers that expose a stream interface
      • Index – Identifier when multiple instances are present, between 0 and 9, inclusively
      • Flags – Modifies the default behavior of the enumerator
  • ActivateDeviceEx
    • Exposed by Device.exe
    • Bus Drivers call ActivateDeviceEx when they load device drivers
    • ActivateDeviceEx also locks the stream interface driver into working RAM
    • This prevents code pages from being discarded
    • Registry Enumerator calls ActivateDeviceEx on each built-in subkey it finds
    • ActivateDeviceEx loads driver and updates registry
  • Driver Loading
    • Registry Enumerator is key to loading drivers
      • Device Manager loads Registry Enumerator
      • Scans registry and loads drivers
      • publiccommonoakdrivers egenum
    • Driver loading process
      • RegEnum scans registry, loads bus drivers
      • Bus driver scans the bus and locates devices
      • Searches the registry for device information
      • Finds a match and loads appropriate driver
        • Action for not finding a match differs with each bus
      • Sends notification that interface is available
  • Registry Key Example
    • [HKEY_LOCAL_MACHINEDrivers]
    • "RootKey"="DriversuiltIn”
    • [HKEY_LOCAL_MACHINEDriversBuiltIn]
    • "Dll"="RegEnum.dll“
    • [HKEY_LOCAL_MACHINEDriversCSPSerial]
    • "Dll"="Com16550.Dll"
    • "Order"=dword:0
    • "Irq"=dword:3
    • "MemBase"=dword:FFBFC000
    • "MemLen"=dword:8
    • "SysIntr"=dword:13
    • "Prefix"="COM"
    • "DeviceArrayIndex"=dword:0
    • "Priority"=dword:0
  • Interface Classes
    • Drivers are characterized by their interface
      • Each IClass has a GUID and a Name
      • GUID describes the generic device interface
      • Name identifies the instance of an interface
        • COM1:, DSK1: and so on
    • Exposing a driver’s interface
      • IClass subkey in the registry
      • Drivers publish interface – AdvertiseInterface
    • Apps query interface – RequestDeviceNotifications
    • Pre-defined GUIDs for existing interfaces
      • A32942B7-920C-486b-B0E6-92A702A99B35
  • I/O Resource Manager
    • IORM is an intrinsic part of Device Manager
    • Tracks available I/O resources ( IRQ and I/O base address )
    • OEM pre-allocates resources for built-in devices
    • Bus drivers request resources when loading a client driver on their bus
      • ResourceRequest
      • ResourceRelease
      • ResourceCreateList
    • IORM fails ResourceRequest when there is a conflict
  • Registry Helper Routines
    • Reads resource configuration from the registry
      • OpenDeviceKey
      • DDKReg_GetIsrInfo
      • DDKReg_GetWindowInfo
      • DDKReg_GetPciInfo
      • APIs in COREDLL
      • Prototyped in < devload.h > and < ddkreg.h >
    • Samples in publiccommonoakdrivers
      • wavedevpddes1371wavepdd.cpp -> GetRegistryConfig
  • Contrast: Windows XP WDM Loading Model
    • Drivers are loaded in the kernel address space as a .sys file
    • In Windows XP, everything is PNP
      • Boot time: BIOS tells you ACPI table which tells you which drivers to load, including busses
      • Windows CE walks through the registry
      • Run time: PNP manager is informed of added devices by the bus drivers. PNP manager asks bus driver who it is, PNP Man. loads the driver based on inf database. CE’s bus drivers detect PNP devices, scan registry for driver and request driver loading from Device Manager
    • Driver entry is called DriverEntry
      • In CE it’s xxx_Init
    • Then the other driver entry points are specified for read/write/IOCTL/power
      • In CE it’s the rest of the streams interface
    • Drivers are re-entrant
    • PDO device objects (handle), provided by bus driver, to handle multiple instances
  • Power Management
    • Power Manager
      • Flexible infrastructure for system-level and peripheral-level power management
      • Lets devices intelligently manage their own power
      • Acts as a mediator between the devices and system/applications
      • Enables OEMs to modify the code surrounding calls to PowerOffSystem()
  • Power Management
    • System-level power states
    • Device (peripheral) level power states
    Suspend User Idle System Idle On D2 Standby D4 Off D1 Low Performance D3 Sleep D0 Fully Powered
  • Power Manager Architecture Drivers Power Manager (pm.dll) PM APIs Application Notification Message Queue Driver APIs Application APIs
  • Contrast: WDM Power Management
    • Similar structure, different implementation
    • Power manager lives in the Kernel (in Windows CE it’s in DeviceMan)
    • S0-S5 system states (CE has OEMIdle and OEMPowerDown)
    • WDM Power manager negotiates with all active drivers whether a system state can be entered
    • WDM Power Manager walks the device tree, tells the drivers that the system is in a certain state. The driver then makes its own decision as to what Device state (D-state) the device should be in
      • (CE has D0-D5, but is extensible)
    • Driver can veto a System state because it is working
    • Battery Critical off has the highest precedent and will override any driver working
  • Physical Memory 64 MB RAM 32 MB Flash Dbg Serial Port 2 GB User 512 MB Uncached 512 MB Cached 64 MB RAM 32 MB Flash 64 MB RAM 32 MB Flash Physical Memory Kernel Virtual Address Reserved 04000000 82000000 80000000 80000000 A0000000 C0000000 0
  • Virtual Address Space Not Used Slot 0 Slot 32 64 KB 32 MB 64 MB 2 GB 3 GB 4 GB Memory mapped files Above 2G-3G Mapped to physical memory Virtual address space Slot 1 Slot 32 NULL pointers 0x80000000 0xA0000000 Accessable via MmMapiIoSpace 512M Cached 512M Non-Cached
  • Memory Management Functions
    • Device drivers are user-mode modules
      • Necessary to map physical memory to virtual memory
    • VirtualAlloc, VirtualFree: reserve, free virtual memory
      • MEM_RESERVE
    • VirtualCopy: Maps a physical memory range to a virtual memory range
      • PAGE_NOCACHE
      • PAGE_PHYSICAL
  • Driver Memory Access – Mapped Pointers
    • MapPtrToProcess
      • Allows you to map a pointer from one address space to another
    • GetCurrentProcess
      • Retrieves a process identifier to be used with the MapPtrToProcess function
    • SetProcPermissions
      • Gives the current process access to other processes’ address spaces
  • Driver Memory Access – Mapped Pointers App Calls DeviceIOControl DM mapped into Slot 0 App is mapped into Slot 0 DM Calls xxx_IoControl DM Sets permissions to App space APP DM Slot 0 APP APP Mapped pointer Driver Calls MapPtrToProcess Driver returns from xxx_IoControl DM Re-Sets permissions to App space App is mapped into Slot 0 APP DM APP Original pointer DM APP
  • Contrast: WDM Basic Memory Management
    • Windows XP drivers are in kernel address space
    • XP Drivers can access all kernel address space
    • Can access the User space of the context from which they’re called
      • In Windows CE, drivers have to map through virtual memory to get to their physical port/memory
    • Driver’s communicate in 2 ways
      • Buffered IO
      • Direct IO (suggested only if packet is bigger then 1 page)
    • MMMapIOSpace maps physical devices into kernel address space
      • Windows CE does this with OEMAddressTable in the OAL
  • CEDDK
    • CE v2.1x and later supports a platform independent I/O scheme
    • Left up to the OEM and driver writer to actually use them
    • CEDDK.DLL
      • BUS Management
      • Memory Management
      • I/O Management
    • CEDDK APIs taken from NTDDK
      • Not documented until V2.12
      • But most available in V2.00
  • CEDDK Abstraction
    • Device drivers use CEDDK
    • Properly written drivers are binary compatible across platforms
      • Source code compatible across CPUs
    Device Manager Device Driver CEDDK.DLL Hardware
  • CEDDK Internals READ_REGISTER_XXXX WRITE_REGISTER_XXXX READ_PORT_XXXX WRITE_PORT_XXXX I/O Access XXXX => UCHAR/USHORT/ULONG MmMapIOSpace – MmUnmapIOSpace HalAllocateCommonBuffer Memory Management HalGetBusDataByOffset() HalGetBusData() HalSetBusDataByOffset() HalSetBusData() HalTranslateBusAddress() HalTranslateSystemAddress() Bus Management Function Examples Coverage
  • Contrast: WDM Advanced Memory Management
    • The CEDDK-like functions aren’t used anymore in WDM
    • Bus drivers are now controlling the DMA for their own busses
    • PNP Manager asks the bus driver what resources the driver needs and arbitrates the resources including DMA channel requests
    • PNP Manager can arbitrate conflicts (“resource rebalancing”)
      • Ex. Device1 can use irq 10 or 11 and gets 10, device2 comes later and can only use 10, PNP Manager will shuffle device1 to 11 and restart him
    • In CE, always use shared interrupts to help avoid this problem. In the example above, you’re stuck
  • Interrupt Architecture
    • Interrupt is just a particular exception
      • Caught by kernel code
      • Dealt with prior to resuming user code
      • But hardware is independent of OS
    • CE uses two stage Interrupt Service model
      • Lightweight code to quiet interrupt
      • Scheduled code to service hardware
    • OS provides API for enabling IRQ signals, prioritization, etc.
    • Hardware specific operations done in OAL and device driver code
  • CE 3.0 Interrupt Handling User Mode HW All None Device Driver IST Processing Set Event EOI Except. Handler ISR Enable App IRQ Masked All IRQ Enabled WFSO WFSO on Event Application Resumes Kernel OAL Higher Priority PSR SYSINTR_ ID
  • Notes On ISRs And ISTs
    • ISTs are plain old user mode code
      • Full CE .NET API and CRT library available
      • CE .NET scheduler controls IST execution based on thread priority
      • Run-time binding to SYSINTR
    • ISRs are called from Exception Handler
      • No OS services available
      • Stack space is limited
      • May be reentrant (OAL choice)
      • Assembly language on MIPS, SHx
  • ISR Observations
    • IRQ priorities CPU architecture dependent
      • PIC hardware handles this on x86
      • OAL arrays IntrPriority, IntrMask on MIPS
    • OAL could add real-time feature allowing IST processing to preempt ISR service
    • Under CE 3.0, all ISR code part of OAL
      • Not particularly expandable
      • IRQs bound to event IDs in OEMInit
      • No Support for PNP, IRQ sharing (PCI bus)
    • CE .NET addresses these limitations with Installable ISR (IISR) chain
  • CE .NET Installable ISRs
    • Preferable Extension to CE 3.0 ISR architecture
    • DLL code, bound at run time
    • Source code can be CPU independent
      • Typically coded in “C”
      • Some restrictions apply
        • No calls to CRT, Windows API, or other DLLs
    • Run-to-completion ISR, or IST dispatch
    • Support for hardware IRQ sharing
      • Distinct SYSINTR ID from same IRQ
  • CE .NET Interrupt Handling IISR Kernel OAL Driver HW Set Event SYSINTR_ ID IRQ Masked IST None Except. Handler ISR Higher Priority IRQs Enabled PSR SYSINTR_xx SYSINTR_NOP IISR 1 NKCallIntChain(IRQ) IISR n SYSINTR_CHAIN IISR 2
  • IISR Control Flow
    • Driver registers IISR DLL with the Kernel with the call to LoadIntChainHandler()
      • Data passed to IISR via KernelLibIoControl()
    • OAL ISR decodes IRQ from hardware, calls kernel NkCallIntChain(dwIRQ) to query IISRs
      • IISRs called in binding order
    • IISR return value indicates status
      • SYSINTR_CHAIN indicates IRQ not recognized
        • OAL ISR translates IRQ to SYSINTR as before
      • SYSINTR_NOP indicates IISR run-to-completion
        • IISR must make IRQ go away!
      • Other values indicate IISR owns interrupt
        • OAL ISR code must set PIC IRQ mask
    • OAL ISR handles PIC EOI, returns ID
  • Interrupt Service Thread
    • Is user-mode thread of device drivers for built-in devices
    • Does the actual processing of the interrupt
    • Creates an event object associated with the logical interrupt by calling CreateEvent function
    • IST remains idle most of the time, awakened when the kernel signals the event object
    • IST usually runs at above-normal priority, boost priority with CeSetThreadPriority function
  • Interrupt Service Thread
    • InterruptInitialize
      • Call InterruptInitialize to link the Event with the Interrupt ID of the ISR
    • WaitForSingleObject
      • Can be used to wait for an event to be signaled
      • This call is usually inside a loop so that when interrupt is processed, the IST gets back to this call waiting for the next interrupt to be handled
    • InterruptDone
      • After the interrupt data is processed, the IST must call the InterruptDone function to instruct the kernel to enable the hardware interrupt related to this thread
  • Typical IST Start struct ISTData // Declare the Strucure to pass to the IST { HANDLE hThread; // IST Handle DWORD sysIntr; // Logical ID HANDLE hEvent; // handle to the event to wait for interrupt volatile BOOL abort; // flag to test to exit the IST }; ISTData g_KeypadISTData; // Create event to link to IST g_KeypadISTData.hEvent = CreateEvent(NULL, FALSE, FALSE, NULL); // Translate IRQ to an logical ID (x86 CEPC) g_KeypadISTData.sysIntr =Mapirq2Sysintr(5); // start the thread g_KeypadISTData.hThread = CreateThread(NULL,0,&KeypadIST, &g_KeypadISTData, 0, NULL);
  • Typical IST Start
    • Set the IST Thread Priority
    • Disconnect any previous events from the associated ISR
    • Connect to the associated ISR
    //Change the threads priority CeSetThreadPriority(g_KeypadISTData.hThread,0); //disconnect any previous event from logical ID InterruptDisable(g_KeypadISTData.sysIntr); // Connect Logical ID with Event InterruptInitialize(g_KeypadISTData.sysIntr, g_KeypadISTData. hEvent,NULL,0);
  • Typical IST Start DWORD KeypadIST(void *dat) { ISTData* pData= (ISTData*)dat; // loop until told to stop While(!pData->abort) { // wait for the interrupt event... WaitForSingleObject(pData->hEvent, INFINITE) if(pData->abort) break; // Handle the interrupt... // Let OS know the interrupt processing is done InterruptDone(pData->sysIntr); } Return 0; }
  • Typical IST Stop
    • Set a flag that will cancel the IST loop
    • Call InterruptDisable to disconnect the triggering event from the logical ID
    • Close the Thread Add Reference for the code
    // set abort flag to true to let thread know // that it should exit g_KeypadISTData.abort =TRUE; //disconnect event from logical ID //this internally sets g_KeypadISTData.sysIntr which in turn //sets g_KeypadISTData.hEvent through the kernel InterruptDisable(g_KeypadISTData.sysIntr); //wait for thread to exit WaitForSingleObject(g_KeypadISTData.hEvent,INFINITE); CloseHandle(g_KeypadISTData.hEvent); CloseHandle(g_KeypadISTData.hThread);
  • Contrast: WDM Interrupts
    • Driver is assigned interrupt by the PNP manager
    • Driver registers with kernel it’s ISR
    • When IRQ fires, IDT table links the IRQ to the ISR
    • ISR routines run in arbitrary thread context because all applications share the kernel space
    • ISR runs immediately
    • Priority by hardware first, then IRQL (levels) 0-31, 3-28 are hardware devices
    • Queue Deferred Procedure Calls to do extended read/write work when IRQL drops to 2, this queue is drained in FIFO order
    • Threads (spell-checker) run when IRQL hits 0
      • DPCs are similar to CE ISTs, however CE ISTs are prioritized
  • Bus Drivers Overview
    • PCMCIA
      • I82365 (ISA)
      • TI-1250 (PCI)
    • USB Host
      • Multiple Host Controllers
        • OHCI and UHCI (PCI)
  • PCMCIA Host
    • PCMCIA bus driver has three main threads
      • Status change thread (card insertion/removal)
      • Interrupt thread (handles card functional interrupt requests)
      • Callback thread (notifies card clients of events)
    • Bus driver supports a subset of Card Serv. messages, delivered as callbacks from the callback thread
    • Interrupts are delivered to client drivers as callbacks
    • Newly inserted cards are scanned for identifying PnP tuples and compared with entries in the registry
    • If no match is found, candidate drivers can run “detect” routines to card-specific mechanisms to ID the card
      • May display a dialog box asking for the name of the DLL
  • USB Host
    • USB Version 1.1 compliant
    • OHCI and UHCI fully supported
    • Support for all transfer types
      • Isoch, bulk, interrupt, control
    • USBD supports multiplexing between multiple HC
    • Client drivers are typically loaded using LoadDriver and use USBD operations to communicate with the HC
    • Client drivers can optionally call ActivateDeviceEx() on themselves to expose a stream interface to apps
    • Detects and identifies newly attached devices
    • Loads drivers as described in the registry
      • May display a dialog box asking for the name of the DLL
  •  
  • Community Resources
    • http://msdn.microsoft.com/embedded/
    • Community Sites
      • http://www.microsoft.com/communities/default.mspx
    • List of Newsgroups
      • http://communities2.microsoft.com/communities/newsgroups/en-us/default.aspx
    • Attend a free chat or webcast
      • http://www.microsoft.com/communities/chats/default.mspx
      • http://www.microsoft.com/seminar/events/webcasts/default.mspx
    • Locate a local user group(s)
      • http://www.microsoft.com/communities/usergroups/default.mspx
    • Non-Microsoft Community Sites
      • http://www.microsoft.com/communities/related/default.mspx
  •