Microsoft Windows Embedded CE 6.0 Exam Preparation Kit

Platform Builder includes a wizard that facilitates cloning a reference BSP. This wizard copies the entire source code of the selected reference BSP to a new folder structure so that you can customize the BSP for the new hardware without affecting the reference BSP or other BSPs in the %_WINCEROOT% folder hierarchy. Figure 5-2 illustrates how to start the BSP Cloning Wizard in Microsoft Visual Studio 2005 with Platform Builder for Windows Embedded CE 6.0.

Figure 5-2 Cloning a BSP in Visual Studio 2005

BSP Folder Structure

To increase code reusability, PQOAL-based BSPs feature a common architecture and corresponding folder structure that is consistent across processor families. Due to this common architecture, large portions of the source code can be reused regardless of hardware-specific BSP requirements. Figure 5-3 shows the typical BSP folder structure and Table 5-1 summarizes the most important BSP folders.

Figure 5-3 Folder structure of a typical BSP

Table 5-1 Important BSP folders

Platform-Specific Source Code

The most important platform-specific source code that you must adapt as part of your BSP is for the boot loader, the OAL, and the device drivers. You can find the corresponding source code underneath the Src folder in the following subdirectories:

■ Src\Boot loader Contains the boot loader code. However, if the boot loader relies on BLCOMMON and related libraries, then only the basic hardware- specific part of the boot loader is located in this directory. The reusable boot loader code is available in the Public folder (%_WINCEROOT%\Public \Common\Oak\Drivers\Ethdbg) and linked as libraries to the BSP part. Chapter 4, "Debugging and Testing the System," introduces the static libraries that facilitate boot loader development.

■ Src\Oal Contains the bare minimal amount of code that is specific to the hardware platform. The majority of the OAL code is located in %_WINCEROOT%\Platform\Common, divided into hardware-independent, processor-family-related, chip-set-specific and platform-specific groups. These code groups provide most of the OAL functionality and are linked to the platform-specific parts as libraries.

■ Src\Common and Src\Drivers Contains the driver source code, organized in different categories to facilitate maintenance and portability. These categories are typically processor-specific and platform-specific. The processor-specific component is located in the Src\Common directory and requires no modifications when adapted to new hardware based on the same processor family.

Several aspects have to be considered when adapting a boot loader for a new platform, including:

■ Changes in the processor architecture.

■ Location of the boot loader code on the target device.

■ Memory architecture of the platform.

■ Tasks to perform during the boot process.

■ Supported transports for downloading the run-time image.

■ Additional features to be supported.

Memory Mappings

The first important adaptation task revolves around the definition of memory mappings for the boot loader. The standard BSPs included in Windows Embedded CE define the memory configuration in a .bib file, located in a boot loader subdirectory, such as %_WINCEROOT%\Platform\Arubaboard\Src\Boot loader\Eboot\Eboot.bib. The following listing shows an example of an Eboot.bib file, which you can customize to meet your specific requirements.

MEMORY

; Name  Start  Size   Type

; ------- -------- -------- ----

; Reserve some RAM before Eboot.

; This memory will be used later.

 DRV_GLB A0008000 00001000 RESERVED ; Driver globals; 4 KB is sufficient.

 EBOOT  A0030000 00020000 RAMIMAGE ; Set aside 128 KB for loader; finalize later.

 RAM   A0050000 00010000 RAM ; Free RAM; finalize later.

CONFIG

 COMPRESSION=OFF

 PROFILE=OFF

 KERNELFIXUPS=ON

 ; These configuration options cause the .nb0 file to be created.

 ; An .nb0 file may be directly written to flash memory and then

 ; booted. Because the loader is linked to execute from RAM,

 ; the following configuration options

 ; must match the RAMIMAGE section.

 ROMSTART=A0030000

 ROMWIDTH=32

 ROMSIZE=20000

MODULES

; Name    Path                     Memory Type

