multiboot.texi

i386的bootloader源码grub

\input texinfo @c -*-texinfo-*-
@c -*-texinfo-*-
@c %**start of header
@setfilename multiboot.info
@settitle Multiboot Specification
@c %**end of header

@c Unify all our little indices for now.
@syncodeindex fn cp
@syncodeindex vr cp
@syncodeindex ky cp
@syncodeindex pg cp
@syncodeindex tp cp

@footnotestyle separate
@paragraphindent 3
@finalout


@dircategory Kernel
@direntry
* Multiboot Specification: (multiboot).		Multiboot Specification.
@end direntry

@ifinfo
Copyright @copyright{} 1995, 96 Bryan Ford <baford@@cs.utah.edu>
Copyright @copyright{} 1995, 96 Erich Stefan Boleyn <erich@@uruk.org>
Copyright @copyright{} 1999, 2000, 2001, 2002 Free Software Foundation, Inc.

Permission is granted to make and distribute verbatim copies of
this manual provided the copyright notice and this permission notice
are preserved on all copies.

@ignore
Permission is granted to process this file through TeX and print the
results, provided the printed document carries a copying permission
notice identical to this one except for the removal of this paragraph
(this paragraph not being relevant to the printed manual).

@end ignore

Permission is granted to copy and distribute modified versions of this
manual under the conditions for verbatim copying, provided also that
the entire resulting derived work is distributed under the terms of a
permission notice identical to this one.

Permission is granted to copy and distribute translations of this manual
into another language, under the above conditions for modified versions.
@end ifinfo

@titlepage
@sp 10
@title The Multiboot Specification
@author Yoshinori K. Okuji, Bryan Ford, Erich Stefan Boleyn, Kunihiro Ishiguro
@page

@vskip 0pt plus 1filll
Copyright @copyright{} 1995, 96 Bryan Ford <baford@@cs.utah.edu>
Copyright @copyright{} 1995, 96 Erich Stefan Boleyn <erich@@uruk.org>
Copyright @copyright{} 1999, 2000, 2001, 2002 Free Software Foundation, Inc.

Permission is granted to make and distribute verbatim copies of
this manual provided the copyright notice and this permission notice
are preserved on all copies.

Permission is granted to copy and distribute modified versions of this
manual under the conditions for verbatim copying, provided also that
the entire resulting derived work is distributed under the terms of a
permission notice identical to this one.

Permission is granted to copy and distribute translations of this manual
into another language, under the above conditions for modified versions.
@end titlepage

@finalout
@headings double

@ifnottex
@node Top
@top Multiboot Specification

This file documents Multiboot Specification, the proposal for the boot
sequence standard. This edition documents version 0.6.93.
@end ifnottex

@menu
* Overview::                    
* Terminology::                 
* Specification::               
* Examples::                    
* History::                     
* Index::                       
@end menu


@node Overview
@chapter Introduction to Multiboot Specification

This chapter describes some rough information on the Multiboot
Specification. Note that this is not a part of the specification itself.

@menu
* Motivation::                  
* Architecture::                
* Operating systems::           
* Boot sources::                
* Boot-time configuration::     
* Convenience to operating systems::  
* Boot modules::                
@end menu


@node Motivation
@section The background of Multiboot Specification

Every operating system ever created tends to have its own boot loader.
Installing a new operating system on a machine generally involves
installing a whole new set of boot mechanisms, each with completely
different install-time and boot-time user interfaces. Getting multiple
operating systems to coexist reliably on one machine through typical
@dfn{chaining} mechanisms can be a nightmare. There is little or no
choice of boot loaders for a particular operating system --- if the one
that comes with the operating system doesn't do exactly what you want,
or doesn't work on your machine, you're screwed.

While we may not be able to fix this problem in existing commercial
operating systems, it shouldn't be too difficult for a few people in the
free operating system communities to put their heads together and solve
this problem for the popular free operating systems. That's what this
specification aims for. Basically, it specifies an interface between a
boot loader and a operating system, such that any complying boot loader
should be able to load any complying operating system. This
specification does @emph{not} specify how boot loaders should work ---
only how they must interface with the operating system being loaded.


@node Architecture
@section The target architecture

This specification is primarily targeted at @sc{pc}, since they are the
most common and have the largest variety of operating systems and boot
loaders. However, to the extent that certain other architectures may
need a boot specification and do not have one already, a variation of
this specification, stripped of the x86-specific details, could be
adopted for them as well.


@node Operating systems
@section The target operating systems

This specification is targeted toward free 32-bit operating systems
that can be fairly easily modified to support the specification without
going through lots of bureaucratic rigmarole. The particular free
operating systems that this specification is being primarily designed
for are Linux, FreeBSD, NetBSD, Mach, and VSTa. It is hoped that other
emerging free operating systems will adopt it from the start, and thus
immediately be able to take advantage of existing boot loaders. It would
be nice if commercial operating system vendors eventually adopted this
specification as well, but that's probably a pipe dream.


@node Boot sources
@section Boot sources

It should be possible to write compliant boot loaders that load the OS
image from a variety of sources, including floppy disk, hard disk, and
across a network.

