Optimizing Resident Flash Arrays in Windows CE Devices

---

Windows CE and resident flash arrays would seem to be a perfect match for portable and embedded devices. The modularity of Windows CE gives developers the flexibility to build relatively small-footprint, mobile, 32-bit devices that integrate with other Windows operating systems, while resident flash arrays (RFAs) are small, low-power storage media soldered directly on the board. High-volume systems often use soldered-in flash components. But Windows CE has traditionally provided no native support for resident flash devices and the inherent characteristics of flash make them particularly challenging to incorporate in Windows CE. Writing and erasing flash requires the use of flash hardware-specific programming algorithms. Programming flash memory takes a long time. Without software to manage data writes, power interruptions can leave the part unreadable. Additionally, writing to flash can only change a bit from a one to a zero. To change a bit value from a zero to a one, a portion of the flash part must be erased, which raises several additional issues:

• Flash can only be erased in large blocks. Flash allocation granularity is defined by the size of a specific flash part’s erase sectors, which are typically 128KB or more.
• Flash has a limited number of write-erase cycles, requiring wear-levelingalgorithms to maximize the life of the device.
• Some flash technologies ship with bad blocks and develop more of them over time. Software must manage these blocks to prevent data loss.

Flash memory management software, such as Datalight’s FlashFX, simplifies and optimizes flash usage in Windows CE. FlashFX directly supports popular resident flash memories and installs directly into Platform Builder’s Component Catalog for all CPUs. The software makes the flash device appear as a standard disk drive to Windows CE applications, eliminating the need to deal with the intricacies of flash memory. Windows CE may ultimately incorporate some support for resident flash arrays, but FlashFX has the advantage of working with all versions of the Windows CE and all types of flash technologies.

Traditional Flash Memory Management under Windows CE

Flash allocation granularity has traditionally imposed restrictions on the design of Windows CE systems. A typical system layout is shown in the diagram on the left side of Figure 1. In these systems, the flash is partitioned into several dedicated regions (P_x, where P = partition), each consisting of one or more erase sectors.

Not only is there unused space within each partition, the dedicated partitioning forces system designers to predict how much room they must reserve for future enhancements. Reserving space for updating the OS image is particularly burdensome since operating systems tend to grow to accommodate the requests of all application developers.

Persistent registry storage is another key opportunity for flash space optimization. Typically, the original (default) version of the system registry is kept in the Windows CE ROM image file (NK.BIN), while updates are made in RAM where data will be lost if power is interrupted. To save both the active registry and a backup copy in flash memory, two flash partitions must be reserved to ensure that one is always valid. During an update, one is erased and rewritten while the other is preserved. Only after the new version is fully validated is the old version erased and updated. Because of the large erase sector allocation granularity, significant portions of the flash are wasted. For example, if a particular system’s registry file is 180KB and the flash memory erase sector is 256KB, 152KB is wasted in the registry and the backup registry partitions.

Designers of Windows CE systems have typically had two options for using flash memory to store persistent registry data:

OEM registry routines, WriteRegistryToOEM() and ReadRegistryFromOEM(), can be written and debugged for every OEM Adaptation Layer (OAL). Each copy of the system registry must reside in its own dedicated partition in the flash array. The Windows CE file system-based routines, RegCopyFile() and RegRestoreFile(), have the benefit of file system allocation granularity but require a subsequent warm-boot of the operating system.

Ideally, designers need a simple file-based registry storage mechanism that will not require a warm boot after the registry is read before it becomes active.

Seamless Flash Memory Management under Windows CE

The diagram on the right in Figure 1 shows a “seamless” flash memory management approach using FlashFX flash memory management software. By emulating a standard Windows CE disk drive, the software reduces flash memory allocation granularity to the standard 512-byte disk sector size. Managing a much larger portion of the RFA as a disk increases application data storage space and eliminates the need to determine exactly how much of the flash to reserve for each dedicated partition. Also, by distributing wear leveling over a larger flash disk region, FlashFX extends the RFA MTBF.

This seamless flash architecture provides some additional benefits. One of these is that the Windows CE image is now stored as a file in the flash disk. Because the flash disk software must be present before booting the system, FlashFX includes a Simple Embedded File System (SEFS) that provides an ANSI C-style buffered stream interface to files stored on FAT12 and FAT16 drives. With this design, data stored on a flash disk can be accessed before the Windows CE FAT file system is loaded. The Boot Loader code can, in turn, rely on SEFS to read the NK.BIN file image (previously stored on a flash disk using standard file system calls) into RAM and so natively boot from a FlashFX disk. Maintaining the Windows CE image on a disk also allows the operating system, as well as its embedded components and applications, to be upgraded in the field without predicting at manufacturing time how much space such an upgrade would require.

Persistent registry files may also be saved to and restored from the flash disk using code included. As in the Boot Loader, the persistent registry routines rely on SEFS to access the flash disk before the operating system is loaded. Storing registry values on a FlashFX disk allows the size of the registry to grow as needed while maintaining fine-grained allocation granularity. Additionally, no warm boot is required.

Board Support Package Integration