; ----------- --------------------------------------------- -----------

  nk.exe   $(_TARGETPLATROOT)\target\$(_TGTCPU)\$(WINCEDEBUG)\EBOOT.exe EBOOT

Driver Globals

Among other things you can use the Eboot.bib file to reserve a memory section for the boot loader to pass information to the operating system during the startup process. This information might reflect the current state of initialized hardware, network communication capabilities if the boot loader supports Ethernet downloads, user and system flags for the operating system, such as to enable Kernel Independent Transport Layer (KITL), and so on. To enable this communication, the boot loader and operating system must share a common region of physical memory, which is referred to as driver globals (DRV_GLB). The above Eboot.bib listing includes a DRV_GLB mapping. The data that the boot loader passes to the operating system in the DRV_GLB region must adhere to a BOOT_ARGS structure that you can define according to your specific requirements.

The following procedure illustrates how to pass Ethernet and IP configuration information from the boot loader to the operating system through a DRV_GLB region. To do this, create a header file in the %_WINCEROOT%\Platform\<BSP Name>\Src\Inc folder, such as Drv_glob.h, with the following content:

#include 

// Debug Ethernet parameters.

typedef struct _ETH_HARDWARE_SETTINGS {

 EDBG_ADAPTER Adapter; // The NIC to communicate with Platform Builder.

 UCHAR ucEdbgAdapterType; // Type of debug Ethernet adapter.

 UCHAR ucEdbgIRQ; // IRQ line to use for debug Ethernet adapter.

 DWORD dwEdbgBaseAddr; // Base I/O address for debug Ethernet adapter.

 DWORD dwEdbgDebugZone; // EDBG debug zones to be enabled.

 // Base for creating a device name.

 // This will be combined with the EDBG MAC address

 // to generate a unique device name to identify

 // the device to Platform Builder.

 char szPlatformStri ng[EDBG_MAX_DEV_NAMELEN];

 UCHAR ucCpuId; // Type of CPU.

} ETH_HARDWARE_SETTINGS, *PETH_HARDWARE_SETTINGS;

// BootArgs - Parameters passed from the boot loader to the OS.

#define BOOTARG_SIG 0x544F4F42 // "BOOT"

typedef struct BOOT_ARGS {

 DWORD dwSig;

 DWORD dwLen; // Total length of BootArgs struct.

 UCHAR ucLoaderFlags; // Flags set by boot loader.

 UCHAR ucEshellFlags; // Flags from Eshell.

 DWORD dwEdbgDebugZone; // Which debug messages are enabled?

 // The following addresses are only valid if LDRFL_JUMPIMG is set and

 // the corresponding bit in ucEshellFlags is set (configured by Eshell, bit

 // definitions in Ethdbg.h).

 EDBG_ADDR EshellHostAddr;  // IP/Ethernet addr and UDP port of host

               // running Eshell.

 EDBG_ADDR DbgHostAddr;    // IP/Ethernet address and UDP port of host

                // receiving debug messages.

 EDBG_ADDR CeshHostAddr;   // IP/Ethernet addr and UDP port of host

                // running Ethernet text shell.

 EDBG_ADDR KdbgHostAddr;   // IP/Ethernet addr and UDP port of host

               // running kernel debugger.

 ETH_HARDWARE_SETTINGS Edbg; // The debug Ethernet controller.

} BOOT_ARGS, *PBOOT_ARGS;

// Definitions for flags set by the boot loader.

#define LDRFL_USE_EDBG 0x0001 // Set to attempt to use debug Ethernet.

// The following two flags are only looked at if LDRFL_USE_EDBG is set.

#define LDRFL_ADDR_VALID 0x0002 // Set if EdbgAddr member is valid.

#define LDRFL_JUMPIMG  0x0004 // If set, do not communicate with Eshell

                // to get configuration information,

                // use ucEshellFlags member instead.

