|
|
||||||
|
Home |
News |
Articles |
Forum
| |||||||
|
|
Integrating the Intel Persistent Storage Manager with Windows CE 4.x
2004-12-23 Article Rating:  / 0
IntroductionThe Intel Persistent Storage Manager (IPSM) is the Windows CE file system driver for Intel flash memory. Intel provides the IPSM driver (through its local representatives) in the form of library files, but the source code is not readily available. Nevertheless, an IPSM implementation is possible based on the provided libraries.
Fortunately, Intel does provide the source to plat_api.c, the one file Intel recommends for modification. In order to implement IPSM, it is also necessary to modify several registry keys and a few OEM files.This article explains how to integrate PSM for use on an Intel XScale SA-1110 processor-based board equipped with Intel StrataFlash flash memory. The process of integrating IPSM -- and making it work -- was somewhat challenging, due to the fact that the required information was not available in a single location. Instead, it was necessary to search through numerous sources for the relevant details. Thus, the main objective of this article is to make it easier for others to implement IPSM on their platforms. The article is presented in two parts: the steps required to integrate IPSM from scratch; and, discussion of several key issues that related to the process. The steps required to integrate IPSM are: A. Setting up the PSM directory
psmfsd.dll in the $(_TARGETPLATROOT)\drivers\PSM\SA11X0\WCE.NET\bin directory.E. Making the registry settings (the tricky part . . .) The registry key changes for Windows CE 4.0 and 4.2 have minor differences, as shown below.
F. Final build After the above modifications, you will need to do a clean rebuild. You need to verify whether psmfsd.dll and flshdrv.dll are present in the image. Otherwise, you may have to copy them from some subdirectory of $(_TARGETPLATROOT)\drivers\PSM to the release directory, and make it part of the image.With this NK.bin you should be able to get the PSM file storage and the registry backup working fine.What exactly IPSM does, and how the filesystem works, is hidden within Intel's Intellectual Property. But, from the information available and the changes made, we can trace an outline of the IPSM. Intel's psm driver contains a file manager that comes in the form of two libraries. Specifically, psmfsd.lib and psmhal.lib. psmfsd.lib get linked along with plat_api.c to create psmfsd.dll; and psmhal.lib gets linked with plat_api.c, which become part of the Hardware Adaptation layer / Board Support Package code. Once the correct settings are made in plat_api.c and in the HAL files, the PSM file storage will start working. The registry backup is a tricky part.In the RAM-based registry, the registry is in RAM and vanishes as soon as the power is switched off. To provide persistent storage to a RAM-based registry we need to allocate registry backup space in the Plat_Oem structure. Also, we (OEMs) have to implement the WriteRegistryToOEM() and ReadRegistryFromOEM() functions. These functions do a low-level write of the registry to the flash and read it back the same way. WriteRegistryToOEM() is called whenever RegFlushKey() is called to store the registry on the flash. While booting, a call to ReadRegistryFromOEM() is made and if it is successful the registry is loaded from the flash. That's the backup procedure in the RAM-based registry.In a hive-based registry, there are two files named boot.hv and system.hv (the names can be changed using registry settings). When using the hive-based registry, we have two boot phases: the first boot phase makes use of boot.hv to bring up the most important components; during the second phase, system.hv is taken from the filesystem and used to complete the boot process. To reach the filesystem and get to system.hv, it is required that the PSM driver be loaded. But, the PSM driver is loaded based on the registry, only. So, the keys that load PSM have to be in the boot hive section (boot.hv). There are a few other keys that need to be loaded before system.hv is loaded. These are also part of boot.hv. Whatever has to go into boot.hv needs to be mentioned between ;HIVE BOOT SECTIONeither in common.reg, platform.reg or project.reg.Care should be taken to decide which keys become part of boot.hv, and which become part of system.hv."Flags"=dword:1000This setting in the registry flag tells the Device Manager to load the driver in the first boot phase with the boot registry, and not to load it a second time in the second boot phase with the system registry. It prevents the driver from being started twice. "SYSTEMHIVE"="system.hv"These keys tell the booting OS to start the device manager in order to reach system.hv (the system hive registry file). The device manager has to be started at this stage because, to get the system.hv file from the filesystem, the necessary drivers need to be loaded -- and only the device manager can do this."MountFlags"=dword:2This says that the filesystem may contain a registry. The boot process The booting consists of two phases. Initially, the system boots with boot.hv. In this phase, after Nk.exe, coredll.dll, filesys.exe, fsdmgr.dll, etc. load, the psm driver psmfsd.dll and regenum.dll are loaded. Once this is done, the filesystem becomes accessible and system.hv is taken from the flash. What happens when booting for the first time? This interesting situation is handled differently. First, the flash is examined for proper format. Because a fresh flash is not PSM-formatted, PLAT_FormatRecovery() is called, a decision on the format and format options is made, and formatting is done. This formatting may take some time, which is the reason why the boot process might appear to have halted when PSM is enabled for the first time. Since there is no system.hv in the filesystem at this point, the default system.hv is taken from the NK.bin image and stored in the flash. PSM as the root filesystem To make IPSM become the root filesystem, the ROM-only filesystem has to be enabled in place of the RAM/ROM filesystem. Also, the mountflags should be . . . "MountFlags"=dword:6. . . which means the mounted filesystem may contain root and also the system hive. The remainder of the settings are similar. In this case, we have the windows directory in ROM, and the rest in the IPSM. But, unfortunately, the program files folder seems to vanish. Well, there is a way to handle this situation -- and that will be the subject of a subsequent article. To be continued . . .  Maharajan Veerabag is a Technical Lead at e-con Systems in Chennai, India. His software specialities include device drivers and OS internals, and he has hands-on experience in both Windows CE and Windows XP Embedded and in porting embedded OSes. He holds a Bachelor of Engineering, and his hobbies include music, puzzles, and debugging.
|
pkfuncs.h>
news feed