Disk-based boot loaders may use a variety of techniques to find the
relevant OS image and boot module data on disk, such as by
interpretation of specific file systems (e.g. the BSD/Mach boot loader),
using precalculated @dfn{block lists} (e.g. LILO), loading from a
special @dfn{boot partition} (e.g. OS/2), or even loading from within
another operating system (e.g. the VSTa boot code, which loads from
DOS). Similarly, network-based boot loaders could use a variety of
network hardware and protocols.

It is hoped that boot loaders will be created that support multiple
loading mechanisms, increasing their portability, robustness, and
user-friendliness.


@node Boot-time configuration
@section Configure an operating system at boot-time

It is often necessary for one reason or another for the user to be able
to provide some configuration information to an operating system
dynamically at boot time. While this specification should not dictate
how this configuration information is obtained by the boot loader, it
should provide a standard means for the boot loader to pass such
information to the operating system.


@node Convenience to operating systems
@section How to make OS development easier

OS images should be easy to generate. Ideally, an OS image should simply
be an ordinary 32-bit executable file in whatever file format the
operating system normally uses. It should be possible to @code{nm} or
disassemble OS images just like normal executables. Specialized tools
should not be required to create OS images in a @emph{special} file
format. If this means shifting some work from the operating system to
a boot loader, that is probably appropriate, because all the memory
consumed by the boot loader will typically be made available again after
the boot process is created, whereas every bit of code in the OS image
typically has to remain in memory forever. The operating system should
not have to worry about getting into 32-bit mode initially, because mode
switching code generally needs to be in the boot loader anyway in order
to load operating system data above the 1MB boundary, and forcing the
operating system to do this makes creation of OS images much more
difficult.

Unfortunately, there is a horrendous variety of executable file formats
even among free Unix-like @sc{pc}-based operating systems --- generally
a different format for each operating system. Most of the relevant free
operating systems use some variant of a.out format, but some are moving
to @sc{elf}. It is highly desirable for boot loaders not to have to be
able to interpret all the different types of executable file formats in
existence in order to load the OS image --- otherwise the boot loader
effectively becomes operating system specific again.

This specification adopts a compromise solution to this
problem. Multiboot-compliant OS images always contain a magic
@dfn{Multiboot header} (@pxref{OS image format}), which allows the boot
loader to load the image without having to understand numerous a.out
variants or other executable formats. This magic header does not need to
be at the very beginning of the executable file, so kernel images can
still conform to the local a.out format variant in addition to being
Multiboot-compliant.


@node Boot modules
@section Boot modules

Many modern operating system kernels, such as those of VSTa and Mach, do
not by themselves contain enough mechanism to get the system fully
operational: they require the presence of additional software modules at
boot time in order to access devices, mount file systems, etc. While
these additional modules could be embedded in the main OS image along
with the kernel itself, and the resulting image be split apart manually
by the operating system when it receives control, it is often more
flexible, more space-efficient, and more convenient to the operating
system and user if the boot loader can load these additional modules
independently in the first place.

Thus, this specification should provide a standard method for a boot
loader to indicate to the operating system what auxiliary boot modules
were loaded, and where they can be found. Boot loaders don't have to
support multiple boot modules, but they are strongly encouraged to,
because some operating systems will be unable to boot without them.


@node Terminology
@chapter The definitions of terms used through the specification

@table @dfn
@item must
We use the term @dfn{must}, when any boot loader or OS image needs to
follow a rule --- otherwise, the boot loader or OS image is @emph{not}
Multiboot-compliant.

@item should
We use the term @dfn{should}, when any boot loader or OS image is
recommended to follow a rule, but it doesn't need to follow the rule.

@item may
We use the term @dfn{may}, when any boot loader or OS image is allowed
to follow a rule.

@item boot loader
Whatever program or set of programs loads the image of the final
operating system to be run on the machine. The boot loader may itself
consist of several stages, but that is an implementation detail not
relevant to this specification. Only the @emph{final} stage of the boot
loader --- the stage that eventually transfers control to an operating
system --- must follow the rules specified in this document in order
to be @dfn{Multiboot-compliant}; earlier boot loader stages may be
designed in whatever way is most convenient.

@item OS image
The initial binary image that a boot loader loads into memory and
transfers control to start an operating system. The OS image is
typically an executable containing the operating system kernel.

@item boot module
Other auxiliary files that a boot loader loads into memory along with
an OS image, but does not interpret in any way other than passing their
locations to the operating system when it is invoked.

@item Multiboot-compliant
A boot loader or an OS image which follows the rules defined as
@dfn{must} is Multiboot-compliant. When this specification specifies a
rule as @dfn{should} or @dfn{may}, a Multiboot-complaint boot loader/OS
image doesn't need to follow the rule.

@item u8
The type of unsigned 8-bit data.

@item u16
The type of unsigned 16-bit data. Because the target architecture is
little-endian, u16 is coded in little-endian.

@item u32
The type of unsigned 32-bit data. Because the target architecture is
little-endian, u32 is coded in little-endian.

@item u64
The type of unsigned 64-bit data. Because the target architecture is
little-endian, u64 is coded in little-endian.