typedef struct _DRIVER_GLOBALS {

 //

 // TODO: Later, fill in this area with shared information between

 // drivers and the OS.

 //

 BOOT_ARGS bootargs;

} DRIVER_GLOBALS, *PDRIVER_GLOBALS;

StartUp Entry Point and Main Function

The StartUp entry point of the boot loader must be located in linear memory at the address where the CPU begins fetching code for execution because this routine carries out the initialization of the hardware. If the adaptation is based on a reference BSP for the same processor chipset, then most of the CPU-related and memory controller-related code can remain unchanged. On the other hand, if the CPU architecture is different, you must adapt the startup routine to perform the following tasks:

1. Put the CPU in the right mode.

2. Disable all interrupts.

3. Initialize the memory controller.

4. Setup caches, Translation Lookaside Buffers (TLBs), and Memory Management Unit (MMU).

5. Copy the boot loader from flash memory into RAM for faster execution.

6. Jump to the C code in the main function.

The StartUp routine eventually calls the main function of the boot loader, and if the boot loader is based on BLCOMMON, then this function in turn calls BootLoaderMain, which initializes the download transport by calling OEM platform functions. The advantage of using the standard libraries provided by Microsoft is that the modifications required to adapt a BSP to a new hardware platform are componentized, isolated, and minimized.

Serial Debug Output

The next step in the boot loader adaptation is the initialization of the serial debug output. This is an important part of the boot process because it enables the user to interact with the boot loader and the developer to analyze debug messages, as discussed in Chapter 4, "Debugging and Testing the System."

Table 5-2 lists the OEM platform functions required to support serial debug output in the boot loader.

Table 5-2 Serial debug output functions

Platform Initialization

Once the CPU and the debug serial output are initialized, you can turn your attention to the remaining hardware initialization tasks. The OEMPlatformInit routine performs these remaining tasks, including:

■ Initializing the real-time clock.

■ Setting up external memory, particularly flash memory.

■ Initializing the network controller.

Downloading via Ethernet

If the hardware platform includes a network controller, then the boot loader can download the run-time image over Ethernet. Table 5-3 lists the functions that you must implement to support Ethernet-based communication.

Table 5-3 Ethernet support functions

The Ethernet support functions use callbacks into network controller-specific routines. This means that you must implement additional routines and set up appropriate function pointers in the OEMPlatformInit function if you want to support a different network controller, as demonstrated in the following sample code:

cAdaptType=pBootArgs->ucEdbgAdapterType;

// Set up EDBG driver callbacks based on

// Ethernet controller type.

switch (cAdaptType) {

case EDBG_ADAPTER_NE2000:

 pfnEDbgInit     = NE2000Init;

 pfnEDbgInitDMABuffer = NULL;

 pfnEDbgGetFrame   = NE2000GetFrame;

 pfnEDbgSendFrame   = NE2000SendFrame;

 break;

case EDBG_ADAPTER_DP83815:

 pfnEDbgInit     = DP83815Init;

 pfnEDbgInitDMABuffer = DP83815InitDMABuffer;

 pfnEDbgGetFrame   = DP83815GetFrame;

 ...

}

Flash Memory Support

Having implemented network communication capabilities, you also must enable the boot loader to download run-time image onto the new hardware platform and pass control to it. Alternately, you can save the run-time image to flash memory. Table 5-4 lists the download and flash memory support functions that you must implement for this purpose if the reference BSP's boot loader does not already support these features.

Table 5-4 Functions for supporting download and flash memory

User Interaction

Boot loaders can support user interaction based on a menu that provides the user with different options to start the platform, which can be helpful during the development process and later on for maintenance and software updates. Figure 5-4 shows a standard boot loader menu. For sample source code, check out the Menu.c file located in the Src\Bootloader\Eboot directory of a reference BSP or in the %_WINCEROOT%\Platform\Common\Src\Common\Boot\Blmenu folder.

Figure 5-4 An example of a boot loader menu

Additional Features

