Snapshot Boot Development (Compact 2013)

  • Article

3/26/2014

Snapshot boot helps you reduce boot time by saving the memory of a device to persistent storage, and then restoring that state when the device reboots. Snapshot boot is a combination of OAL APIs and data structures that you use to save an image of the device’s memory.

You can use snapshot boot to:

  • Implement hibernate/resume by using a standard interface.
  • Take a snapshot without having to pre-reserve RAM to save the snapshot.
  • Take large snapshots of up to 500 MB.
  • Take a snapshot on devices that have over 512 MB of RAM.
  • Reduce boot time for large snapshots by providing support for pages of the snapshot memory to be read in on demand instead of all at once.

This guide provides information about the snapshot boot process and how to implement it on your device.

Prerequisites

The following are necessary in order to implement snapshot boot:

  • Full power management support: your BSP must include SYSGEN_PM.
  • Sufficient storage to store the snapshot must be available to the boot loader. You must have a driver for your persistent storage that can operate in the boot loader phase without any OS support.
  • Your drivers must support either the PowerUp() and PowerDown() power management functions, or the IOCTLPowerSet power management function.

Sample Code

An end-to-end code sample for how to implement snapshot boot is not included with Windows Embedded Compact 2013. There is snapshot boot sample code to take and resume from a snapshot. For more information, see Snapshot Boot Sample Code. These samples do not include the BSP or boot loader changes that must be made to support snapshot boot.

Snapshot Memory Design Considerations

Snapshot memory contains a device’s memory contents, thread contexts, OS status, and CPU and hardware status. It also contains the state of running programs that you want restored when the device boots from the snapshot. It may also include OEM specific areas of memory, such as display memory or memory shared between OS and the OAL for global variables.

You should first decide what you want to save in your snapshot. You may choose to save only the OS state in the snapshot, in which case applications will have to be manually started after booting from the snapshot. Or you may include running applications in the snapshot so that they are available immediately after the device reboots.

Next, take the snapshot when the device is in the state that you want restored when the device reboots. If you capture the snapshot too early, there may be time-consuming initialization left to do when the device resumes from a snapshot. If you capture the snapshot too late, you may take a larger snapshot that includes more running applications or running services than you want.

Large snapshots are usually caused by running large user mode programs. The amount of memory used by the operating system is fairly consistent. If you implement snapshot paging (see Implement APIs to Restore a Snapshot) you can read pageable memory back in on demand. The amount of non-pageable memory that must be restored before the system can resume does not vary regardless of the amount of memory being used when the snapshot is taken.

Optimize your snapshot to load quickly

The time it takes to restore a full snapshot depends on multiple factors, including the size of snapshot image and whether you support snapshot paging. For example, if you store a snapshot on flash and the throughput of your flash is 20 MB per second, it can take up to five seconds to restore a 100-MB snapshot.

To optimize performance, implement snapshot paging so that only the nonpageable memory is read back into memory, instead of the whole snapshot. The OS then demand loads the pageable memory in the snapshot as needed after the system resumes.

For more information about snapshot paging, see Implement APIs to Restore a Snapshot.

Optimize your snapshot for application responsiveness

After you issue the call to take a snapshot, the OS pages the contents of memory out to storage to reduce the amount of memory that must be included in the snapshot. Driver state is generally unknown when a driver is active, so the device is suspended to put the drivers into a power-off state.

The device is then resumed, after which there is a one minute delay. This delay provides an opportunity to start one or more applications by bringing them to the foreground. When you start an application by bringing it to the foreground, the OS pages memory back into RAM for the code and data that belong to that application. The memory will then be saved as part of the snapshot. This means that the application will respond more quickly after the device reboots. Memory that is saved in the snapshot can be read using a fast sequential read, which does not have the same overhead as reading in pages using page-fault handling. Therefore, include the active memory for an application in the snapshot to make it respond more quickly after the device reboots

You can programmatically detect when the one minute delay begins by monitoring GetSnapshotState for a change from the eSnapPass1 state to the eSnapPass2 state.

Storage considerations

It is important to determine how much persistent storage to set aside to store your snapshot and where you will store it. Watch the serial output during development for snapshot boot messages to see the minimum amount of storage is being requested. That will help you understand how much storage you will need for your image.

Storage options include any block-level storage medium, such as an SD card or NAND flash, for which you have driver support in the boot loader phase. You can choose the dedicated area in which to store the snapshot and how you will protect it from being overwritten by the OS. For example, you can designate your snapshot boot storage as reserved or read-only so that the OS does not use that portion of memory for other purposes.

The persistent storage driver that you have available during the boot loader phase will govern the type of storage you can use to store your snapshot. For example, if you have a driver for an SD card that can function during the boot loader phase, before the OS is running, then you can use an SD card to store your snapshot.

In This Section

  • Take a Snapshot
    Describes how to take a snapshot and which functions you must implement.
  • Restore a Snapshot
    Describes how to restore a snapshot and which functions you must implement.
  • Snapshot Boot Sample Code
    Provides sample code for taking a snapshot and restoring a snapshot, and utility functions that may be useful when you implement snapshot boot.

See Also

Concepts

BSP Development
Developer Guides

Other Resources

Snapshot Boot Reference