Hive-Based Registry for CE 6.0

Hive-Based Registry for CE 6.0
Created by samphung on 11/20/2010 10:54:27 PM

When deploying Windows Embedded CE operating system to a device, there is the need for the device t...

Introduction

When deploying Windows Embedded CE operating system to a device, there is the need for the device to be able to save system and application settings to non-volatile storage when the device is power off, and able to boot up with these saved settings when the device is power on again.

To accomplish the task to save these system and application settings between power-reset for a Windows Embedded CE device, Hive-Based registry is used. To help better understand how Hive-Based registry work under Windows Embedded CE, we need to understand how a Windows Embedded CE operating system with Hive-Based registry implemented boot up.

A Windows Embedded CE operating system with Hive-Based registry implemented goes through two different phases when it boot. During the first boot phase, the system load a minimum set of operating system components and device driver, enough to access the storage device’s file system and read the registry file saved from the previous session. When the registry file is not detected on the designated file system, or become corrupted, the operating system will continue the boot process and uses the default registry settings, just as the device is booting up for the first time use. If registry file from previous session is detected, the saved registry entries are read and are used to continuing on with the second boot phase. During the second boot phase, the system continues the boot up process and load additional operating system components and device drivers which were not loaded during the first boot phase.

One of the common problem associate with Hive-Based registry implementation is duplicated driver loading during the first and second boot phases, where the device driver is loaded during the first boot phase is loaded again during the second boot phase and caused the system to fail and unable to complete the boot up process.

It’s actually quite simple to implement Hive-Based registry if you understand how it works and what is needed.

Adding Hive-Based Registry to the OS Design

There are different methods to add Hive-Based registry support to the OS design.

- Include the Hive-Based registry component to the OS design from the component catalog

- Set the SYSGEN_FSREGHIVE environment variable

In addition to the Hive-Based registry component, device drivers for the storage device and file system are needed in order for the operating system to access the storage device and save the settings to a file system on the storage device.

Hive-Based registry implementation is little bit different between different hardware platforms. An eBox-3310A (built with x86 CPU) is used as the reference hardware for this application note. The following components from the Windows Embedded CE component catalog were added to the OS design to implement Hive-Based registry:

- ATAPI storage driver

- FAT file system driver

- Hive-Based registry component

In addition to the above components, the PRJ_ENABLE_FSREGHIVE and PRJ_BOOTDEVICE_ATAPI environment variables were set for the OS design. Including the environment variables set by the device driver, here is the list of the environment variables included to the OS design needed for Hive-Based registry to function:

- PRJ_ENABLE_FSREGHIVE

- PRJ_ENABLE_BOOTDEVICE_ATAPI

- SYSGEN_FSREGHIVE

- SYSGEN_ATAPI

- SYSGEN_FATFS

Note: Hive-Based registry implementation may be little bit different between different hardware platforms.

Sample Registry Entries to Support Hive-Based Registry for the eBox-3310A

The Windows Embedded CE board-support-package (BSP) for the eBox-3310A is configured to support Hive-Based registry implementation. Adding support to implement Hive-Based registry is a matter of clicking a check box.

In this section, we will list the registry entries which affect Hive-Based registry function and explain the impact:

; HIVE BOOT SECTION

[$(PCI_BUS_ROOT)\Template\A9121]

"IClass"=multi_sz:"{CDDC3621-3512-4b3f-BB6F-B4DD5E061795}"

"Prefix"="IDE"

"Dll"="atapi.dll"

"Order"=dword:06

"Class"=dword:01

"SubClass"=dword:01

"VendorID"=dword:17F3

"DeviceID"=dword:1011

"ConfigEntry"="GenericConfig"

"Legacy"=dword:00 ; not legacy

"SysIntr"=dword:00 ; provided by PCI bus driver

"DMAAlignment"=dword:04 ; default DMA alignment

"SoftResetTimeout"=dword:03 ; ATA/ATAPI spec defines 31s ceiling; this is too long

"StatusPollCycles"=dword:100 ; Status register DRQ/BSY polling; 256 poll cycles

"StatusPollsPerCycle"=dword:20 ; Status register DRQ/BSY polling; 32 polls per cycle