Beyond the core functionality, you can also add convenience features, such as download progress indication, support for downloading multiple .bin files during the same download session (multi-bin image notification), or downloading only trusted images. Additionally, you can implement support for downloading run-time images directly from Platform Builder. To accomplish this task, the boot loader must prepare a BOOTME packet with details about the target device and send it over the underlying transport. If the transport is Ethernet then this packet is broadcasted over the network. The libraries provided by Microsoft support these features, and you can customize them to suit your needs.

A significant portion of the BSP adaptation revolves around the platform-specific part of the OAL. If the new platform uses a CPU that is not currently supported, then the OAL adaptation requires you to modify most of the OAL code to support the new processor architecture. On the other hand, if the new hardware is very similar to the reference BSP's platform, you might be able to reuse most of the existing code base.

OEM Address Table

The kernel performs specialized tasks, such as initializing virtual memory, and cannot rely on a boot loader for this because the kernel must be entirely self-contained. Otherwise, the operating system would depend on the presence of a boot loader and it would not be possible to bootstrap the run-time image directly. Yet, to establish virtual-to-physical address mappings through the Memory Management Unit (MMU), the kernel must know the memory layout of the underlying hardware platform. To obtain this information, the kernel uses an important table called OEMAddressTable (or g_oalAddressTable) that defines static virtual memory regions. The OAL includes a declaration of OEMAddressTable as a read-only section and one of the first actions taken by the kernel is to read this section, set up corresponding virtual memory mapping tables, and then transition to the virtual address where the kernel can execute code. The kernel can determine the physical address of the OEMAddressTable in linear memory based on the address information available in the run-time image.

You must indicate any differences in the memory configuration of a new hardware platform by modifying the OEMAddressTable. The following sample code illustrates how to declare the OEMAddressTable section.

;--------------------------------------------------------------

public _OEMAddressTable

 _OEMAddressTable:

 ; OEMAddressTable defines the mapping between Physical and Virtual Address

 ; o MUST be in a READONLY Section

 ; o First Entry MUST be RAM, mapping from 0x80000000 -> 0x00000000

 ; o each entry is of the format ( VA, PA, cbSize )

 ; o cbSize must be multiple of 4M

 ; o last entry must be (0, 0, 0)

 ; o must have at least one non-zero entry

 ; RAM 0x80000000 -> 0x00000000, size 64M

 dd 80000000h, 0, 04000000h

 ; FLASH and other memory, if any

 ; dd FlashVA, FlashPA, FlashSize

 ; Last entry, all zeros

 dd 0 0 0

StartUp Entry Point

Similar to the boot loader, the OAL contains a StartUp entry point to which the boot loader or system can jump in order to start kernel execution and initialize the system. For example, the assembly code for putting the processor in the correct state is usually the same as the code used in the boot loader. In fact, code sharing between the boot loader and the OAL is a common practice to minimize code duplication in the BSP. Yet not all code runs twice. For example, on hardware platforms that start from a boot loader, StartUp directly jumps to the KernelStart function, as the boot loader has already performed the intialization groundwork.

The KernelStart function initializes the memory-mapping tables as discussed in the previous section and loads the kernel library to run Microsoft kernel code. The Microsoft kernel code now calls the OEMInitGlobals function to pass a pointer to a static NKGLOBALS structure to the OAL and retrieve a pointer to an OEMGLOBALS structure in the form of a return value from the OAL. NKGLOBALS contains pointers to all the functions and variables used by KITL and the Microsoft kernel code. OEMGLOBALS has pointers to all the functions and variables implemented in the OAL for the BSP. By exchanging pointers to these global structures, Oal.exe and Kernel.dll have access to each other's functions and data, and can continue with architecture-generic and platform-specific startup tasks.

The architecture-generic tasks include setting up page tables and cache information, flushing TLBs, initializing architecture-specific buses and components, setting up the interlocked API code, loading KITL to support kernel communication for debugging purposes, and initializing the kernel debug output. The kernel then proceeds by calling the OEMInit function through the function pointer in the OEMGLOBALS structure to perform platform-specific initialization.

