multiboot.texi

i386的bootloader源码grub

Management (APM) BIOS Interface Specification}, for more information.

If bit 11 in the @samp{flags} is set, the graphics table is available.
This must only be done if the kernel has indicated in the
@samp{Multiboot Header} that it accepts a graphics mode.

The fields @samp{vbe_control_info} and @samp{vbe_mode_info} contain
the physical addresses of @sc{vbe} control information returned by the
@sc{vbe} Function 00h and @sc{vbe} mode information returned by the
@sc{vbe} Function 01h, respectively.

The field @samp{vbe_mode} indicates current video mode in the format
specified in @sc{vbe} 3.0.

The rest fields @samp{vbe_interface_seg}, @samp{vbe_interface_off}, and
@samp{vbe_interface_len} contain the table of a protected mode interface
defined in @sc{vbe} 2.0+. If this information is not available, those
fields contain zero. Note that @sc{vbe} 3.0 defines another protected
mode interface which is incompatible with the old one. If you want to
use the new protected mode interface, you will have to find the table
yourself.

The fields for the graphics table are designed for @sc{vbe}, but
Multiboot boot loaders may simulate @sc{vbe} on non-@sc{vbe} modes, as
if they were @sc{vbe} modes.


@node Examples
@chapter Examples

@strong{Caution:} The following items are not part of the specification
document, but are included for prospective operating system and boot
loader writers.

@menu
* Notes on PC::                 
* BIOS device mapping techniques::  
* Example OS code::             
* Example boot loader code::    
@end menu


@node Notes on PC
@section Notes on PC

In reference to bit 0 of the @samp{flags} parameter in the Multiboot
information structure, if the bootloader in question uses older
@sc{bios} interfaces, or the newest ones are not available (see
description about bit 6), then a maximum of either 15 or 63 megabytes of
memory may be reported. It is @emph{highly} recommended that boot
loaders perform a thorough memory probe.

In reference to bit 1 of the @samp{flags} parameter in the Multiboot
information structure, it is recognized that determination of which
@sc{bios} drive maps to which device driver in an operating system is
non-trivial, at best. Many kludges have been made to various operating
systems instead of solving this problem, most of them breaking under
many conditions. To encourage the use of general-purpose solutions to
this problem, there are 2 @sc{bios} device mapping techniques
(@pxref{BIOS device mapping techniques}). 

In reference to bit 6 of the @samp{flags} parameter in the Multiboot
information structure, it is important to note that the data structure
used there (starting with @samp{BaseAddrLow}) is the data returned by
the INT 15h, AX=E820h --- Query System Address Map call. See @xref{Query
System Address Map, , Query System Address Map, grub.info, The GRUB
Manual}, for more information. The interface here is meant to allow a
boot loader to work unmodified with any reasonable extensions of the
@sc{bios} interface, passing along any extra data to be interpreted by
the operating system as desired.


@node BIOS device mapping techniques
@section BIOS device mapping techniques

Both of these techniques should be usable from any PC operating system,
and neither require any special support in the drivers themselves. This
section will be flushed out into detailed explanations, particularly for
the I/O restriction technique.

The general rule is that the data comparison technique is the quick and
dirty solution. It works most of the time, but doesn't cover all the
bases, and is relatively simple.

The I/O restriction technique is much more complex, but it has potential
to solve the problem under all conditions, plus allow access of the
remaining @sc{bios} devices when not all of them have operating system
drivers.

@menu
* Data comparison technique::   
* I/O restriction technique::   
@end menu


@node Data comparison technique
@subsection Data comparison technique

Before activating @emph{any} of the device drivers, gather enough data
from similar sectors on each of the disks such that each one can be
uniquely identified.

After activating the device drivers, compare data from the drives using
the operating system drivers. This should hopefully be sufficient to
provide such a mapping.

Problems:

@enumerate
@item
The data on some @sc{bios} devices might be identical (so the part
reading the drives from the @sc{bios} should have some mechanism to give
up).

@item
There might be extra drives not accessible from the @sc{bios} which are
identical to some drive used by the @sc{bios} (so it should be capable
of giving up there as well).
@end enumerate


@node I/O restriction technique
@subsection I/O restriction technique

This first step may be unnecessary, but first create copy-on-write
mappings for the device drivers writing into @sc{pc} @sc{ram}. Keep the
original copies for the @dfn{clean @sc{bios} virtual machine} to be
created later.

