<HTML> <HEAD><TITLE>Multiboot Standard</TITLE></HEAD> <BODY> <CENTER><H1>Multiboot Standard</H1></CENTER><CENTER><H3>Version 0.6</H3></CENTER> <HR> <H2>Contents</H2> <UL><LI> <A HREF="#motivation">Motivation</A><LI> <A HREF="#terminology">Terminology</A><LI> <A HREF="#scope">Scope and Requirements</A><LI> <A HREF="#details">Details</A><LI> <A HREF="#author">Authors</A><LI> <B>NOTE: The following items are not part of the standards document,but are included for prospective OS and bootloader writers.</B><LI> <A HREF="#notes">Notes on PCs</A><LI> <A HREF="#example_os">Example OS Code</A><LI> <A HREF="#example_boot">Example Bootloader Code</A></UL> <HR> <H2><A NAME="motivation">Motivation</A></H2> Every OS ever created tends to have its own boot loader.  Installing a newOS on a machine generally involves installing a whole new set of bootmechanisms, each with completely different install-time and boot-time userinterfaces.   Getting multiple operating systems to coexist reliably on onemachine through typical "chaining" mechanisms can be a nightmare.  There islittle or no choice of boot loaders for a particular operating system - ifthe one that comes with the OS doesn't do exactly what you want, or doesn'twork on your machine, you're screwed.<P> While we may not be able to fix this problem in existing commercialoperating systems, it shouldn't be too difficult for a few people in thefree OS communities to put their heads together and solve this problem forthe popular free operating systems.  That's what this standard aims for.Basically, it specifies an interface between a boot loader and a operatingsystem, such that any complying boot loader should be able to load anycomplying operating system.  This standard does NOT specify how bootloaders should work - only how they must interface with the OS beingloaded.<P> <HR> <H2><A NAME="terminology">Terminology</A></H2> Throughout this document, the term "boot loader" means whatever program orset of programs loads the image of the final operating system to be run onthe machine.  The boot loader may itself consist of several stages, butthat is an implementation detail not relevant to this standard.  Only the"final" stage of the boot loader - the stage that eventually transferscontrol to the OS - needs to follow the rules specified in this documentin order to be "MultiBoot compliant"; earlier boot loader stages can bedesigned in whatever way is most convenient.<P> The term "OS image" is used to refer to the initial binary image that theboot loader loads into memory and transfers control to to start the OS.The OS image is typically an executable containing the OS kernel.<P> The term "boot module" refers to other auxiliary files that the boot loaderloads into memory along with the OS image, but does not interpret in anyway other than passing their locations to the OS when it is invoked.<P> <HR> <H2><A NAME="scope">Scope and Requirements</A></H2> <H3>Architectures</H3> This standard is primarily targetted at PC's, since they are the mostcommon and have the largest variety of OS's and boot loaders.  However, tothe extent that certain other architectures may need a boot standard and donot have one already, a variation of this standard, stripped of thex86-specific details, could be adopted for them as well.<P> <H3>Operating systems</H3> This standard is targetted toward free 32-bit operating systems that can befairly easily modified to support the standard without going through lots ofbureaucratic rigmarole.  The particular free OS's that this standard isbeing primarily designed for are Linux, FreeBSD, NetBSD, Mach, and VSTa.It is hoped that other emerging free OS's will adopt it from the start, andthus immediately be able to take advantage of existing boot loaders.  Itwould be nice if commercial operating system vendors eventually adoptedthis standard as well, but that's probably a pipe dream.<P> <H3>Boot sources</H3> It should be possible to write compliant boot loaders thatload the OS image from a variety of sources, including floppy disk, harddisk, and across a network.<P> Disk-based boot loaders may use a variety of techniques to find therelevant OS image and boot module data on disk, such as by interpretationof specific file systems (e.g. the BSD/Mach boot loader), usingprecalculated "block lists" (e.g. LILO), loading from a special "bootpartition" (e.g. OS/2), or even loading from within another operatingsystem (e.g. the VSTa boot code, which loads from DOS).  Similarly,network-based boot loaders could use a variety of network hardware andprotocols.<P> It is hoped that boot loaders will be created that support multiple loadingmechanisms, increasing their portability, robustness, anduser-friendliness.<P> <H3>Boot-time configuration</H3> It is often necessary for one reason or another for the user to be able toprovide some configuration information to the OS dynamically at boot time.While this standard should not dictate how this configuration informationis obtained by the boot loader, it should provide a standard means for theboot loader to pass such information to the OS.<P> <H3>Convenience to the OS</H3> OS images should be easy to generate.  Ideally, an OS image should simplybe an ordinary 32-bit executable file in whatever file format the OSnormally uses.  It should be possible to 'nm' or disassemble OS images justlike normal executables.  Specialized tools should not be needed to createOS images in a "special" file format.  If this means shifting some workfrom the OS to the boot loader, that is probably appropriate, because allthe memory consumed by the boot loader will typically be made availableagain after the boot process is created, whereas every bit of code in theOS image typically has to remain in memory forever.  The OS should not haveto worry about getting into 32-bit mode initially, because mode switchingcode generally needs to be in the boot loader anyway in order to load OSdata above the 1MB boundary, and forcing the OS to do this makes creationof OS images much more difficult.<P> Unfortunately, there is a horrendous variety of executable file formatseven among free Unix-like PC-based OS's - generally a different format foreach OS.  Most of the relevant free OS's use some variant of a.out format,but some are moving to ELF.  It is highly desirable for boot loaders not tohave to be able to interpret all the different types of executable fileformats in existence in order to load the OS image - otherwise the bootloader effectively becomes OS-specific again.<P> This standard adopts a compromise solution to this problem.MultiBoot compliant boot images always either (a) are in ELF format, or (b)contain a "magic MultiBoot header", described below, which allows the bootloader to load the image without having to understand numerous a.outvariants or other executable formats.  This magic header does not needto be at the very beginning of the executable file, so kernel images canstill conform to the local a.out format variant in addition to beingMultiBoot compliant.<P> <H3>Boot modules</H3> Many modern operating system kernels, such as those of VSTa and Mach, donot by themselves contain enough mechanism to get the system fullyoperational: they require the presence of additional software modules atboot time in order to access devices, mount file systems, etc.  While theseadditional modules could be embedded in the main OS image along with thekernel itself, and the resulting image be split apart manually by the OSwhen it receives control, it is often more flexible, more space-efficient,and more convenient to the OS and user if the boot loader can load theseadditional modules independently in the first place.<P> Thus, this standard should provide a standard method for a boot loader toindicate to the OS what auxiliary boot modules were loaded, and where theycan be found.  Boot loaders don't have to support multiple boot modules,but they are strongly encouraged to, because some OS's will be unable toboot without them.<P> <HR> <H2><A NAME="details">Details</H2> There are three main aspects of the boot-loader/OS image interface thisstandard must specify:<P> <UL><LI>The format of the OS image as seen by the boot loader.<LI>The state of the machine when the boot loader starts the OS.<LI>The format of the information passed by the boot loader to the OS.</UL> <H3>OS Image Format</H3> An OS image is generally just an ordinary 32-bit executable file in thestandard format for that particular OS, except that it may be linked at anon-default load address to avoid loading on top of the PC's I/O regionor other reserved areas, and of course it can't use shared libraries orother fancy features.  Initially, only images in a.out format aresupported; ELF support will probably later be specified in the standard.<P> Unfortunately, the exact meaning of the text, data, bss, and entry fieldsof a.out headers tends to vary widely between different executable flavors,and it is sometimes very difficult to distinguish one flavor from another(e.g. Linux ZMAGIC executables and Mach ZMAGIC executables).  Furthermore,there is no simple, reliable way of determining at what address in memorythe text segment is supposed to start.  Therefore, this standard requiresthat an additional header, known as a 'multiboot_header', appear somewherenear the beginning of the executable file.  In general it should come "asearly as possible", and is typically embedded in the beginning of the textsegment after the "real" executable header.  It _must_ be containedcompletely within the first 8192 bytes of the executable file, and must belongword (32-bit) aligned.  These rules allow the boot loader to find andsynchronize with the text segment in the a.out file without knowingbeforehand the details of the a.out variant.  The layout of the header isas follows:<P> <pre>	+-------------------+0	| magic: 0x1BADB002 |	(required)4	| flags		    |	(required)8	| checksum	    |	(required)	+-------------------+8	| header_addr	    |	(present if flags[16] is set)12	| load_addr	    |	(present if flags[16] is set)16	| load_end_addr	    |	(present if flags[16] is set)20	| bss_end_addr	    |	(present if flags[16] is set)24	| entry_addr	    |	(present if flags[16] is set)	+-------------------+</pre> All fields are in little-endian byte order, of course.  The first field isthe magic number identifying the header, which must be the hex value0x1BADB002.<P> The flags field specifies features that the OS image requests or requiresof the boot loader.  Bits 0-15 indicate requirements; if the boot loadersees any of these bits set but doesn't understand the flag or can't fulfillthe requirements it indicates for some reason, it must notify the user andfail to load the OS image.  Bits 16-31 indicate optional features; if anybits in this range are set but the boot loader doesn't understand them, itcan simply ignore them and proceed as usual.  Naturally, allas-yet-undefined bits in the flags word must be set to zero in OSimages.  This way, the flags fields serves for version control as well assimple feature selection.<P> If bit 0 in the flags word is set, then all boot modules loaded along withthe OS must be aligned on page (4KB) boundaries.  Some OS's expect to beable to map the pages containing boot modules directly into a paged addressspace during startup, and thus need the boot modules to be page-aligned.<P> If bit 1 in the flags word is set, then information on available memoryvia at least the 'mem_*' fields of the multiboot_info structure definedbelow must be included.  If the bootloader is capable of passing a memorymap (the 'mmap_*' fields) and one exists, then it must be included aswell.<P> If bit 16 in the flags word is set, then the fields at offsets 8-24 in themultiboot_header are valid, and the boot loader should use them instead ofthe fields in the actual executable header to calculate where to load theOS image.  This information does not need to be provided if the kernelimage is in ELF format, but it should be provided if the images is in a.outformat or in some other format.  Compliant boot loaders must be able toload images that either are in ELF format or contain the load addressinformation embedded in the multiboot_header; they may also directlysupport other executable formats, such as particular a.out variants, butare not required to.<P> All of the address fields enabled by flag bit 16 are physical addresses.The meaning of each is as follows:<P> <UL><LI><B>header_addr</B> -- Contains the address corresponding to thebeginning of the multiboot_header - the physical memory location at whichthe magic value is supposed to be loaded.  This field serves to "synchronize"the mapping between OS image offsets and physical memory addresses.<LI><B>load_addr</B> -- Contains the physical address of the beginningof the text segment.  The offset in the OS image file at which to startloading is defined by the offset at which the header was found, minus(header_addr - load_addr).  load_addr must be less than or equal toheader_addr.<LI><B>load_end_addr</B> -- Contains the physical address of the end of thedata segment.  (load_end_addr - load_addr) specifies how much data to load.This implies that the text and data segments must be consecutive in theOS image; this is true for existing a.out executable formats.<LI><B>bss_end_addr</B> -- Contains the physical address of the end ofthe bss segment.  The boot loader initializes this area to zero, andreserves the memory it occupies to avoid placing boot modules and otherdata relevant to the OS in that area.<LI><B>entry</B> -- The physical address to which the boot loader shouldjump in order to start running the OS.</UL> The checksum is a 32-bit unsigned value which, when added tothe other required fields, must have a 32-bit unsigned sum of zero.<P> <H3>Machine State</H3> When the boot loader invokes the 32-bit operating system,the machine must have the following state:<P> <UL><LI>CS must be a 32-bit read/execute code segment with an offset of 0and a limit of 0xffffffff.<LI>DS, ES, FS, GS, and SS must be a 32-bit read/write data segment withan offset of 0 and a limit of 0xffffffff.<LI>The address 20 line must be usable for standard linear 32-bitaddressing of memory (in standard PC hardware, it is wired to0 at bootup, forcing addresses in the 1-2 MB range to be mapped to the0-1 MB range, 3-4 is mapped to 2-3, etc.).<LI>Paging must be turned off.<LI>The processor interrupt flag must be turned off.<LI>EAX must contain the magic value 0x2BADB002; the presence of this valueindicates to the OS that it was loaded by a MultiBoot-compliant bootloader (e.g. as opposed to another type of boot loader that the OS canalso be loaded from).<LI>EBX must contain the 32-bit physical address of the multiboot_infostructure provided by the boot loader (see below).</UL> All other processor registers and flag bits are undefined.  This includes,in particular:<P> <UL><LI>ESP: the 32-bit OS must create its own stack as soon as it needs one.<LI>GDTR: Even though the segment registers are set up as described above,the GDTR may be invalid, so the OS must not load any segment registers(even just reloading the same values!) until it sets up its own GDT.<LI>IDTR: The OS must leave interrupts disabled until it sets up its own IDT.</UL> However, other machine state should be left by the boot loader in "normalworking order", i.e. as initialized by the BIOS (or DOS, if that's whatthe boot loader runs from).  In other words, the OS should be able to makeBIOS calls and such after being loaded, as long as it does not overwritethe BIOS data structures before doing so.  Also, the boot loader must leavethe PIC programmed with the normal BIOS/DOS values, even if it changed themduring the switch to 32-bit mode.<P> <H3>Boot Information Format</H3> Upon entry to the OS, the EBX register contains the physical address ofa 'multiboot_info' data structure, through which the boot loadercommunicates vital information to the OS.  The OS can use or ignore anyparts of the structure as it chooses; all information passed by the bootloader is advisory only.<P> The multiboot_info structure and its related substructures may be placedanywhere in memory by the boot loader (with the exception of the memoryreserved for the kernel and boot modules, of course).  It is the OS'sresponsibility to avoid overwriting this memory until it is done using it.<P> The format of the multiboot_info structure (as defined so far) follows:<P> <pre>	+-------------------+0	| flags		    |	(required)	+-------------------+4	| mem_lower	    |	(present if flags[0] is set)8	| mem_upper	    |	(present if flags[0] is set)	+-------------------+12	| boot_device	    |	(present if flags[1] is set)	+-------------------+16	| cmdline	    |	(present if flags[2] is set)	+-------------------+20	| mods_count	    |	(present if flags[3] is set)24	| mods_addr	    |	(present if flags[3] is set)	+-------------------+28 - 40 | syms		    |   (present if flags[4] or flags[5] is set)	+-------------------+44	| mmap_length	    |	(present if flags[6] is set)48	| mmap_addr	    |	(present if flags[6] is set)	+-------------------+</pre> The first longword indicates the presence and validity of other fields inthe multiboot_info structure.  All as-yet-undefined bits must be set tozero by the boot loader.   Any set bits that the OS does not understandshould be ignored.  Thus, the flags field also functions as a versionindicator, allowing the multiboot_info structure to be expanded in thefuture without breaking anything.<P> If bit 0 in the multiboot_info.flags word is set, then the 'mem_*' fieldsare valid.  'mem_lower' and 'mem_upper' indicate the amount of lower and uppermemory, respectively, in kilobytes.  Lower memory starts at address 0, andupper memory starts at address 1 megabyte.  The maximum possiblevalue for lower memory is 640 kilobytes.  The value returned for uppermemory is maximally the address of the first upper memory hole minus1 megabyte.  It is not guaranteed to be this value.<P> If bit 1 in the multiboot_info.flags word is set, then the 'boot_device'field is valid, and indicates which BIOS disk device the boot loader loadedthe OS from.  If the OS was not loaded from a BIOS disk, then this fieldmust not be present (bit 3 must be clear).  The OS may use this field as ahint for determining its own "root" device, but is not required to.  Theboot_device field is layed out in four one-byte subfields as follows:<P> <pre>	+-------+-------+-------+-------+	| drive | part1 | part2 | part3 |	+-------+-------+-------+-------+</pre> The first byte contains the BIOS drive number as understood by the BIOSINT 0x13 low-level disk interface: e.g. 0x00 for the first floppy disk or0x80 for the first hard disk.<P> The three remaining bytes specify the boot partition.  'part1' specifiesthe "top-level" partition number, 'part2' specifies a "sub-partition" inthe top-level partition, etc.  Partition numbers always start from zero.Unused partition bytes must be set to 0xFF.  For example, if the disk ispartitioned using a simple one-level DOS partitioning scheme, then 'part1'contains the DOS partition number, and 'part2' and 'part3' are both zero.As another example, if a disk is partitioned first into DOS partitions, andthen one of those DOS partitions is subdivided into several BSD partitionsusing BSD's "disklabel" strategy, then 'part1' contains the DOS partitionnumber, 'part2' contains the BSD sub-partition within that DOS partition,and 'part3' is 0xFF.<P> DOS extended partitions are indicated as partition numbers starting from 4and increasing, rather than as nested sub-partitions, even though the underlying disk layout of extended partitions is hierarchical in nature.For example, if the boot loader boots from the second extended partitionon a disk partitioned in conventional DOS style, then 'part1' will be 5,and 'part2' and 'part3' will both be 0xFF.<P> If bit 2 of the flags longword is set, the 'cmdline' field is valid, and contains the physical address of the the command line to be passed to thekernel.  The command line is a normal C-style null-terminated string.<P> If bit 3 of the flags is set, then the 'mods' fields indicate to the kernelwhat boot modules were loaded along with the kernel image, and where theycan be found.  'mods_count' contains the number of modules loaded;'mods_addr' contains the physical address of the first module structure.'mods_count' may be zero, indicating no boot modules were loaded, even ifbit 1 of 'flags' is set.  Each module structure is formatted as follows:<P> <pre>	+-------------------+0	| mod_start	    |4	| mod_end	    |	+-------------------+8	| string	    |	+-------------------+12	| reserved (0)	    |	+-------------------+</pre> The first two fields contain the start and end addresses of the boot moduleitself.  The 'string' field provides an arbitrary string to be associatedwith that particular boot module; it is a null-terminated ASCII string,just like the kernel command line.  The 'string' field may be 0 if there isno string associated with the module.  Typically the string might be acommand line (e.g. if the OS treats boot modules as executable programs),or a pathname (e.g. if the OS treats boot modules as files in a filesystem), but its exact use is specific to the OS.  The 'reserved' fieldmust be set to 0 by the boot loader and ignored by the OS.<P> NOTE:  Bits 4 & 5 are mutually exclusive.<P> If bit 4 in the multiboot_info.flags word is set, then the followingfields in the multiboot_info structure starting at byte 28 are valid:<P> <pre>	+-------------------+28	| tabsize	    |32	| strsize	    |36	| addr		    |40	| reserved (0)	    |	+-------------------+</pre> These indicate where the symbol table from an a.out kernel image can befound.  'addr' is the physical address of the size (4-byte unsignedlong) of an array of a.out-format 'nlist' structures, followed immediatelyby the array itself, then the size (4-byte unsigned long) of a set ofnull-terminated ASCII strings (plus sizeof(unsigned long) in this case),and finally the set of strings itself.  'tabsize' is equal to it's sizeparameter (found at the beginning of the symbol section), and 'strsize'is equal to it's size parameter (found at the beginning of the string section)of the following string table to which the symbol table refers.   Note that'tabsize' may be 0, indicating no symbols, even if bit 4 in the flagsword is set.<P> If bit 5 in the multiboot_info.flags word is set, then the followingfields in the multiboot_info structure starting at byte 28 are valid:<P> <pre>	+-------------------+28	| num		    |32	| size		    |36	| addr		    |40	| shndx		    |	+-------------------+</pre> These indicate where the section header table from an ELF kernel is, thesize of each entry, number of entries, and the string table used as theindex of names.  They correspond to the 'shdr_*' entries ('shdr_num', etc.)in the Executable and Linkable Format (ELF) specification in the programheader.  All sections are loaded, and the physical address fieldsof the elf section header then refer to where the sections are in memory(refer to the i386 ELF documentation for details as to how to read thesection header(s)).  Note that 'shdr_num' may be 0, indicating no symbols,even if bit 5 in the flags word is set.<P> 

Lines 1–500 of 664. Load more