Table 5-5 lists the platform-specific funtions that Kernel.dll calls and that you might have to modify in your BSP to run Windows Embedded CE on a new hardware platform.

Table 5-5 Kernel startup support functions

Kernel Independent Transport Layer

The OEMInit function is the main OAL routine that initializes board-specific peripherals, sets up the kernel variables, and starts KITL by passing a KITL IOCTL to the kernel. If you added and enabled KITL in the run-time image, the kernel starts KITL for debugging over different transport layers, as discussed in Chapter 4, "Debugging and Testing the System."

Table 5-6 lists the functions that the OAL must include to enable KITL support on a new platform.

Table 5-6 KITL support functions

Profile Timer Support

Located at the core of the operating system, the OAL is a perfect choice for mechanisms to measure the performance of the system and support performance optimization. As discussed in Chapter 3, "Performing System Programming," you can use the Interrupt Latency Timing (ILTiming) tool to measure the time it takes to invoke an interrupt service routine (ISR) after an interrupt occurred (ISR latency) and the time between when the ISR exits and the interrupt service thread (IST) actually starts (IST latency). However, this tool requires a system hardware tick timer or alternative high-resolution timer that is not available on all hardware platforms. If the new hardware platform supports a high-resolution hardware timer, you can support ILTiming and similar tools by implementing the functions listed in Table 5-7.

Table 5-7 Profile timer support functions

Apart from the core system functions, the BSP also contains device drivers for peripherals. These peripheral devices can be components on the processor chip or external components. Even when separate from the processor, they remain an integral part of the hardware platform.

Device Driver Code Locations

Table 5-8 lists the source code locations for device drivers according to the PQOAL model. If your BSP is based on the same processor as the reference BSP, then the adaptation of device drivers mainly requires modification to the source code in the %TGTPLATROOT% folder. It is also possible to add new drivers to the BSP if the new platform includes peripherals that are not present in the reference platform. For more information about developing device drivers, see Chapter 6, "Developing Device Drivers."

Table 5-8 Source code folders for device drivers

Windows Embedded CE uses a paged virtual memory management system with a 32-bit virtual address space, mapped to physical memory by using the MMU. With 32 bits, the system can address a total of 4 GB of virtual memory, which CE 6.0 divides into the following two areas (see Figure 5-5):

■ Kernel space Located in the upper 2 GB of virtual memory and shared between all application processes running on the target device.

■ User space Located in the lower 2 GB of virtual memory and used exclusively by each individual process. Each process has its own unique address space. The kernel manages this mapping of the process address space when a process switch occurs. Processes cannot access the kernel address space directly.

Figure 5-5 Virtual memory space in Windows Embedded CE 6.0

Kernel Address Space

Windows Embedded CE 6.0 divides the kernel address space further into several regions for specific purposes, as illustrated in Figure 5-6. The lower two regions of 512 MB each statically map physical memory into cached and non-cached virtual memory. The middle two regions for kernel execute in place (XIP) DLLs and Object Store are important for the OS design. The remaining space is for kernel modules and CPU-specific purposes.

Figure 5-6 Kernel space in Windows Embedded CE 6.0

Table 5-9 summarizes the kernel virtual memory regions with start and end addresses.

Table 5-9 Kernel memory regions

Process Address Space

The process address space ranges from 0x00000000 through 0x7FFFFFFF, and is divided into a CPU-dependent kernel data section, four main process regions, and a 1 MB buffer between user and kernel spaces. Figure 5-7 illustrates the main regions. The first process region of 1 GB is for application code and data. The next process region of 512 MB is for the DLLs and read-only data. The next two regions of 256 MB and 255 MB are for memory-mapped objects and the shared system heap. The shared system heap is read-only for the application process, but readable and writable for the kernel.

Figure 5-7 Process space in Windows Embedded CE 6.0

Table 5-10 summarizes the virtual memory regions in user space with start and end addresses.

