Microsoft Corporation
December 4, 1998
This article describes the general process of putting the system into nonvolatile sleep using the BIOS, and describes some common compatibility problems that should be avoided.
The Advanced Configuration and Power Interface Specification, Version 1.0, in support of operating system-directed power management, defines a nonvolatile sleeping state (S4) that system makers can choose to implement in OnNow systems. Nonvolatile sleep preserves the system memory context on nonvolatile media, thereby removing the need to power most of the system and obtaining low-to-zero power consumption during sleep (at the cost of longer wake-up latency).
S4 is viewed differently from different perspectives. To the end user, S4 is simply a sleeping state. The most perceptible differences are that wake-up time is longer and that the computer can be unplugged while it is asleep.
To software, S4 is simply a sleeping state, the same as S1-S3, except that memory context must be written out to nonvolatile storage. The fact that this sleep state is nonvolatile is transparent to the operating system, drivers, and applications. S4 is distinguished only by its latency characteristics. Because of this, all application and driver processing leading up to S4 is the same as for S1-S3.
To hardware, S4 is the same as the soft-off state (S5), which means that power is removed from the system and the hardware, and that the BIOS must be reinitialized upon wake up. Consequently, all BIOS processing, up to the handoff to the operating system, is the same as for S5.
However, two implementations of the transition to S4 as defined in the ACPI specification delineate differences between the operating system and BIOS implementations. Operating system-initiated S4 is implemented entirely in the operating system and requires no special BIOS support. The operating system simply saves the required system-memory context to nonvolatile storage before sending the sleep command to the hardware. The context is then restored to main memory during operating system load, which takes place after handoff from the BIOS during wake up. The BIOS should be optimized to support this mode—for example, by doing a fast boot—but no support for the image itself is required in the BIOS.
With S4BIOS, however, the BIOS saves the memory context when requested by an explicit command from the operating system; the restore operation is performed before the operating system regains control upon wake up. The first instantiation of the Microsoft® Windows® 98 operating system will not implement operating system-initiated S4, so it is crucial that S4BIOS implementations are compatible and robust.
The process of putting the system into and bringing it out of the S4 state using the S4BIOS transition entails three phases: detecting S4BIOS support, going to sleep, and waking. This section summarizes the activities in these phases. Notice that both Windows 98 and Windows 2000 operating systems will perform as defined in this article.
Detecting S4BIOS support. On platforms that support S4 (as indicated by the existence of an _S4 object in the Name Space), at initialization time, the operating system looks for the S4BIOS_F flag in the Firmware ACPI Control Structure (FACS) table, as defined in the ACPI specification.
Notice that support for the operating system-initiated S4 state is a prerequisite for S4BIOS support. If this flag is set, the platform firmware is expected to support the S4BIOS transition. If the firmware finds S4BIOS support, the operating system may or may not choose to use the S4BIOS technique to go into the S4 state. Operating systems that support operating system-initiated S4 (such as Windows 2000) will use the operating system-initiated S4 state instead.
Going to sleep. As stated previously, the processing before starting the S4BIOS transition to S4 is the same as for S1-S3. Specifically:
Waking. When waking, the BIOS and operating system perform the following specific actions.
BIOS actions during wake up:
Operating system actions during wake up:
The following sections describe implementation guidelines that can increase the likelihood of compatibility with Microsoft OnNow-capable operating systems. These guidelines stem from analysis and investigation of common problems seen in previous save-to-disk implementations.
Guidelines for storing images on the hard disk. The image of main memory to be stored can be saved in a special disk partition specifically intended for this purpose or in a file within the system partition. Each original equipment manufacturer (OEM) implementing S4BIOS is responsible for preinstalling this storage location and for developing and providing any tools needed to maintain it.
Guidelines for file systems. As a result of storing the image in the system partition, it is necessary for the BIOS code to deal with the operating system's file system. This involves both determining which file system is in use and locating a specific file within that file system. Documentation on Microsoft FAT16 and FAT32 file-system media structures is available on MSDN and from Microsoft Technical Services (contact your Microsoft Technical Account Manager).
Things to check before resuming from an S4BIOS image. This section describes the checks that Windows expects to be performed by the BIOS before waking from an S4BIOS image.
It is a good idea to inform the user that core configuration changes should be performed only when the operating system has been shut down. Users should be educated on how to do this on their particular machine, using either the Windows user interface or the Power button. For this reason, it is strongly recommended that systems implementing S4 provide both a Sleep button and a Power button.
DO NOT: stop or hang if there is a problem. If there is any problem waking from the memory image—because either one of the checks described in the previous section failed or a problem occurred while reading the memory image from the media—always print an error. Then perform a normal boot by loading the boot sector and executing it.
In all cases, the system must either wake to the image or perform a boot; it must never fail to run. All errors, other than the lack of the 0xAA55 boot sector signature, must be "continuable" errors that cause the BIOS to load the boot sector off the boot drive (drive A or drive C) and jump to it. Under no circumstances, other than the lack of the 0xAA55 boot sector signature, should the BIOS refuse to load the boot sector off the boot drive and jump to it. Implementation of S4BIOS should never prevent a user's system from rebooting.
DO NOT: allow any other volume to boot if a valid memory image exists. This might require the use of nonvolatile RAM (NVRAM).
DO NOT: hang when the image file has cross-links (especially cross-links to itself). S4BIOS implementations must be able to handle errors while reading the image file from the media. One common error is that the image file has cross-links to itself on the media, which causes the BIOS to hang. It is recommended that before reading the file, implementations should find out how many clusters are in the file. Then, if more clusters are read than the file size indicates, the image file is cross-linked to itself and cannot be restored. Implementations should detect this error condition, print an error, and exit cleanly.
DO: invalidate the current image file before jumping to the wake vector. In case the image is bad and the operating system stalls in the wake vector, this will prevent the system from trying to reload the image on subsequent reboots.
DO: verify the partition type before reading the memory image. This applies regardless of whether the image file is in its own partition or in a file in the operating system's file system. In both cases, the partition type must be correct.
DO: have bullet-proof disk routines. The disk read and write routines, which are provided by the OEM, must be bullet-proof. It is recommended that they all have a timer time-out architecture so that if a command to the disk controller doesn't complete within a few seconds, then the command is canceled and the read/write routine returns with an error.
DO: test your implementation thoroughly. Test on both Windows 98 and Windows 2000, and test all error conditions to ensure robustness.
Implementations of nonvolatile sleep states must be robust to ensure expected behavior for the user. Many common problems in BIOS implementations can be avoided with some additional information regarding Windows compatibility and common errors. Windows with OnNow support will work best with implementations that follow the guidelines described in this article.
For more information, see the OnNow home page, located at www.microsoft.com/hwdev/onnow.htm.