A BSP (Board Support Package) is a collection of software supplied by hardware manufacturers in direct support of Windows CE. A BSP includes the code for the OEM Adaptation Layer (OAL) as well as for the Boot Loader. FlashFX libraries may be incorporated in the Boot Loader to allow OEMs to natively boot Windows CE from a flash disk and into the OAL to perform OEM registry read and write functions. In this context, the term BSP applies to either application.

Before building the libraries into a BSP, the FlashFX DLL must be fully tested and functional. It is easier and safer to build and test the DLL apart from either the OAL or the Boot Loader when you first port FlashFX to your platform. Additionally, a functional DLL is required in order to write the NK.BIN file to the disk and to support the persistent registry functions. Once the DLL is functional, the library routines can be confidently incorporated into the BSP.

Building Flash Management Libraries into a BSP

The FlashFX DLL uses Windows CE registry entries to define the start and length of the flash disk. Obviously, this information will not be available to the routines that boot Windows CE nor that need to read the registry, and so similar information must be hard coded in an include file within the FlashFX sources.

Code compiled for use in the device driver is placed in FXHAL.LIB while code compiled for use in a BSP is placed in FXBOOT.LIB. The code in both libraries is otherwise nearly identical, so once the FlashFX DLL is functional, it is a small incremental step to provide access to the flash disk from a BSP.

The block diagram in Figure 2 shows the equivalence between the DLL and FXHAL.LIB in the normal operating system configuration and SEFS and FXBOOT.LIB in a BSP. The FlashFX core and the Flash Interface Module (FIM) are common to both configurations. The FIM contains the flash part specific code to program the flash. The shaded modules represent the platform specific interfaces that need to be ported to each hardware environment.

The FlashFX block device driver DLL is included in the NK.BIN file by adding an entry to the PLATFORM.BIB file for each hardware platform. The FlashFX libraries must be statically linked into both the OAL and the Boot Loader component: This linkage dependency is typically specified by adding a TARGETLIBS macro setting for each of the pertinent libraries in the SOURCES.CMN file of the BSP as shown in Example 1.

Inside Platform Builder, the Platform Settings for both the OAL and the Boot Loader components must define specific environment variables that determine how the libraries are to be built. A Custom Build Step must also be added to the Platform Settings for these components to insure that the libraries are properly rebuilt before the components are linked. These Platform Settings are automatically established for the FlashFX device driver component when it is added to the Platform from the Platform Builder Component Catalog.

Adding Persistent Registry Storage to the OAL

Windows CE maintains two global kernel variables that point to the OEM registry read and write routines, respectively. Once these pointers have been initialized in the OAL, Windows CE will call the routines indicated by these pointers to perform all persistent registry operations. Adding the code in Example 2 to the OAL and calling it from within the Windows CE OEMInit() function will cause Windows CE to automatically make use of the FlashFX registry functions.

The FXReadRegistryFromOEM() function is called early in the boot process and uses SEFS to read the registry file as requested by the kernel. The FXWriteRegistryToOEM() function is called by Windows CE whenever an application invokes the Windows RegFlushKey() function. FXWriteRegistry-ToOEM() loads COREDLL.DLL and relies on the Win32 file system API to write its buffered registry entries to the flash disk.

Adding Flash Disk Support to the Boot Loader

Microsoft defines four Boot Loader models and provides numerous examples of Boot Loader implementations in the Windows CE BSP add-on pack. The first step in adding flash disk support to a Boot Loader is to recognize how SEFS fits into the Boot Loader model for a platform. In the CEPC model, for instance, SEFS provides one to one replacement functions for the file access functions used to manipulate the DOS NK.BIN file.

Once SEFS’s role in the Boot Loader model is selected, the relative priority of any alternate boot media must be established. For example, it may be desirable for an Ethernet connection to take priority over booting from the NK.BIN file stored on the flash disk during development.

Next, the code to processes the NK.BIN file on the flash disk must be integrated into the existing Boot Loader code. The particular integration steps that must be taken will vary with every platform. In general the following SEFS functions must be considered:

• sefinit() is used to initialize the underlying modules and to validate the FAT format of the flash disk. This function must be successfully called once before any other SEFS routines can be used.

• sefopen() is used to locate the NK.BIN file and open a stream for reading the ROM image file.

• sefread() is used to read a sequential stream of bytes from the NK.BIN file. *sefclose() is called to close the current stream for later reuse.

Abstraction Benefits

By providing RFA disk emulation, flash management software employs a widely understood metaphor for easily accessing flash memory that simplifies the system design task while optimizing RFA usage. This increased level of software abstraction frees developers from the complexity of providing robust RFA access, allowing them to focus instead on fully exploiting the value of Windows CE to their applications.

About the Authors

Dennis Edwards is a Senior Software Architect for Datalight Inc and currently serves as the technical lead for the FlashFX product. Dennis has a BSCS from Pacific Lutheran University and 17 years experience in embedded systems development.

Keith Garvin is the Director of Engineering for Datalight Inc. He has worked with flash media management software systems such as MS-FFS, PCMCIA FTL, and several other flash management systems. Keith is the architect and named inventor of multiple patents used in Datalight’s FlashFX product. The authors can be reached through Windows Developer.