|
|
更具体请看:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnxpembed/html/eltorito.asp
Creating a Bootable CD-ROM with the El Torito Feature in Windows XP Embedded
Eric Schweickert
Microsoft Corporation
September 2002
Applies to:
Microsoft® Windows® XP Embedded
Summary: Learn about the El Torito feature in Windows XP Embedded. This article includes an overview of the El Torito feature and the ELTORITO.SYS Driver and provides common support issues along with instructions for creating a bootable CD-ROM with the feature. (10 printed pages)
Contents
El Torito Overall Mechanics and the ELTORITO.SYS Driver
The HD2ISO.EXE Utility
Creating an El Torito "Master" CD
Common Support Issues by Symptom
Constraints, Limitations, and Architectural Incompatibilities
Additional Information
El Torito Overall Mechanics and the ELTORITO.SYS Driver
Setup of the El Torito Device by the System BIOS
In order to understand the overall mechanics of El Torito, knowledge of the El Torito 1.0 specification is necessary. This specification is available in Adobe Acrobat format at http://www.phoenix.com/resources/specs-cdrom.pdf.
Microsoft® Windows® XP Embedded utilizes El Torito type 4 emulation (hard disk emulation), which sets it apart from most other implementations of the El Torito standard. In the past, Microsoft MS-DOS® has utilized type 1, 2, or 3 emulation (floppy disk). In this case, the system basic input/output system (BIOS) treats the sector extent on the CD-ROM addressed by the Boot Volume Descriptor at sector 17 (0x11 . . . remember that CD-ROM sectors are 2048 bytes in length) as a standard floppy disk, either 1.2 megabytes (MB), 1.44 MB or 2.88 MB depending on the emulation type. The BIOS will expose an extended INT-13 interface to the emulated extent on the CD-ROM such that software can communicate with it as though it is a standard floppy disk, assigning the emulated device a drive number of 0x00. Your typical Microsoft Windows NT® version 4.0, Windows 2000, or Windows XP setup CD also boots with El Torito support, but it boots with an emulation of type 0 (no emulation). That is to say that the SETUPLDR (a modification/subset of NTLDR) knows intrinsically that it is booting from CD specifically. In this case, the loader and kernel are flagged, such that they know that they will be reading from the CD-ROM device instead of a floppy or hard disk device. In this scenario, the Boot CD is only used as setup/install media and does not boot and run the final operating system (OS).
Windows XP Embedded, however, utilizes (as stated previously) type 4 emulation, meaning that the extent addressed by the Boot Volume Descriptor at sector 17 (0×11) is emulated as a standard hard disk and assigned INT-13 device number 0×80, "bumping" the hard disk that would normally be drive 0×80 to drive number 0×81, and so forth. For a complete list of El Torito emulation types and descriptions, see section 2.5, figure 3, and section 5 of the El Torito Specification. The system BIOS then expects the sector extent to contain both a Master Boot Record (MBR) and a boot sector. The extent that represents a hard disk volume can contain multiple partitions. However, due to disk geometry issues and poorly implemented BIOSes, Windows XP Embedded can only boot from the first partition on the CD. The only supportable configuration of an El Torito volume on a CD contains one or more partitions, the first of which is marked as the active partition and is type 0×6 (FAT16 also known as BIGDOS). The remainder of the partitions can be of any type, but cannot be marked active. Most, if not all, BIOSes will not accept any other file system in the boot partition. For a complete list of file system types recognized by Windows, see the Windows 2000 Server Resource Kit; Server Operations Guide; Storage, File Systems, and Printing; Disk Concepts and Troubleshooting; Disk Sectors Critical to Startup; Master Boot Record.
The Bootstrap
After the system BIOS has set up the extended INT-13 interface to the emulated disk device, it boots from the device as it would any standard hard disk. The Master Boot Record is read and loaded into memory. The MBR, which does not need to be modified from its original form whatsoever, then loads the boot sector from the bootable partition. After they are loaded, the loader, NTDETECT, and the loader stub that the kernel communicates with are all operating under the premise that they are communicating with an extended INT-13 interface to a standard hard disk. There is no information of the fact that the device does not physically exist.
All is well until the kernel stops using INT-13 calls to read from the disks after initializing the boot drivers. After the disk stacks are set up, the OS starts using them for all read/write purposes. Unfortunately, the device does not actually exist and no disk stack is created for it because the PnPMgr has no knowledge of the device and the remainder of the OS has no way of knowing that it actually booted from an extent on CD. This then creates the need for an additional boot driver.
Such a driver must be previously set up in the registry as a bus device enumerating the volume(s) on the El Torito extent. This will be discussed in further detail in the section regarding the creation of a master CD in addition to the problems section. This bus driver simply provides a functional device object for a software bus and enumerates a physical device object for one or more disk devices. To enumerate El Torito disk devices, the driver registers for device arrival notification on all CD-ROM devices present in the system. When notified of a device arrival, the bus FDO "probes" the device. If the device contains media, an El Torito boot record in the volume descriptor set, an El Torito boot catalog and a valid extent, the driver creates a device object for an El Torito disk and stores information about it in a linked list hanging off the driver’s private extension. When the device is set up and started, the driver sends an IOCTL_PREVENT_MEDIA_REMOVAL to the associated CD-ROM device to prevent the user from removing the system volume from the device. The device is not unlocked until the system is shut down.
Because it is possible for the system to contain two or more CD-ROM devices, all containing El Torito-bootable CDs, the driver must mount and provide access to any volume it detects. The driver has no way of knowing which volume the OS booted from, so it sets up Physical Device Objects (PDOs) and services requests for all of them. Unfortunately, this is not a supported configuration, as the device objects are not set up properly. One of the devices will be assigned an Advanced RISC Computing (ARC) name while the other(s) will not. Such a configuration works quite well, but the time or resources to analyze the situation enough to guarantee that it would work were not available. Besides that, such a configuration is relatively invalid. Why have a second, non-boot, El Torito volume when the second volume (only consisting of non-critical data) can simply be a standard ISO-9660 CD?
After the El Torito disk is enumerated and all disk stacks are fully assembled and working, it is simply a matter of the El Torito driver servicing read requests from the device.
Post-Boot Operation of the El Torito Disk
With a working device stack, the system is now set up to read from the disk. As mentioned previously, the El Torito driver maintains a disk PDO upon which disk.sys and partmgr.sys set up FDOs and filter device objects. What happens above the disk stack is of no consequence to us.
Read requests arrive in the form of small computer system interface (SCSI) commands from disk.sys. The eltorito.sys driver cracks open these SCSI requests and repackages them as standard read requests (IRPs) that it forwards to the associated CD-ROM stack. Remember that as per ISO-9660, CD-ROM sectors are 2048 bytes in length. Thus, the driver must read a superset (if not a proper subset) of the sectors requested, which of course everyone else believes are 512 bytes in length. The El Torito driver sends IRPs to the CD-ROM stack asynchronously and waits for them to complete before completing the original IRP that arrived from the disk stack. Due to the presence of the additional device stack and the slow speed of CD-ROM devices, performance is rather poor.
If the El Torito driver were to receive a write request, it fails the IRP, setting appropriate error status in the SCSI request block. Amazingly enough, the system tolerates this to the point of the lazy write mechanism eventually failing. This will result in a deluge of errors as soon as the user logs on and an eventual forced shutdown of the system. However, eltorito.sys should never receive a write request, so the embedded developer should never encounter such behavior.
Another driver, ewf.sys (the Enhanced Write Filter), will intercept all write requests before they make it to the El Torito driver and store data in a random access memory (RAM-based) overlay for future reference. Thus, the El Torito driver services sector reads only until the sector is written to. From that point forward, all reads are serviced by Enhanced Write Filter (EWF). In fact, as this happens, system performance visibly increases. Unfortunately, the memory manager sets a hard-coded 256 MB limit to the amount of non-paged pool that can be allocated at any time. Thus, if the boot volume is too large and must service too many write requests, the system eventually runs out of non-paged pool and will fail.
The HD2ISO.EXE Utility
Currently shipping with Windows XP Embedded is a utility called HD2ISO. It is a small console-based menu application designed to read one or more partitions from a hard disk and package them as the "boot volume" in an ISO-9660 image file. The resulting .ISO file (named osboot.iso by default) can be burned directly to CD by any commercially available burning software. The size of the resulting .ISO file depends on the size of the source partition(s) contained within. The size will be approximately the size of the source partition(s) plus about 46 kilobytes (KB) of overhead.
To spare the reader the expense of studying ISO-9660 and El Torito, figure 1 shows the basic structure of the resulting image file.
Figure 1. Structure of an ISO-9660 / El Torito Image File As Produced by HD2ISO.EXE
The structure of the image is static due to the fact that HD2ISO does not support the inclusion of files within the ISO-9660 volume structure nor does it support supplementary volumes (such as a Joliet descriptor) of any type.
HD2ISO was originally written as an in-house development tool because producing a bootable, type 4-emulated CD using commercial software is not a simple task. Due to problems with the burning software, various issues were encountered with the resulting ISO images, including duplicate master boot records within the boot volume extent, improper positioning of the master boot record and/or boot sector(s), and an altogether lack of a master boot record at all.
HD2ISO supports the inclusion of multiple partitions in the boot volume, but restricts the user to choosing exactly one bootable partition from the source disk. All included partitions must reside on the same source disk. After the user has provided all necessary input, the utility calculates the size of the image file to be built and raises an error if it exceeds the proposed size of the destination CD media (either 650 or 700 MB). The utility does not, however, restrict the user from selecting a bootable non-FAT16 partition to be included as the boot partition; although all BIOSes tested thus far require the boot partition on the CD to be type 0×06 (BIGDOS/FAT-16). Furthermore, it allows the user to select the second, third or fourth partition on the disk to be the first, bootable partition in the destination image. This will not function due to the disk geometry and BIOS issues described earlier in this document. It appears that the geometry calculations for such an operation are not working as they should be. No effort will be made to correct this issue and it has been well documented in the System Design Guide that the user must set up the source hard disk such that the first partition is the boot partition and is of type 0×06.
The user may create ISO images for either 74-minute (650 MB) or 80-minute (700 MB) CD media. HD2ISO defaults to a 650 MB restriction, but this setting can be changed under the Advanced Options submenu of the Create ISO Image menu. Choosing 80-minute media only changes the size restriction of the resulting International Organization for Standardization (ISO) image file and has no other bearing.
By default, HD2ISO changes the disk signature in the Master Boot Record contained in the boot volume extent of the ISO image to 0×45 0×4C 0×54 0×4F ("ELTO") from whatever it was previously in order to guarantee uniqueness. If the disk signature is copied from the source hard disk instead of being modified as described, the OS could not determine which disk device is which, because the operating system uses disk signatures, partition offsets, and partition lengths to uniquely identify each disk and partition in the system. Furthermore, it is necessary to establish a well-defined signature so that the final system preparation tool (ETPREP.EXE) can appropriately reconfigure drive letters. Should the user wish to override the default signature, he or she can do so under the Advanced Options submenu, but is cautioned that he or she must also change the default in the dynamic HTML (DHTML) configuration in the Enhanced Write Filter component in Target Designer to the same signature. This allowance was originally provided to allow for the simultaneous presence of multiple El Torito volumes in the embedded device, but as explained earlier, that configuration is somewhat invalid.
The user can also change the default volume title in the primary volume descriptor in the Advanced Options submenu to any string of 32 characters or less. This produces only a cosmetic effect by changing the string displayed next to the CD-ROM drive in My Computer and has no bearing on functionality.
HD2ISO also allows the user to specify a binary file whose contents will be copied to the System Data Area of the image (see figure 1). The type of or use for this data is not defined, but engineers typically use it to store proprietary information for their specific BIOSes, such as security checksums. The file must be less than 32 KB in size and will be copied starting at offset 0 of the image file. Thus, if the user wishes to copy the data into sector 2, for instance, 4096 bytes of padding must be included in the binary file. This feature can be accessed under the Advanced Options submenu.
It is conceivable and common that the user may be booting to the second, third or fourth partition of the source hard disk, leaving the first partition marked as non-bootable. Because the user must specify the first partition as the boot partition in the image to maintain functionality, the user may override this flag under the "Advanced Options" submenu. This is the only situation in which the user should exercise this functionality.
Creating an El Torito "Master" CD
The process of creating a bootable CD that contains a fully configured operating system is quite complex. There are many small details that can cause problems if not properly attended to. The Troubleshooting section of this document will address the commonly encountered issues.
It is important to pay close attention to the provided documentation throughout the entire process of setting up for a master CD. A step-by-step set of instructions can be located in the System Design Guide and will not be repeated here because this document is designed to supplement that information.
First, the hard drive in the device must be configured with a primary FAT-16 (BIGDOS) partition of 650 MB or less (700 MB if 80-minute CD media is to be used) as the first partition on the drive. A second partition should be created to harbor a "safe build" of Windows 2000 or Windows XP. Most importantly, at least 4 KB must be left unallocated on the drive so that an EWF configuration partition can be placed there during First Boot Agent (FBA). The user may opt to forego the second partition and the safe build altogether, but then must make arrangements to transport the drive or its contents to and from another computer.
After the drive is set up, an embedded image should be produced by using Target Designer. The EWF, EWF NTLDR, and El Torito CD components, and the file allocation table (FAT) file system component must be included in the target image. If you are planning to override the default disk signature used in HD2ISO.EXE and the DHTML configuration script for the EWF component, one should be chosen now and written down for future reference. Any DWORD is acceptable, as long as it does not match the signature of any other disk in the system.
When the embedded image is created and placed on the target partition, HD2ISO should be run from the safe build to produce an ISO file. The HD2ISO should not be run on the current system partition under any circumstances. The produced ISO file should then be burned to CD. This CD will eventually be discarded, as the data in the volume is a pre-FBA image. It is created such that the eltorito.sys driver can detect and enumerate the volume for the first time. This allows a full disk stack to be installed on top of the device, the volume to be mounted and assigned a drive letter and all pertinent data to be stored in the registry during FBA.
The CD produced should then be inserted in the CD-ROM drive of the target device, but you must boot from the hard drive. FBA will then configure the system and create an EWF configuration partition. If there is not enough unallocated space on the drive for such a partition, this step will fail silently and problems will arise in subsequent steps. The FBA log should be inspected to verify successful EWF configuration. The EWF partition is created such that when the system is next booted, EWF will inspect the partition to find that it is disabled. It must remain disabled until you have completed all necessary modifications to the image and have run the ETPREP utility.
After FBA has completed and the embedded image can be booted to the desktop, any final modifications to the image should be completed. The next step is to run the ETPREP utility. When this tool is run, no other steps can be performed while booted into the embedded image and the system must be immediately rebooted. It is extremely important to note that after ETPREP is run, the embedded partition will no longer boot.
The ETPREP utility serves two purposes:
•To delete the EWF partition. Deleting this partition will cause EWF to enable itself at the next boot. When EWF loads and finds that it has no configuration partition, it will look in the registry under HKLM\System\CurrentControlSet\Services\EWF\Parameters to determine which volume it is to protect.
•To swap the drive letters of the El Torito disk device and the original source partition. The drive letters for the original C: drive (presumably) and the newer El Torito disk must be exchanged for the system to boot through WinLogon due to the fact that the system registry and other configuration mechanisms quite often have hard-coded references to drive letters. For example, the HKLM\Software\Microsoft\Windows NT\CurrentVersion\WinLogon registry key contains a value named "Userinit", this will have a hard-coded reference to "C:\WINDOWS\system32\userinit.exe" (or something similar). Under XPe, this value is generally set to "C:\WINDOWS\system32\winlogon.exe". If drive letters are not swapped, and even though the operating system knows that it is booting from a drive other than C:—winlogon will attempt to run the Userinit program from the C: drive, which may or may not exist at this point, possibly causing the session manager to terminate its own process and thus bugcheck the system.
After ETPREP has been run, the system must be immediately rebooted to the safe build. At this time, the user may make any final modifications to the boot.ini file and the final El Torito master .ISO can be produced and burned onto CD.
Common Support Issues by Symptom
HD2ISO Issues
•Message "Failed to create file mapping. Error 112." appears when the user chooses to create the .ISO image. This is caused by a low disk space condition. To resolve, the user should select a different drive as the .ISO file destination or free up disk space on the selected destination drive. There should be at least as much free disk space on the target as the combined size of all partitions being packaged into the image file.
•When attempting to boot from the El Torito CD, message "Invalid partition table" appears. Most likely, the user attempted to package a partition that was not the first partition on the source hard disk as the El Torito boot partition. There seems to be a flaw in the way that HD2ISO performs disk geometry recalculations when shifting partitions around. This issue will not affect secondary partitions on the El Torito CD. To remedy this problem, the user must repartition the hard disk such that the first partition on the hard disk will be packaged as the El Torito boot volume.
Issues with Post-FBA El Torito Operation
•User experiences a Bugcheck 0x0000007B, sub-status 0xC0000034 (OBJECT_NOT_FOUND) when attempting to boot from the El Torito CD. If attached to the debugger, nt!IopMarkBootPartition() is at the top of the stack. This can be caused by two conditions:
•Most commonly, the CD-ROM stack is not set up properly, causing eltorito.sys to not receive notification of any CD-ROM devices in time. Thus, eltorito cannot enumerate a disk PDO for the associated device and the OS has no boot disk to read/write from/to. In general, this is because all CD-ROM filter drivers are not configured as Start 0x0 (BOOT_INIT). Check the HKLM\System\CurrentControlSet\Services\CDROM key for the value called "Start". This value must be 0×0. The same applies for the REDBOOK and IMAPI services. If any of them are set to Start = 0×1, the CD-ROM stack will not be present early enough to boot from CD.
•One instance has been diagnosed in which the system BIOS does not appropriately expose an emulated INT-13 device to the OS. It is likely that such problems may be relatively common. To quickly diagnose this problem, put the system on the debugger and check the loaded drivers list at the time of the bugcheck (!drivers). If CDROM.SYS, REDBOOK.SYS, and IMAPI.SYS are all loaded, check the \ArcName directory in the global object namespace (!object \ArcName). If the directory is empty, "multi(0)disk(0)rdisk(0)" is not present, or there are fewer "rdisks" reported than the number of hard disks present in the system plus one (the El Torito disk device should appear exactly like a hard disk), the system BIOS has not correctly exposed the INT-13 device such that it does not appear in the loader block. Upgrade the BIOS to the newest version and if symptoms persist, contact the BIOS vendor for support. If the drivers mentioned previously are not all loaded, see the previous bulleted item.
•At the time of logon, the system displays message boxes indicating "Delayed write failed" and/or "The operating system could not store configuration data . . . ". After dismissing the message boxes, the system reboots itself. This occurs when the enhanced write filter is not properly configured or working. Most commonly, this is due to a problem stemming from when the user was first setting up the device. It is common for users to neglect to leave at least 4 KB of unpartitioned space on the hard disk so that an EWF partition can be created. If this is the case, EWF will not be properly configured to protect the volume. An error will have been reported in the FBA log, but such an error is commonly overlooked. The user should repartition the hard disk and go through the entire process again to remedy this problem.
•Random bugcheck occurs after prolonged or strenuous system use. Because CD-ROM drives are not generally designed for strenuous random access, if the drive is stressed for too long, it may stop responding to ATAPI requests and time out. In this case, the IDE miniport will conduct a retry algorithm and if it is unsuccessful, the device is declared "dead" and the OS will essentially consider it "removed" from the system. This causes the system volume to disappear and will manifest a variety of problems. It is unlikely that any user will actually experience this issue as the device must be stressed well beyond normal usage (we have only seen this in-house after 12 to 24 hours of extreme input/output [I/O] stress). However, it is recommended that the customer select a high-quality model of CD-ROM for their embedded device if it is intended to boot with El Torito.
General El Torito Troubleshooting
If there is an issue outside of those described above, it is most likely not directly related to El Torito. Standard diagnostic logic should be exercised with discretion. However, here are some tips:
•Burn the final master CD again at single speed. It is somewhat common for media to be defective or minor errors to occur while burning.
•Make sure that the El Torito volume on the hard disk boots without issues (before ETPREP.EXE is run). If it will not boot properly from the hard disk, it certainly will not boot properly from CD.
•As always, ensure that the system is running on the newest released BIOS.
•Try changing CD-ROM drives. An even slightly defective drive can cause erratic behavior and significant performance issues.
Constraints, Limitations, and Architectural Incompatibilities
Constraints and Limitations
•The operating system currently has a hard-coded 256 MB limit for non-paged pool allocations. Because of this, if more than 256 MB (minus the overhead of other non-paged pool allocations) of data is "written to" on the EWF-protected El Torito volume, the system will bugcheck. With the cost of RAM rapidly decreasing, it is common for devices to have one or two gigabytes of memory to work with. Thus, there is no reason for such a hard-coded limitation. In fact, it cripples the operability of an El Torito situation.
•At the moment, due to the size of a standard CD-ROM, there is a 650 MB or 700 MB limit to the size of the boot volume, depending on the capacity of the media. This prevents the full version of the operating system from being booted from CD. Only a Windows XP embedded install can be booted from CD. Fortunately, a relatively full install (max-boot) does indeed generally fit.
•As stated earlier in this document, HD2ISO is not fully ISO-9660 compliant and does not include functionality to place files outside of the El Torito boot volume in standard ISO-9660 or JOLIET format. HD2ISO was originally written as an in-house test and development.
Additional Information
Additional information about Windows XP Embedded is available on MSDN.
Welcome to Windows XP Embedded
Installation Guide |
|
IP卡
狗仔卡
发表于 2003-5-19 20:20:44
收藏
支持
反对
提升卡
沉默卡
喧嚣卡
变色卡
千斤顶
显身卡
楼主