HME Architecture HME Architecture HME Services HME Boot Manager HME Services & The Device Model HME Architecture The HME abstracts a handset as a collection of services that are made available to an operating system loader and the operating system. A file system is included to allow the storage of a variety of binary images managed by the active and controlling agent in HME, the HME Boot Manager. The operator and handset manufacturer retain control over boot loading and access to the file system. This is not exposed to the consumer. While so-called hypervisor technologies will employ a persistent kernel to always mediate resource access and utilization for the operating system, the HME only performs initialization of the platform. On operating system boot, the HME turns complete control of the platform over to the operating system, providing it with a set of fully initialized device drivers. Figure 2 HME Architecture ^ Return to top HME Services HME Services provide an abstraction between the handset platform and the mobile operating. Depending on how they are used by the operating system, HME Services are described as either Runtime Services or Boot Services. Boot Services Boot services provide interfaces for devices and system functionality that will be used during operating system boot. Runtime Services Runtime services make available devices and functionality needed by the running operating system. HME runtime services are used by operating system kernel level code in device drivers and other kernel elements. The HME provides a set of core services, but many system and device specific services are implemented in a port of the HME on a system. These services can be dynamically loaded as needed. All runtime services are non-blocking and can be used with interrupts disabled if desired. ^ Return to top HME Boot Manager The HME contains a boot manager that loads and unloads HME applications, or HME device drivers. Figure 3 HME Boot Life Cycle The boot manager implements the device life-cycle shown in Figure 3. by loading HME Images. Images are described using a subset of the PE32 image format. HME images are categorized into 3 types: HME Applications, HME Operating System Loaders and HME Device Drivers. In essence the Boot Manager is a configurable policy engine, determining system behavior depending on circumstance and status of the system at boot time. Depending on the selected policy the Boot Manager can determine what device drivers to load and even which operating system to load. HME Applications An HME application is a routine that is loaded, run and then unloaded when it exits. HME Applications are utilized as diagnostics and utility programs at boot time. HME OS Loaders OS loaders are a type of application that takes control of the system from the HME. An OS loader behaves like any other HME application. If the OS loader experiences a problem and cannot load the operating system correctly it may return control to the Boot Service. However, the OS loader is normally responsible for taking over control and continued operation of the system and shutting down the HME Boot Manager. HME Drivers HME Drivers are the vehicle for platform specific services to be exposed to the boot loader or the operating system. There are two types of HME Drivers: Boot Drivers and Runtime Drivers. The difference being that a Runtime Driver is available once the operating system boot loader has taken control of the system and the Boot Manager has exited. ^ Return to top HME Services & The Device Model The HME defines a broad set of Runtime Services exposed to the operating system and its boot loader. Service Type Description HME System Variable addressing, System Reset, Pointer Conversion IRQ Basic interrupt request line service and masking DMA Access and managing a DMA Channel Audio Player abstraction and audio system manipulation USB USB Bus & Device abstraction PCI PCI Bus & Device abstraction Keypad Keypad access Power Power Management functions Serial Serial Port access Display Text LCD & pixel manipulation Time System Time & Alarm Camera Exposes system camera support Figure 4 Core Runtime Services In addition to the Runtime Services listed in Figure 4, a Device Driver may implement Protocols. In essence Protocols are interfaces that a Device Driver may also support. Figure 5 describes some HME protocols. Protocol Description Load Image Provides information on an image Device Path Provides location of a device Driver Binding Start/Stop/Discovery of Controller Driver Config Driver/Controller configuration options Bus Override Override mechanism for choosing the best driver given controller and bus Driver Override Override mechanism for choosing best driver given controller Name Human readable names for driver & controllers Simple Input Console style text input Simple Output Console style text display UGA Draw Graphical output Pointer Touch screen interface Serial I/O Serial character transfer Load File File input File System Disk volume open File Handle Access to file systems Disk I/O File based Block I/O Interface Block I/O Physical Block I/O Unicode Unicode comparison ops PCI Root Bridge I/O PCI Memory, I/O, Config & DMA access to PCI root bridge PCI IO PCI Memory, I/O, Config, DMA access to PCI controller USB HC USB Host Controller access USB I/O USB Controller access Simple Net Packet based transfer PXE BC Network booting BIS Boot image validation Decompress Image decompression Device I/O Basic device I/O Figure 5 HME Protocols The HME device driver model describes system devices as a collection of I/O busses with children. The children can be either devices or addition I/O buses. The leaf nodes in this tree structure, devices, describe a peripheral that performs some form of I/O (e.g. keypads, displays, storage, network etc.). The HME Boot Manager is responsible for determining which peripherals are used and when. To facilitate this, the following distinctions are made amongst device drivers: Host Bus Controllers are bus drivers that manage the key bus components on the system. These are made available at system start up to the HME Boot Manager. Bus Drivers are responsible for creating new Device driver instances for child devices that a bus driver discovers on its bus. Bus drivers are capable of handling hot-plug addition of devices. Device Drivers are not allowed to create any new devices but will install protocol handlers to support the peripheral that the driver will manage. Device drivers need not manage an actual physical piece of hardware; such device drivers that do not are called Virtual Device Drivers. ^ Return to top | Return to Overview