Table 5-10 Process memory regions

Memory Management Unit

Windows Embedded CE 6.0 requires the processor to provide a memory mapping mechanism to associate physical memory with virtual memory, up to a maximum of 512 MB of mapped physical memory. Figure 5-8 shows an example with 32 MB of flash memory and 64 MB of RAM mapped into the cached and non-cached static mapping regions of the kernel. On ARM-based and x86-based platforms, the memory mapping relies on a user-defined OEMAddressTable, whereas on the SHx-based and MIPS-based platforms, the mapping is directly defined by the CPU. The Memory Management Unit (MMU) is responsible for managing the physical-to-virtual address mappings.

Figure 5-8 Physical-to-virtual memory mapping example

Statically Mapped Virtual Addresses

The virtual memory regions depicted in Figure 5-8 are statically mapped virtual addresses to emphasize the fact that they are defined at startup time and the mapping does not change. Statically mapped virtual addresses are always available and directly accessible in kernel mode. It is noteworthy, however, that Windows Embedded CE also supports static mapping at runtime by means of CreateStaticMapping and NKCreateStaticMapping APIs. These functions return a non-cached virtual address mapped to the specified physical address.

Dynamically Mapped Virtual Addresses

The kernel can also manage the mapping of physical-to-virtual addresses dynamically, which is the technique used for all non-static mappings. A driver or DLL loaded into the kernel through LoadKernelLibrary can reserve a region of virtual memory in the kernel address space by calling VirtualAlloc and then map the virtual address to a physical address by creating a new page-table entry through a call to VirtualCopy. This is a common technique to map virtual addresses to the registers or frame buffers of peripheral devices in order to perform input/output operations. If the mapped buffer is no longer needed, the device driver or DLL can call VirtualFree to remove page-table entry and free the allocated virtual memory.

You must customize two elements to include information about static memory mappings in a BSP:

■ Config.bib file Provides information about how the system should use the different memory regions on the platform. For example, you can specify how much memory is available for the OS, how much can be used as free RAM and also reserve memory for specific needs.

■ OEMAddressTable Provides information about the memory layout of the underlying platform, as discussed in Lesson 1. The memory specified in Config.bib should also be mapped in the OEMAddressTable.

Mapping Noncontiguous Physical Memory

As mentioned in Chapter 2, "Building and Deploying a Run-Time Image," you must define a single contiguous region in the RAMIMAGE memory region for the operating system in the MEMORY section of the Config.bib file. The system uses this definition to load the kernel image and any modules you specified in the MODULES and FILES sections. You cannot define multiple RAMIMAGE regions, yet the OAL can extend the RAMIMAGE region and provide additional noncontiguous memory sections at runtime.

Table 5-11 summarizes important variables and functions to extend the RAM region.

Table 5-11 Variables and functions to extend the RAM region

Device drivers often need access to physical resources, such as memory-mapped registers or DMA buffers, yet drivers cannot directly access physical memory because the system only works with virtual addresses. For device drivers to gain access to physical memory, the physical addresses must be mapped to virtual addresses.

Dynamically Accessing Physical Memory

If a driver requires physically contiguous memory, as in the case of buffers required for DMA operations, the driver can allocate contiguous physical memory by using the AllocPhysMem function. If the allocation is successful, AllocPhysMem returns a pointer to the virtual address that corresponds to the specified physical address. Because the system allocates memory, it is important to free the memory later on when it is no longer needed by calling FreePhysMem.

On the other hand, if a driver requires non-paged access to a physical memory region defined in Config.bib, you can use the MmMapIoSpace function. MmMapIoSpace returns a non-paged virtual address that is directly mapped to the specified physical address. This function is typically used to access device registers.

Statically Reserving Physical Memory

Occasionally, it may be necessary to share a common region of physical memory between drivers or between a driver and the OAL (such as between an IST and an ISR). Similar to sharing a memory region for boot arguments between boot loader and kernel, you can reserve a shared memory region for driver communication purposes in the Config.bib file. A standard practice is to use the DRIVER_GLOBALS structure defined in Drv_glob.h, as mentioned in Lesson 1.