For each device driver brought online, determine which @sc{bios} devices
become inaccessible by:

@enumerate
@item
Create a @dfn{clean @sc{bios} virtual machine}.

@item
Set the I/O permission map for the I/O area claimed by the device driver
to no permissions (neither read nor write).

@item
Access each device.

@item
Record which devices succeed, and those which try to access the
@dfn{restricted} I/O areas (hopefully, this will be an @dfn{xor}
situation).
@end enumerate

For each device driver, given how many of the @sc{bios} devices were
subsumed by it (there should be no gaps in this list), it should be easy
to determine which devices on the controller these are.

In general, you have at most 2 disks from each controller given
@sc{bios} numbers, but they pretty much always count from the lowest
logically numbered devices on the controller.


@node Example OS code
@section Example OS code

In this distribution, the example Multiboot kernel @file{kernel} is
included. The kernel just prints out the Multiboot information structure
on the screen, so you can make use of the kernel to test a
Multiboot-compliant boot loader and for reference to how to implement a
Multiboot kernel. The source files can be found under the directory
@file{docs} in the GRUB distribution.

The kernel @file{kernel} consists of only three files: @file{boot.S},
@file{kernel.c} and @file{multiboot.h}. The assembly source
@file{boot.S} is written in GAS (@pxref{Top, , GNU assembler, as.info,
The GNU assembler}), and contains the Multiboot information structure to
comply with the specification. When a Multiboot-compliant boot loader
loads and execute it, it initialize the stack pointer and @code{EFLAGS},
and then call the function @code{cmain} defined in @file{kernel.c}. If
@code{cmain} returns to the callee, then it shows a message to inform
the user of the halt state and stops forever until you push the reset
key. The file @file{kernel.c} contains the function @code{cmain},
which checks if the magic number passed by the boot loader is valid and
so on, and some functions to print messages on the screen. The file
@file{multiboot.h} defines some macros, such as the magic number for the
Multiboot header, the Multiboot header structure and the Multiboot
information structure.

@menu
* multiboot.h::                 
* boot.S::                      
* kernel.c::                    
* Other Multiboot kernels::     
@end menu


@node multiboot.h
@subsection multiboot.h

This is the source code in the file @file{multiboot.h}:

@example
@include multiboot.h.texi
@end example


@node boot.S
@subsection boot.S

In the file @file{boot.S}:

@example
@include boot.S.texi
@end example


@node kernel.c
@subsection kernel.c

And, in the file @file{kernel.c}:

@example
@include kernel.c.texi
@end example


@node Other Multiboot kernels
@subsection Other Multiboot kernels

Other useful information should be available in Multiboot kernels, such
as GNU Mach and Fiasco @url{http://os.inf.tu-dresden.de/fiasco/}. And,
it is worth mentioning the OSKit
@url{http://www.cs.utah.edu/projects/flux/oskit/}, which provides a
library supporting the specification.


@node Example boot loader code
@section Example boot loader code

The GNU GRUB (@pxref{Top, , GRUB, grub.info, The GRUB manual}) project
is a full Multiboot-compliant boot loader, supporting all required and
optional features present in this specification. A public release has
not been made, but the test release is available from:

@url{ftp://alpha.gnu.org/gnu/grub}

See the webpage @url{http://www.gnu.org/software/grub/grub.html}, for
more information.


@node History
@chapter The change log of this specification

@table @asis
@item 0.7
@itemize @bullet
@item
@dfn{Multiboot Standard} is renamed to @dfn{Multiboot Specification}.

@item
Graphics fields are added to Multiboot header.

@item
BIOS drive information, BIOS configuration table, the name of a boot
loader, APM information, and graphics information are added to Multiboot
information.

@item
Rewritten in Texinfo format.

@item
Rewritten, using more strict words.

@item
The maintainer changes to the GNU GRUB maintainer team
@email{bug-grub@@gnu.org}, from Bryan Ford and Erich Stefan Boleyn.
@end itemize

@item 0.6
@itemize @bullet
@item
A few wording changes.

@item
Header checksum.

@item
Clasification of machine state passed to an operating system.
@end itemize

@item 0.5
@itemize @bullet
@item
Name change.
@end itemize

@item 0.4
@itemize @bullet
@item
Major changes plus HTMLification.
@end itemize
@end table


@node Index
@unnumbered Index

@printindex cp

@contents
@bye