"StatusPollCyclePause"=dword:05 ; Status register DRQ/BSY polling; 5 milliseconds between poll cycles

"SpawnFunction"="CreatePromise" ; controller-specific instantiation function

"IsrDll"="giisr.dll" ; bus-agnostic; installable ISR

"IsrHandler"="ISRHandler" ; bus-agnostic; installable ISR

"RegisterStride"=dword:01 ; ATA register stride; register block is contiguous

[$(PCI_BUS_ROOT)\Template\A9121\Device0]

"IClass"=multi_sz:"{A4E7EDDA-E575-4252-9D6B-4195D48BB865}"

"Prefix"="DSK"

"Dll"="atapi.dll"

"InterruptDriven"=dword:01 ; enable interrupt driven I/O

"DMA"=dword:01 ; enable DMA

"DoubleBufferSize"=dword:10000 ; 128 sector (65536 byte) double buffer

"DrqDataBlockSize"=dword:200 ; 1 sector (512 byte) DRQ data block

"WriteCache"=dword:01 ; enable on-disk write cache

"LookAhead"=dword:01 ; enable on-disk look-ahead

"DeviceId"=dword:00 ; device 0, i.e., primary master

"TransferMode"=dword:FF ; use device default transfer mode (Ultra DMA 3, 4 require 80-conductor cable)

[$(PCI_BUS_ROOT)\Template\A9121\Device1]

"IClass"=multi_sz:"{A4E7EDDA-E575-4252-9D6B-4195D48BB865}"

"Prefix"="DSK"

"Dll"="atapi.dll"

"InterruptDriven"=dword:01 ; enable interrupt driven I/O

"DMA"=dword:01 ; enable DMA

"DoubleBufferSize"=dword:10000 ; 128 sector (65536 byte) double buffer

"DrqDataBlockSize"=dword:200 ; 1 sector (512 byte) DRQ data block

"WriteCache"=dword:01 ; enable on-disk write cache

"LookAhead"=dword:01 ; enable on-disk look-ahead

"DeviceId"=dword:01 ; device 2, i.e., secondary master

"TransferMode"=dword:FF ; use device default transfer mode (Ultra DMA 3, 4 require 80-conductor cable)

[HKEY_LOCAL_MACHINE\init\BootVars]

"SYSTEMHIVE"="\\Registry\\system.hv"

"PROFILEDIR"="\\Registry"

"Start DevMgr"=dword:1

"DefaultUser"="User"

"Flags"=dword:3

[HKEY_LOCAL_MACHINE\System\StorageManager\FATFS]

"Flags"=dword:1000

[$(PCI_BUS_ROOT)\Template\A9121]

"Flags"=dword:1000

[$(PCI_BUS_ROOT)\Template\A9121\Device0]

"Flags"=dword:1000

[$(PCI_BUS_ROOT)\Template\A9121\Device1]

"Flags"=dword:1000

; END HIVE BOOT SECTION

The registry entries are wrapped between the following pair of tags.

- HIVE BOOT SECTION

- END HIVE BOOT SECTION

The “Flags”=dword:1000 set the flag for the system to load the associated driver during the first boot phase and skip loading these drivers during the second boot phase.

Summary

With each new version of Windows Embedded CE, additional features and resources help simplify complicated tasks. When not implemented properly, Hive-Based registry can cause the operating system fails to boot.

The primary problem associate with Hive-Based registry implementation is:

- Required device driver not loaded during the first boot phase

- Driver already loaded in the first boot phase is loaded again during the second boot phase

To debug and resolve problem, generate an OS runtime image with KITL enabled, download the KITL enabled image from the Platform Builder development workstation to the target device, debug messages from the Platform Builder IDE’s output tab should provide useful information to help identify device drivers loading as the OS image boot up.

Additional Reference

The Windows Embedded CE 6.0 BSP for eBox-3310A and sample OS design project are available for download from the following URL:

http://www.embeddedpc.net/eBox3310aMSJK/

Implementing the Hive-Based Registry on Microsoft’s MSDN site:

http://msdn.microsoft.com/en-us/library/aa914710.aspx