Communication between Drivers and the OAL

In addition to the standard set of IOCTLs required by the kernel, drivers can communicate with the OAL through custom IOCTLs implemented in OEMIoControl. Kernel-mode drivers call OEMIoControl indirectly through KernelIoControl, passing in the custom IOCTL. The kernel does no processing, other than passing the parameters straight through to OEMIoControl. However, user-mode drivers cannot directly call custom OAL IOCTLs by default. The KernelIOControl calls from user-mode drivers or processes are passed to OEMIoControl through a kernel-mode component (Oalioctl.dll), which maintains a list of user-accessible OAL IOCTL codes. The call is rejected if the requested IOCTL code is not listed in this module, but you can customize this list by modifying the Oalioctl.cpp file that is located in the %_WINCEROOT%\Public\Common\Oak\Oalioctl folder.

The maximum power saving state that a Windows Embedded CE device can support is the Power Off or Suspend state. The system can request the device to enter the Suspend state by calling GwesPowerOffSystem directly or SetSystemPowerState. Both functions eventually call the OEMPowerOff routine.

The OEMPowerOff routine is part of the OAL and responsible for switching the CPU into Suspend state. OEMPowerOff should also put the RAM into self-refresh mode if the processor does not automatically do so when it enters the Suspend state. You can also set up the interrupts to wake up the device. In handheld devices, this is typically the power-button interrupt, but you may use any wakeup event source that is appropriate for your target platform.

Entering the Suspend State

When entering the Suspend state, Windows Embedded CE performs the following sequence of steps:

1. GWES notifies the Taskbar about the power down event.

2. The system aborts calibration if in the calibration screen.

3. The system stops the Windows message queues. After step 3, the system enters single-thread mode, which prevents function calls that rely on blocking operations.

4. The system checks if the startup user interface (UI) must appear on resume.

5. The system saves video memory to RAM.

6. The system calls SetSystemPowerState (NULL, POWER_STATE_SUSPEND, POWER_FORCE).

7. Power Manager:

a. Calls the FileSystemPowerFunction to power off the drivers related to the file system.

b. Calls PowerOffSystem to inform the kernel to do the final power down.

c. Calls Sleep(0) to invoke the scheduler.

8. Kernel:

a. Unloads GWES process.

b. Unloads Filesys.exe.

c. Calls OEMPowerOff.

9. OEMPowerOff configures the interrupts and puts the CPU in Suspend state.

Waking Up from Suspend State

When a pre-configured interrupt wakes up the system, the associated ISR runs and returns to the OEMPowerOff routine. On returning from this function, the system goes through the resume sequence, which includes the following steps:

1. OEMPowerOff re-configures interrupts to original state and returns.

2. Kernel:

a. Calls InitClock to re-initialize the system timer.

b. Starts Filesys.exe with power on notification.

c. Starts GWES with power on notification.

d. Re-initializes KITL interrupt if it was in use.

3. Power Manager calls FileSystemPowerFunction with power on notification.

4. GWES:

a. Restores video memory from RAM.

b. Powers on Windows Manager.

c. Sets the display contrast.

d. Shows startup UI if required.

e. Notifies Taskbar of resume.

f. Notifies User Subsystem.

g. Triggers applications as required.

To help you successfully master the exam objectives presented in this chapter, complete the following tasks.

Access the Hardware Registers of a Peripheral Device

Implement a device driver for peripheral hardware and access the hardware registers by using the MmMapIoSpace API to interact with the device. Note that it is not possible to call MmMapIoSpace from an application.

Reorganize Platform Memory Mappings

By modifying the Config.bib file of the cloned Device Emulator BSB, you can increasingly reduce the available RAM on the system and study the impact in terms of available memory on the system by using the memory information APIs or Platform Builder tools.