El Torito
El Torito is a specification for bootable CD-ROMs that enables computers to load an operating system from a CD-ROM by emulating a bootable floppy disk or hard disk drive.[1] Developed by Phoenix Technologies Ltd. and IBM Corporation, the "El Torito" Bootable CD-ROM Format Specification Version 1.0 was released on January 25, 1995.[1] It extends the ISO 9660 file system standard with a boot record at sector 17 and a boot catalog to support floppy emulation (1.2 MB, 1.44 MB, or 2.88 MB formats) or hard disk emulation, allowing features like multi-OS support and user-selectable boot options while preserving compatibility with non-bootable volumes.[1]Overview
Definition and Purpose
El Torito, formally known as the "Bootable CD-ROM Format Specification," is a standard developed to enable booting from optical media such as CD-ROMs, DVDs, and Blu-ray discs by extending the ISO 9660 file system. It achieves this through BIOS-level emulation of legacy devices like floppy disks or hard drives, allowing the optical media to be recognized and accessed as bootable volumes without native hardware support for direct booting.[2][3] The primary purpose of El Torito is to address the limitations of early CD-ROM drives, which lacked the ability to boot operating systems directly, by simulating familiar boot media to load initial program loaders, kernels, or full operating systems. This emulation enables self-configuring CDs that can support multiple operating systems, user selection of boot options, and even copy protection mechanisms, all while maintaining compatibility with standard BIOS interrupt functions.[2] Key benefits include providing a standardized approach for interoperability across diverse PC BIOS implementations in the pre-UEFI era, avoiding resource conflicts and driver dependencies that plagued DOS-based CD access, and facilitating efficient initial program loading (IPL) for various computing environments. The specification's name derives from the El Torito Mexican restaurant chain in Irvine, California, where it was conceived as a codename by developers Curtis Stevens of Phoenix Technologies and Stan Merkin of IBM.[2][3]Relation to ISO 9660
El Torito serves as a non-intrusive extension to the ISO 9660 filesystem standard, enabling bootable CD-ROMs by incorporating boot metadata in designated locations without modifying the core data structures or file organization of ISO 9660.[2] Specifically, it utilizes reserved sectors following the primary volume descriptor to embed this functionality, such as placing a Boot Record volume descriptor at logical sector 17 (LBA 0x11), which points to the Boot Catalog without affecting the integrity of the filesystem's directory records or file data.[2] This design ensures that the boot elements, including the Boot Catalog and associated boot images, can be stored either as hidden files within the ISO 9660 directory structure or in raw sectors outside the visible filesystem, thereby maintaining full compliance with ISO 9660 while adding boot capabilities.[4] To preserve backward compatibility, El Torito leverages the ISO 9660 System Area—logical sectors 0 through 15 (LBAs 0x00 to 0x0F)—which remains unrecorded and reserved for manufacturer-specific use, alongside the post-Volume Descriptor Area for placing the Boot Record immediately after the Primary Volume Descriptor at logical sector 16 (LBA 0x10).[2] This placement avoids any overlap with the filesystem's data areas, allowing non-bootable CD readers and standard ISO 9660-compliant software to access the media as a regular data disc without detecting or requiring the boot extensions.[4] Boot images are typically integrated as ordinary files in the ISO 9660 filesystem (e.g., marked with hidden attributes in the root directory), ensuring that the boot process does not disrupt normal file reading operations.[2] ISO 9660 compliance in El Torito implementations mandates the presence of a standard Primary Volume Descriptor (PVD) at logical sector 16, which uses the application identifier "CD001" to confirm adherence to the base standard, while the subsequent Boot Record volume descriptor (of type 0x00) at sector 17 serves as the explicit boot indicator by including El Torito-specific identifiers like "EL TORITO SPECIFICATION" in its boot system use field.[2] This structured integration guarantees that bootable media remains fully interoperable with legacy ISO 9660 devices, as the boot metadata is confined to predefined, non-conflicting locations defined in ISO 9660 section 8.2 for volume descriptors.[2]Technical Specification
Volume Descriptor
The El Torito volume descriptor, also known as the boot record, is a specialized structure within an ISO 9660 file system that indicates the presence of bootable content on a CD-ROM. It serves as the initial entry point for BIOS firmware to identify and locate the boot catalog, enabling the boot process while remaining transparent to standard ISO 9660 readers that do not support booting. This descriptor must be placed at a fixed location to ensure compatibility with the ISO 9660 volume structure.[2] The volume descriptor is located at logical sector 17 (decimal), immediately following the Primary Volume Descriptor (PVD) at sector 16 in the system's volume recognition area. This positioning integrates it seamlessly with the ISO 9660 standard, where it functions as a type 0 volume descriptor that non-booting implementations can safely ignore. The structure occupies a full 2048-byte logical sector, but the critical fields are confined to the initial bytes, with the remainder reserved as unused.[2] The descriptor begins with a boot record indicator byte set to 0x00, distinguishing it as the El Torito boot record type. This is followed by the 5-byte ISO 9660 identifier "CD001" and a version byte of 1, adhering to the general format of ISO volume descriptors. The boot system identifier field, spanning 32 bytes, must contain the ASCII string "EL TORITO SPECIFICATION" padded with null bytes, signaling compliance with the El Torito specification. Immediately after are 20 unused bytes set to zero, and a 4-byte little-endian unsigned integer providing the absolute sector address of the boot catalog. All subsequent bytes in the sector are reserved and must be zero. The data length field typical of other volume descriptors is unused in this context.[2] For clarity, the key fields of the volume descriptor are outlined below:| Offset (hex) | Size (bytes) | Field Name | Description/Value |
|---|---|---|---|
| 00 | 1 | Boot Record Indicator | 0x00 (specifies boot record type) |
| 01-05 | 5 | ISO 9660 Identifier | "CD001" (ASCII) |
| 06 | 1 | Version | 0x01 |
| 07-26 | 32 | Boot System Identifier | "EL TORITO SPECIFICATION" (ASCII, padded with 0x00) |
| 27-3A | 20 | Unused | 0x00 (all bytes) |
| 3B-3E | 4 | Boot Catalog Pointer | Little-endian unsigned integer (sector number) |
| 3F-7FF | 2041 | Unused | 0x00 (all bytes) |
Boot Catalog Structure
The Boot Catalog in the El Torito specification serves as a directory of bootable images on an ISO 9660 volume, with its location specified by the Boot Record Volume Descriptor typically found at logical sector 17. This catalog is commonly placed in the post-Volume Descriptor Set Area (post-VDSA) and has a fixed size of 2048 bytes, equivalent to one sector, though the specification allows for multiple sectors if needed.[2] The structure begins with a validation entry of 32 bytes, which confirms the presence and integrity of the catalog. This entry contains a header ID of 0x01, a platform ID (e.g., 0x00 for x86), two reserved bytes set to 0x00, a 24-byte ID string fixed as "EL TORITO SPECIFICATION", a 2-byte checksum computed such that the sum of all 16-bit words (bytes 0-31) equals 0x0000, and key bytes 0x55 followed by 0xAA at offsets 30-31.[2] The checksum ensures the entry's validity during BIOS parsing.[2] Immediately following is the initial/default entry, also 32 bytes, which defines the primary boot image for the platform. It includes a boot indicator (0x88 for bootable), a media type byte (e.g., 0x00 for no emulation), a 2-byte load segment value (0x0000 indicating the default 07C0h), a system type byte, a reserved byte, a 2-byte sector count for the image, a 4-byte logical block address (LBA) pointing to the boot image start, and 20 reserved bytes set to 0x00.[2] This entry enables the BIOS to load and emulate the default image without additional selection.[2] The remaining space in the catalog (starting after byte 64) accommodates section entries for advanced configurations, allowing multiple boot options grouped by platform. Each section begins with a 32-byte section header specifying the platform ID, the number of entries (up to 8), and a section ID string, followed by up to 8 section entries of 32 bytes each.[2] Individual section entries follow the initial entry's format but include selection criteria in the reserved space: boot indicator (0x88 for bootable), media type, load segment, system type, reserved byte, sector count, LBA, selection criteria type byte (0x00 none, 0x01 language/version, etc.), and 19 bytes vendor-specific criteria.[2] The boot indicator uses 0x88 to mark the bootable default option within the section, while 0x00 indicates a non-bootable or continuation entry to chain additional images.[2] Up to 8 such sections can be defined, supporting diverse boot environments like x86, PowerPC, or Macintosh.[2]| Component | Size (bytes) | Key Purpose |
|---|---|---|
| Validation Entry | 32 | Validates catalog and specifies platform |
| Initial/Default Entry | 32 | Defines primary boot image details |
| Section Header | 32 | Groups up to 8 section entries by platform |
| Section Entry | 32 | Describes alternative boot images with selection criteria |
Emulation Modes and Boot Entries
El Torito defines several emulation modes to allow a CD-ROM to simulate different types of bootable media during the BIOS boot process. These modes include floppy disk emulation for standard sizes, hard disk emulation for larger images, and no-emulation mode for direct sector loading. The boot media type is specified in the boot entry using a single byte value in bits 0-3: 0x00 for no emulation, 0x01 for 1.2 MB floppy, 0x02 for 1.44 MB floppy, 0x03 for 2.88 MB floppy, and 0x04 for hard disk emulation.[2] In floppy emulation modes, the BIOS presents the CD-ROM sectors as a virtual floppy disk with predefined geometry to the boot loader via INT 13h calls. For the 1.44 MB mode, this geometry consists of 80 cylinders, 2 heads, and 18 sectors per track, totaling 2,880 logical 512-byte sectors. Similarly, the 1.2 MB mode uses 80 cylinders, 2 heads, and 15 sectors per track (2,400 sectors), while the 2.88 MB mode employs 80 cylinders, 2 heads, and 36 sectors per track (5,760 sectors). Hard disk emulation (0x04) treats the CD-ROM as a virtual hard drive starting at BIOS drive 80h, with geometry derived from the partition table in the first sector of the boot image; this mode supports images up to the BIOS's addressing limits, typically around 4 GB in practice due to CHS constraints.[2][4] No-emulation mode (0x00) bypasses disk emulation entirely, loading raw 512-byte virtual sectors directly into memory at a specified segment without presenting a virtual drive to the BIOS. This mode is useful for loading small bootloaders or EFI images, with the data loaded to a 16-bit segment address (default 07C0h if unspecified, corresponding to physical address 00007C00h). Unlike emulation modes, no virtual geometry is involved; the BIOS simply transfers the bytes as a linear block.[2][4] Each boot entry in the catalog describes the parameters for loading a specific boot image. The key fields include the boot media type (as noted above), a 16-bit load segment value (used primarily in no-emulation mode), an 8-bit system type (0x00 for x86 BIOS compatibility), a 16-bit sector count indicating the number of 512-byte virtual sectors to load (e.g., 2,880 for a full 1.44 MB floppy image or 4 for a typical no-emulation CD sector equivalent), and a 32-bit logical block address (LBA) specifying the starting location of the boot image on the CD-ROM as raw consecutive sectors. For floppy and hard disk modes, the sector count represents the full size of the emulated image; in no-emulation mode, it defines the exact amount of data to transfer.[2][4] Boot images consist of raw sectors beginning at the specified LBA; tools may place ISO 9660 files contiguously in sectors for booting, but the catalog references only the LBA, not file paths. The maximum load size across all modes is limited to 65,535 sectors (0xFFFF) in the sector count field, equating to approximately 32 MB of 512-byte sectors, though practical limits may vary by BIOS implementation.[2]Boot Process
BIOS Detection and Loading
The BIOS firmware initiates the boot process from an El Torito-compliant CD-ROM by scanning attached CD-ROM drives in the configured boot order during the Power-On Self-Test (POST) phase, provided CD-ROM booting is enabled in the system setup.[2] If a CD-ROM is present and detected, the BIOS invokes interrupt 19h (INT 19h) to begin the operating system load sequence, treating the CD-ROM as a potential boot device.[2] Upon detection, the BIOS reads logical sector 17 (decimal) of the CD-ROM, which contains the Boot Record Volume Descriptor for an ISO 9660-compliant filesystem.[2] This descriptor has type 00h at byte 0, bytes 1-5 as "CD001", version 01h at byte 6, and bytes 7-30 containing the identifier "EL TORITO SPECIFICATION" followed by a zero; bytes 31-70 are unused (set to 00h), and bytes 71-74 provide the little-endian Logical Block Address (LBA) of the Boot Catalog. If these criteria are not met, the BIOS treats the CD as non-bootable and proceeds to the next device in the boot order.[2] The BIOS seeks to that Boot Catalog location and loads it into memory.[2] The Boot Catalog begins with a 32-byte Validation Entry, which the BIOS parses to confirm compatibility.[2] This entry has byte 0 set to 01h, Platform ID at byte 1 (00h for x86 BIOS), bytes 2-3 reserved (0000h), bytes 4-27 as manufacturer string padded with 00h, a 16-bit checksum at bytes 28-29 (such that the sum of all 16 words in the entry is 00h), and key bytes 55h followed by AAh at bytes 30-31.[2] If the validation succeeds, the BIOS proceeds to the Initial/Default Entry immediately following the Validation Entry (or the first suitable entry after any Section Header Entries), which has boot indicator 88h at byte 0 (bootable), boot media type at byte 1 (e.g., 00h for no emulation, 01h for 1.2 MB floppy, 02h for 1.44 MB floppy, 03h for 2.88 MB floppy, 04h for hard disk), Load Segment at bytes 2-3 (defaulting to 07C0h if 0000h), Sector Count at bytes 6-7 (number of virtual 512-byte sectors to load), and the starting LBA of the boot image as Load RBA (little-endian DWORD at bytes 8-11).[2] To load the boot image, the BIOS uses extensions to INT 13h (functions 4Ah through 4Dh) to read the specified Sector Count of virtual 512-byte sectors from the Load RBA into memory starting at the Load Segment address shifted left by 4 bits (i.e., segment * 16), mapping from 2048-byte CD-ROM sectors as needed.[2] For no-emulation mode, the BIOS performs a direct load and then jumps to the entry point at Load Segment:0000h to execute the loaded code.[2] In emulation modes (e.g., 1.44MB floppy or hard disk), the BIOS simulates a legacy disk device by remapping drive numbers (e.g., CD-ROM appears as drive 00h for floppy emulation) and invoking standard INT 13h functions for subsequent accesses during boot.[2] Error handling ensures robustness: if the Boot Record indicator is invalid, the Validation Entry checksum fails, or no compatible Initial Entry is found, the BIOS aborts the CD-ROM boot and falls back to the next device in the sequence; additionally, invalid data detection during loading may prompt the user to disable CD-ROM booting via setup options.[2] This process relies on the CD-ROM's ATAPI or SCSI interface for initial sector reads, with the BIOS querying drive geometry via INT 13h function 08h if needed for emulation setup.[2]Image Emulation Details
In the El Torito boot process, once the BIOS has loaded the initial boot image from the CD-ROM, it enters image emulation mode to present the bootable content as a virtual disk device, allowing the bootloader to interact with it using standard BIOS interrupt services without direct awareness of the underlying optical medium.[2] This emulation translates logical block addresses (LBAs) on the CD into accesses on the emulated device, primarily through INT 13h calls, where CD sectors of 2048 bytes are mapped to virtual 512-byte sectors by packing four virtual sectors per CD sector.[2] The emulated device is registered in the BIOS device list as unit 0x00 for floppy emulation or 0x80 for hard disk emulation, shifting existing physical devices accordingly to maintain compatibility with legacy bootloaders.[2] Floppy emulation configures the CD boot image to mimic a standard 3.5-inch floppy disk drive, supporting common geometries such as 1.44 MB (80 cylinders × 2 heads × 18 sectors, totaling 2880 sectors), 1.2 MB (80 × 2 × 15 sectors), or 2.88 MB (80 × 2 × 36 sectors).[2] The BIOS maps the boot catalog's specified load RBA (relative byte address) to the virtual floppy's sector 0, enabling the bootloader to load the boot sector and perform subsequent reads via INT 13h functions (e.g., function 02h for reading sectors) as if accessing a physical floppy, with CHS addressing translated internally to CD LBAs.[2] Upon activation, the emulated floppy assumes drive number 00, reassigning the original floppy A: drive to 01 and rendering any original B: drive inaccessible during the boot session.[2] This mode is ideal for simple bootloaders designed for floppy media, providing seamless compatibility without requiring CD-specific commands. Hard disk emulation treats the boot image as a single-partition Master Boot Record (MBR)-formatted hard drive, limited to a maximum of 65,535 sectors (approximately 32 MB) due to 16-bit LBA addressing in INT 13h.[2] The BIOS loads the MBR from the boot image's first sector and presents the device as drive 80 (the first hard disk), incrementing existing hard drives to 81 and higher; the partition table in the MBR defines the active boot partition, allowing the bootloader to access it via INT 13h for reading the partition bootstrap code and subsequent sectors using CHS or extended LBA translations.[2] This setup supports more complex boot environments, such as those expecting a partitioned disk, but restricts the emulation to read-only operations, with the fixed image size determined by the boot entry's sector count.[2] In no-emulation mode, the BIOS bypasses disk geometry translation entirely, directly loading the specified number of virtual 512-byte sectors from the CD's boot image starting at the load RBA into memory at segment 07C0h (or a boot entry-defined alternative) without registering an emulated device in the BIOS drive list.[2] This raw sector transfer supports up to 65,535 sectors and leaves physical drive numbering unchanged, requiring the loaded bootloader to implement its own CD-ROM access—typically via direct SCSI or ATAPI commands over INT 13h extensions or other interfaces—for any further reads.[2] Like the other modes, no-emulation enforces read-only access and a fixed boot image size, making it suitable for advanced bootloaders capable of native optical media handling.[2] Across all emulation modes, the BIOS provides no write support to the virtual device, ensuring data integrity for the read-only CD medium, and the emulated size remains static based on the boot catalog entry, preventing dynamic resizing or overflow handling.[2] These mechanisms enable broad compatibility with existing x86 boot code while abstracting the CD-ROM's sectoring differences.[2]History and Development
Origins and Initial Release
The El Torito specification emerged as a collaborative effort between Phoenix Technologies, a leading BIOS developer, and IBM, aimed at enabling PC booting from CD-ROM media in an era of rapidly expanding optical storage use. The name "El Torito" was inspired by the El Torito restaurant in Irvine, California, where the engineers met during the design process in early 1994.[3] This joint initiative addressed the limitations of mid-1990s personal computers, where CD-ROM drives were increasingly common for data distribution but lacked native hardware support for direct booting, necessitating software-based solutions to load operating systems and applications from such media.[3] The specification was primarily authored by Curtis E. Stevens of Phoenix Technologies and Stan Merkin of IBM, who drew on their expertise in BIOS extensions and system interoperability to define a standardized format compatible with existing ISO 9660 file systems.[2] The project was first announced in November 1994 as a proposal to promote industry-wide adoption of bootable CDs, reflecting the growing demand for versatile, removable media in software distribution and system installation.[3] By early 1995, this culminated in the formal release of Version 1.0 on January 25, 1995, distributed as a freely available 20-page technical document that outlined the necessary structures for emulation and boot processes without requiring modifications to standard PC hardware.[2] The document's open distribution strategy was intended to encourage broad implementation by hardware and software vendors, fostering compatibility across diverse PC environments.[2] Key motivations included facilitating efficient OS deployment on CDs, which were becoming preferred over floppy disks due to their higher capacity, while supporting features like multi-OS selection and self-configuring drivers to simplify user setup.[2] This approach not only mitigated the absence of built-in CD-ROM boot capabilities in BIOS firmware but also enabled enhanced security measures, such as copy protection for distributed software, by leveraging the CD's read-only nature.[2] The specification's design emphasized minimal overhead, ensuring it integrated seamlessly with conventional PC architectures prevalent at the time.[2]Adoption and Revisions
Following its release in January 1995, the El Torito specification saw rapid integration into PC BIOS firmware by major vendors, including Phoenix Technologies (a co-author) and others such as Award and AMI, enabling widespread support for booting from CD-ROMs by mid-1995.[2][5] This facilitated the creation of bootable installation media, notably for Microsoft Windows 95 OEM editions released later that year, which leveraged El Torito's floppy emulation mode to load setup files directly from CD without requiring separate boot floppies.[5] Early Linux distributions, such as those using mkisofs tools with El Torito patches, also adopted the standard around the same time to produce bootable CDs for installation on x86 systems.[6] The core El Torito specification has remained at version 1.0 since its initial publication, with no official revisions or updates issued by its developers, Phoenix Technologies and IBM.[2] However, minor extensions emerged through related standards, particularly the BIOS Boot Specification (BBS) version 1.01 released in January 1996 by Compaq, Phoenix, and Intel, which introduced configurable boot priorities and IPL (Initial Program Load) device support while referencing and building upon El Torito for CD-ROM handling without altering its fundamental structure.[7] By 2000, El Torito had become a de facto standard in optical drive firmware and BIOS implementations, influencing extensions to DVD media under standards like ECMA-167 for volume structures, allowing bootable DVDs to follow similar emulation protocols.[8][9] Its prominence declined with the introduction of the Unified Extensible Firmware Interface (UEFI) in 2005, which favored native EFI boot mechanisms over legacy BIOS emulation, though El Torito persists in hybrid ISO images that include both BIOS-compatible boot catalogs and EFI entries to support older hardware.[4] This dual-mode approach ensures compatibility for bootable optical media in mixed environments until the broader shift to USB-based booting.Implementations
Software Tools for Creation
The primary open-source tools for creating El Torito-compliant bootable ISO images are derived from the cdrtools suite, including mkisofs (now largely superseded by genisoimage in cdrkit) and the more advanced xorriso from GNU libburnia. These command-line utilities embed a boot image—such as a floppy disk image (e.g., floppy.img) or a hard disk image (e.g., eltorito.iso)—into the ISO 9660 filesystem during creation, while generating the required boot catalog that adheres to the El Torito specification.[10][11] To specify the boot image location, mkisofs and genisoimage use the-b option followed by the ISO-relative path to the boot file (e.g., -b /boot.img), which indicates the logical block address (LBA) for loading. The -c option sets the path for the boot catalog file (e.g., -c boot.cat), which the tool populates with validation and initial/default entries. For no-emulation mode, suitable for raw sector loading in bootloaders like ISOLINUX, the -no-emul-boot flag is applied, often paired with -boot-load-size to define the number of 512-byte sectors to load (e.g., 4 sectors for typical BIOS setups). xorriso emulates these options via its -as mkisofs mode for compatibility but natively uses -b for BIOS boot images and -e for EFI, supporting up to 32 alternate boot entries with -eltorito-alt-boot for multi-platform images.[10][12][13]
xorriso extends El Torito functionality beyond CDs to DVDs and Blu-ray discs, maintaining ISO 9660 compatibility while enabling multiple boot catalogs for complex scenarios like hybrid media. This makes it particularly useful for Linux distributions; for instance, Ubuntu employs xorriso to produce hybrid ISOs that support both optical disc booting via El Torito and USB booting through isohybrid extensions.[12][14]
Graphical and alternative tools include ImgBurn for Windows, which provides a user interface in its Advanced tab to configure El Torito parameters like boot image selection, emulation type, and load segment/size, simplifying creation without command-line expertise. PowerISO similarly supports adding boot information via its "Action > Boot > Add Boot Information" menu, loading a bootable image file and embedding it into the ISO while handling catalog generation. For raw image preparation, the Unix dd command copies disk or partition data (e.g., dd if=/dev/fd0 of=floppy.img) to create the initial boot sector file before integration. Open-source multiboot setups often incorporate GRUB by including its cdboot.img or EFI images as the El Torito boot file, with tools like xorriso or genisoimage calculating the catalog to chainload GRUB for subsequent OS selection.[15][16][17]