multiboot.texi

i386的bootloader源码grub

@end table


@node Specification
@chapter The exact definitions of Multiboot Specification

There are three main aspects of a boot loader/OS image interface:

@enumerate
@item
The format of an OS image as seen by a boot loader.

@item
The state of a machine when a boot loader starts an operating
system.

@item
The format of information passed by a boot loader to an operating
system.
@end enumerate

@menu
* OS image format::             
* Machine state::               
* Boot information format::     
@end menu


@node OS image format
@section OS image format

An OS image may be an ordinary 32-bit executable file in the standard
format for that particular operating system, except that it may be
linked at a non-default load address to avoid loading on top of the
@sc{pc}'s I/O region or other reserved areas, and of course it should
not use shared libraries or other fancy features.

An OS image must contain an additional header called @dfn{Multiboot
header}, besides the headers of the format used by the OS image. The
Multiboot header must be contained completely within the first 8192
bytes of the OS image, and must be longword (32-bit) aligned. In
general, it should come @emph{as early as possible}, and may be
embedded in the beginning of the text segment after the @emph{real}
executable header.

@menu
* Header layout::               The layout of Multiboot header
* Header magic fields::         The magic fields of Multiboot header
* Header address fields::       
* Header graphics fields::      
@end menu


@node Header layout
@subsection The layout of Multiboot header

The layout of the Multiboot header must be as follows:

@multitable @columnfractions .1 .1 .2 .5
@item Offset @tab Type  @tab Field Name    @tab Note
@item 0      @tab u32 @tab magic         @tab required
@item 4      @tab u32 @tab flags         @tab required
@item 8      @tab u32 @tab checksum      @tab required
@item 12     @tab u32 @tab header_addr   @tab if flags[16] is set
@item 16     @tab u32 @tab load_addr     @tab if flags[16] is set
@item 20     @tab u32 @tab load_end_addr @tab if flags[16] is set
@item 24     @tab u32 @tab bss_end_addr  @tab if flags[16] is set
@item 28     @tab u32 @tab entry_addr    @tab if flags[16] is set
@item 32     @tab u32 @tab mode_type     @tab if flags[2] is set
@item 36     @tab u32 @tab width         @tab if flags[2] is set
@item 40     @tab u32 @tab height        @tab if flags[2] is set
@item 44     @tab u32 @tab depth         @tab if flags[2] is set
@end multitable

The fields @samp{magic}, @samp{flags} and @samp{checksum} are defined in
@ref{Header magic fields}, the fields @samp{header_addr},
@samp{load_addr}, @samp{load_end_addr}, @samp{bss_end_addr} and
@samp{entry_addr} are defined in @ref{Header address fields}, and the
fields @samp{mode_type}, @samp{width}, @samp{height} and @samp{depth} are
defind in @ref{Header graphics fields}.


@node Header magic fields
@subsection The magic fields of Multiboot header

@table @samp
@item magic
The field @samp{magic} is the magic number identifying the header,
which must be the hexadecimal value @code{0x1BADB002}.

@item flags
The field @samp{flags} specifies features that the OS image requests or
requires of an boot loader. Bits 0-15 indicate requirements; if the
boot loader sees any of these bits set but doesn't understand the flag
or can't fulfill the requirements it indicates for some reason, it must
notify the user and fail to load the OS image. Bits 16-31 indicate
optional features; if any bits in this range are set but the boot loader
doesn't understand them, it may simply ignore them and proceed as
usual. Naturally, all as-yet-undefined bits in the @samp{flags} word
must be set to zero in OS images. This way, the @samp{flags} fields
serves for version control as well as simple feature selection.

If bit 0 in the @samp{flags} word is set, then all boot modules loaded
along with the operating system must be aligned on page (4KB)
boundaries. Some operating systems expect to be able to map the pages
containing boot modules directly into a paged address space during
startup, and thus need the boot modules to be page-aligned.

If bit 1 in the @samp{flags} word is set, then information on available
memory via at least the @samp{mem_*} fields of the Multiboot information
structure (@pxref{Boot information format}) must be included. If the
boot loader is capable of passing a memory map (the @samp{mmap_*} fields)
and one exists, then it may be included as well.

If bit 2 in the @samp{flags} word is set, information about the video
mode table (@pxref{Boot information format}) must be available to the
kernel.

If bit 16 in the @samp{flags} word is set, then the fields at offsets
8-24 in the Multiboot header are valid, and the boot loader should use
them instead of the fields in the actual executable header to calculate
where to load the OS image. This information does not need to be
provided if the kernel image is in @sc{elf} format, but it @emph{must}
be provided if the images is in a.out format or in some other
format. Compliant boot loaders must be able to load images that either
are in @sc{elf} format or contain the load address information embedded
in the Multiboot header; they may also directly support other executable
formats, such as particular a.out variants, but are not required to.

@item checksum
The field @samp{checksum} is a 32-bit unsigned value which, when added
to the other magic fields (i.e. @samp{magic} and @samp{flags}), must
have a 32-bit unsigned sum of zero.
@end table


@node Header address fields
@subsection The address fields of Multiboot header

All of the address fields enabled by flag bit 16 are physical addresses.
The meaning of each is as follows:

@table @code
@item header_addr
Contains the address corresponding to the beginning of the Multiboot
header --- the physical memory location at which the magic value is
supposed to be loaded. This field serves to @dfn{synchronize} the
mapping between OS image offsets and physical memory addresses.

@item load_addr
Contains the physical address of the beginning of the text segment. The
offset in the OS image file at which to start loading is defined by the
offset at which the header was found, minus (header_addr -
load_addr). load_addr must be less than or equal to header_addr.

@item load_end_addr
Contains the physical address of the end of the data
segment. (load_end_addr - load_addr) specifies how much data to load.
This implies that the text and data segments must be consecutive in the
OS image; this is true for existing a.out executable formats.
If this field is zero, the boot loader assumes that the text and data
segments occupy the whole OS image file.

@item bss_end_addr
Contains the physical address of the end of the bss segment. The boot
loader initializes this area to zero, and reserves the memory it
occupies to avoid placing boot modules and other data relevant to the
operating system in that area. If this field is zero, the boot loader
assumes that no bss segment is present.

@item entry_addr
The physical address to which the boot loader should jump in order to
start running the operating system.
@end table


@node Header graphics fields
@subsection The graphics fields of Multiboot header

All of the graphics fields are enabled by flag bit 2. They specify the
preferred graphics mode. Note that that is only a @emph{recommended}
mode by the OS image. If the mode exists, the boot loader should set
it, when the user doesn't specify a mode explicitly. Otherwise, the
boot loader should fall back to a similar mode, if available.

The meaning of each is as follows:

@table @code
@item mode_type
Contains @samp{0} for linear graphics mode or @samp{1} for
EGA-standard text mode. Everything else is reserved for future
expansion. Note that the boot loader may set a text mode, even if this
field contains @samp{0}.

@item width
Contains the number of the columns. This is specified in pixels in a
graphics mode, and in characters in a text mode. The value zero
indicates that the OS image has no preference.

@item height
Contains the number of the lines. This is specified in pixels in a
graphics mode, and in characters in a text mode. The value zero
indicates that the OS image has no preference.

@item depth
Contains the number of bits per pixel in a graphics mode, and zero in
a text mode. The value zero indicates that the OS image has no
preference.
@end table


@node Machine state
@section Machine state

When the boot loader invokes the 32-bit operating system, the machine
must have the following state:

@table @samp
@item EAX
Must contain the magic value @samp{0x2BADB002}; the presence of this
value indicates to the operating system that it was loaded by a
Multiboot-compliant boot loader (e.g. as opposed to another type of
boot loader that the operating system can also be loaded from).

@item EBX
Must contain the 32-bit physical address of the Multiboot
information structure provided by the boot loader (@pxref{Boot
information format}).

@item CS
Must be a 32-bit read/execute code segment with an offset of @samp{0}
and a limit of @samp{0xFFFFFFFF}. The exact value is undefined.

@item DS
@itemx ES
@itemx FS
@itemx GS
@itemx SS
Must be a 32-bit read/write data segment with an offset of @samp{0}
and a limit of @samp{0xFFFFFFFF}. The exact values are all undefined.

@item A20 gate
Must be enabled.

@item CR0
Bit 31 (PG) must be cleared. Bit 0 (PE) must be set. Other bits are
all undefined.

@item EFLAGS
Bit 17 (VM) must be cleared. Bit 9 (IF) must be cleared. Other bits
are all undefined.
@end table

All other processor registers and flag bits are undefined. This
includes, in particular:

@table @samp
@item ESP
The OS image must create its own stack as soon as it needs one.

@item GDTR
Even though the segment registers are set up as described above, the
@samp{GDTR} may be invalid, so the OS image must not load any segment
registers (even just reloading the same values!) until it sets up its
own @samp{GDT}.

@item IDTR
The OS image must leave interrupts disabled until it sets up its own
@code{IDT}.
@end table

However, other machine state should be left by the boot loader in
@dfn{normal working order}, i.e. as initialized by the @sc{bios} (or
DOS, if that's what the boot loader runs from). In other words, the
operating system should be able to make @sc{bios} calls and such after
being loaded, as long as it does not overwrite the @sc{bios} data
structures before doing so. Also, the boot loader must leave the
@sc{pic} programmed with the normal @sc{bios}/DOS values, even if it
changed them during the switch to 32-bit mode.


@node Boot information format
@section Boot information format

FIXME: Split this chapter like the chapter ``OS image format''.

Upon entry to the operating system, the @code{EBX} register contains the
physical address of a @dfn{Multiboot information} data structure,
through which the boot loader communicates vital information to the
operating system. The operating system can use or ignore any parts of
the structure as it chooses; all information passed by the boot loader
is advisory only.

The Multiboot information structure and its related substructures may be
placed anywhere in memory by the boot loader (with the exception of the
memory reserved for the kernel and boot modules, of course). It is the
operating system's responsibility to avoid overwriting this memory until
it is done using it.

The format of the Multiboot information structure (as defined so far)
follows:

@example
@group
        +-------------------+
0       | flags             |    (required)
        +-------------------+
4       | mem_lower         |    (present if flags[0] is set)
8       | mem_upper         |    (present if flags[0] is set)