Working with USB Boot
Windows Embedded Standard 7 includes support for booting systems from USB flash devices (UFDs). The reasons why you might want to use USB Boot functionality are as follows:
Help to reduce bill-of-material (BOM) cost for OEMs that are building devices.
Increase the overall system stability by helping to reduce the number of moving parts in a system, for example, a hard disk.
This technical article discusses scenarios and precautions that you should consider when you design systems that use USB Boot functionality.
Present-day flash devices implement wear-leveling to extend the life of the media. However, there are still some basics that you should consider to make sure that you are not causing your devices to fail prematurely.
Write filters will help reduce the disk writes made to the protected media. We recommend that you use one of the two available write filters, with Enhanced Write Filter (EWF) being the best option for protecting a UFD. EWF is a disk-volume driver that will not allow NTFS file system metadata to be written to the disk.
If write filters cannot be used for the system, you should try to disable the services in Windows that cause high volumes of file IO; for example, file-indexing service, defragmentation, and prefetching. However, the purpose of using these services is to improve run-time performance in specific user scenarios. Be aware that disabling these services can affect run-time performance.
If the UFD does wear out, it can have a severe impact on normal operation of the system. Some UFD OEMs provide utilities to check the health of a UFD. We recommend that you schedule and run these utilities periodically. In addition, you can use chkdsk on the system volume to discover worn UFDs.
USB Boot functionality does not support hibernation. System designers of portable systems or battery-backed systems should consider this. For more information about power management scenarios, see Mobile Battery Life Solution for Windows 7.
If the device will be connected to other external USB devices, make sure that you perform power-management tests for these secondary peripherals. For example, does the USB device sleep after being idle for a period of time?
Booting your device from a UFD might cause application compatibility issues. The following sections discuss installation of third-party USB drivers and application data read and write speeds.
Interaction with Third-Party USB Drivers
Does your device have usage scenarios that involve installation of third-party USB drivers? You should test end-to-end usage scenarios to make sure that the functionality works similar to what users might expect from a typical hard disk booted from an OS.
Booting from UFD can break software-design assumptions about disk read and write speeds. Generally, for UFDs there are large differences between disk read and write speeds that might expose software defects related to timing issues in various applications. It is common to find defects in multithreaded applications where assumptions about data that is read into buffers are invalidated on systems started from UFDs. To prevent this, make sure that you validate all important application scenarios on UFDs with different disk throughput.
Paging files are not supported on UFDs. If the system has only a UFD connected to the system, this implies there is a restriction on how much virtual memory you can have.
Does your application scenario require large amounts of memory? Lack of a page file might affect some of these scenarios. We recommend that you run stress tests for your scenarios to help you understand your device boundaries. For example, if you are designing a set-top box (STB) with UFD boot functionality, you should determine the maximum amount of data that you can buffer in RAM if you transfer it onto secondary storage.
Standard 7 allows you to have a page file on a non-system volume. If you have a secondary disk on the system, you can enable virtual memory on your device.