/usr/share/doc/multiboot/html/Specification.html is in multiboot 0.6.96+20101113-1.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 | <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<!-- Copyright (C) 1995,96 Bryan Ford <baford@cs.utah.edu>
Copyright (C) 1995,96 Erich Stefan Boleyn <erich@uruk.org>
Copyright (C) 1999,2000,2001,2002,2005,2006,2009,2010 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. -->
<!-- Created by GNU Texinfo 5.1, http://www.gnu.org/software/texinfo/ -->
<head>
<title>Multiboot Specification version 0.6.96: Specification</title>
<meta name="description" content="Multiboot Specification version 0.6.96: Specification">
<meta name="keywords" content="Multiboot Specification version 0.6.96: Specification">
<meta name="resource-type" content="document">
<meta name="distribution" content="global">
<meta name="Generator" content="makeinfo">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<link href="index.html#Top" rel="start" title="Top">
<link href="Index.html#Index" rel="index" title="Index">
<link href="Index.html#SEC_Contents" rel="contents" title="Table of Contents">
<link href="index.html#Top" rel="up" title="Top">
<link href="Examples.html#Examples" rel="next" title="Examples">
<link href="Terminology.html#Terminology" rel="previous" title="Terminology">
<style type="text/css">
<!--
a.summary-letter {text-decoration: none}
blockquote.smallquotation {font-size: smaller}
div.display {margin-left: 3.2em}
div.example {margin-left: 3.2em}
div.indentedblock {margin-left: 3.2em}
div.lisp {margin-left: 3.2em}
div.smalldisplay {margin-left: 3.2em}
div.smallexample {margin-left: 3.2em}
div.smallindentedblock {margin-left: 3.2em; font-size: smaller}
div.smalllisp {margin-left: 3.2em}
kbd {font-style:oblique}
pre.display {font-family: inherit}
pre.format {font-family: inherit}
pre.menu-comment {font-family: serif}
pre.menu-preformatted {font-family: serif}
pre.smalldisplay {font-family: inherit; font-size: smaller}
pre.smallexample {font-size: smaller}
pre.smallformat {font-family: inherit; font-size: smaller}
pre.smalllisp {font-size: smaller}
span.nocodebreak {white-space:nowrap}
span.nolinebreak {white-space:nowrap}
span.roman {font-family:serif; font-weight:normal}
span.sansserif {font-family:sans-serif; font-weight:normal}
ul.no-bullet {list-style: none}
-->
</style>
</head>
<body lang="en" bgcolor="#FFFFFF" text="#000000" link="#0000FF" vlink="#800080" alink="#FF0000">
<a name="Specification"></a>
<div class="header">
<p>
Next: <a href="Examples.html#Examples" accesskey="n" rel="next">Examples</a>, Previous: <a href="Terminology.html#Terminology" accesskey="p" rel="previous">Terminology</a>, Up: <a href="index.html#Top" accesskey="u" rel="up">Top</a> [<a href="Index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Index.html#Index" title="Index" rel="index">Index</a>]</p>
</div>
<a name="The-exact-definitions-of-Multiboot-Specification"></a>
<h2 class="chapter">3 The exact definitions of Multiboot Specification</h2>
<p>There are three main aspects of a boot loader/OS image interface:
</p>
<ol>
<li> The format of an OS image as seen by a boot loader.
</li><li> The state of a machine when a boot loader starts an operating
system.
</li><li> The format of information passed by a boot loader to an operating
system.
</li></ol>
<table class="menu" border="0" cellspacing="0">
<tr><td align="left" valign="top">• <a href="#OS-image-format" accesskey="1">OS image format</a>:</td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top">• <a href="#Machine-state" accesskey="2">Machine state</a>:</td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top">• <a href="#Boot-information-format" accesskey="3">Boot information format</a>:</td><td> </td><td align="left" valign="top">
</td></tr>
</table>
<hr>
<a name="OS-image-format"></a>
<div class="header">
<p>
Next: <a href="#Machine-state" accesskey="n" rel="next">Machine state</a>, Up: <a href="#Specification" accesskey="u" rel="up">Specification</a> [<a href="Index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Index.html#Index" title="Index" rel="index">Index</a>]</p>
</div>
<a name="OS-image-format-1"></a>
<h3 class="section">3.1 OS image format</h3>
<p>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
<small>PC</small>’s I/O region or other reserved areas, and of course it should
not use shared libraries or other fancy features.
</p>
<p>An OS image must contain an additional header called <em>Multiboot
header</em>, 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 <em>as early as possible</em>, and may be
embedded in the beginning of the text segment after the <em>real</em>
executable header.
</p>
<table class="menu" border="0" cellspacing="0">
<tr><td align="left" valign="top">• <a href="#Header-layout" accesskey="1">Header layout</a>:</td><td> </td><td align="left" valign="top">The layout of Multiboot header
</td></tr>
<tr><td align="left" valign="top">• <a href="#Header-magic-fields" accesskey="2">Header magic fields</a>:</td><td> </td><td align="left" valign="top">The magic fields of Multiboot header
</td></tr>
<tr><td align="left" valign="top">• <a href="#Header-address-fields" accesskey="3">Header address fields</a>:</td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top">• <a href="#Header-graphics-fields" accesskey="4">Header graphics fields</a>:</td><td> </td><td align="left" valign="top">
</td></tr>
</table>
<hr>
<a name="Header-layout"></a>
<div class="header">
<p>
Next: <a href="#Header-magic-fields" accesskey="n" rel="next">Header magic fields</a>, Up: <a href="#OS-image-format" accesskey="u" rel="up">OS image format</a> [<a href="Index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Index.html#Index" title="Index" rel="index">Index</a>]</p>
</div>
<a name="The-layout-of-Multiboot-header"></a>
<h4 class="subsection">3.1.1 The layout of Multiboot header</h4>
<p>The layout of the Multiboot header must be as follows:
</p>
<table>
<tr><td width="10%">Offset</td><td width="10%">Type</td><td width="20%">Field Name</td><td width="50%">Note</td></tr>
<tr><td width="10%">0</td><td width="10%">u32</td><td width="20%">magic</td><td width="50%">required</td></tr>
<tr><td width="10%">4</td><td width="10%">u32</td><td width="20%">flags</td><td width="50%">required</td></tr>
<tr><td width="10%">8</td><td width="10%">u32</td><td width="20%">checksum</td><td width="50%">required</td></tr>
<tr><td width="10%">12</td><td width="10%">u32</td><td width="20%">header_addr</td><td width="50%">if flags[16] is set</td></tr>
<tr><td width="10%">16</td><td width="10%">u32</td><td width="20%">load_addr</td><td width="50%">if flags[16] is set</td></tr>
<tr><td width="10%">20</td><td width="10%">u32</td><td width="20%">load_end_addr</td><td width="50%">if flags[16] is set</td></tr>
<tr><td width="10%">24</td><td width="10%">u32</td><td width="20%">bss_end_addr</td><td width="50%">if flags[16] is set</td></tr>
<tr><td width="10%">28</td><td width="10%">u32</td><td width="20%">entry_addr</td><td width="50%">if flags[16] is set</td></tr>
<tr><td width="10%">32</td><td width="10%">u32</td><td width="20%">mode_type</td><td width="50%">if flags[2] is set</td></tr>
<tr><td width="10%">36</td><td width="10%">u32</td><td width="20%">width</td><td width="50%">if flags[2] is set</td></tr>
<tr><td width="10%">40</td><td width="10%">u32</td><td width="20%">height</td><td width="50%">if flags[2] is set</td></tr>
<tr><td width="10%">44</td><td width="10%">u32</td><td width="20%">depth</td><td width="50%">if flags[2] is set</td></tr>
</table>
<p>The fields ‘<samp>magic</samp>’, ‘<samp>flags</samp>’ and ‘<samp>checksum</samp>’ are defined in
<a href="#Header-magic-fields">Header magic fields</a>, the fields ‘<samp>header_addr</samp>’,
‘<samp>load_addr</samp>’, ‘<samp>load_end_addr</samp>’, ‘<samp>bss_end_addr</samp>’ and
‘<samp>entry_addr</samp>’ are defined in <a href="#Header-address-fields">Header address fields</a>, and the
fields ‘<samp>mode_type</samp>’, ‘<samp>width</samp>’, ‘<samp>height</samp>’ and ‘<samp>depth</samp>’ are
defined in <a href="#Header-graphics-fields">Header graphics fields</a>.
</p>
<hr>
<a name="Header-magic-fields"></a>
<div class="header">
<p>
Next: <a href="#Header-address-fields" accesskey="n" rel="next">Header address fields</a>, Previous: <a href="#Header-layout" accesskey="p" rel="previous">Header layout</a>, Up: <a href="#OS-image-format" accesskey="u" rel="up">OS image format</a> [<a href="Index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Index.html#Index" title="Index" rel="index">Index</a>]</p>
</div>
<a name="The-magic-fields-of-Multiboot-header"></a>
<h4 class="subsection">3.1.2 The magic fields of Multiboot header</h4>
<dl compact="compact">
<dt>‘<samp>magic</samp>’</dt>
<dd><p>The field ‘<samp>magic</samp>’ is the magic number identifying the header,
which must be the hexadecimal value <code>0x1BADB002</code>.
</p>
</dd>
<dt>‘<samp>flags</samp>’</dt>
<dd><p>The field ‘<samp>flags</samp>’ 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</samp>’ word
must be set to zero in OS images. This way, the ‘<samp>flags</samp>’ fields
serves for version control as well as simple feature selection.
</p>
<p>If bit 0 in the ‘<samp>flags</samp>’ 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.
</p>
<p>If bit 1 in the ‘<samp>flags</samp>’ word is set, then information on available
memory via at least the ‘<samp>mem_*</samp>’ fields of the Multiboot information
structure (see <a href="#Boot-information-format">Boot information format</a>) must be included. If the
boot loader is capable of passing a memory map (the ‘<samp>mmap_*</samp>’ fields)
and one exists, then it may be included as well.
</p>
<p>If bit 2 in the ‘<samp>flags</samp>’ word is set, information about the video
mode table (see <a href="#Boot-information-format">Boot information format</a>) must be available to the
kernel.
</p>
<p>If bit 16 in the ‘<samp>flags</samp>’ word is set, then the fields at offsets
12-28 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 <small>ELF</small> format, but it <em>must</em>
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 <small>ELF</small> 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.
</p>
</dd>
<dt>‘<samp>checksum</samp>’</dt>
<dd><p>The field ‘<samp>checksum</samp>’ is a 32-bit unsigned value which, when added
to the other magic fields (i.e. ‘<samp>magic</samp>’ and ‘<samp>flags</samp>’), must
have a 32-bit unsigned sum of zero.
</p></dd>
</dl>
<hr>
<a name="Header-address-fields"></a>
<div class="header">
<p>
Next: <a href="#Header-graphics-fields" accesskey="n" rel="next">Header graphics fields</a>, Previous: <a href="#Header-magic-fields" accesskey="p" rel="previous">Header magic fields</a>, Up: <a href="#OS-image-format" accesskey="u" rel="up">OS image format</a> [<a href="Index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Index.html#Index" title="Index" rel="index">Index</a>]</p>
</div>
<a name="The-address-fields-of-Multiboot-header"></a>
<h4 class="subsection">3.1.3 The address fields of Multiboot header</h4>
<p>All of the address fields enabled by flag bit 16 are physical addresses.
The meaning of each is as follows:
</p>
<dl compact="compact">
<dt><code>header_addr</code></dt>
<dd><p>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 <em>synchronize</em> the
mapping between OS image offsets and physical memory addresses.
</p>
</dd>
<dt><code>load_addr</code></dt>
<dd><p>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.
</p>
</dd>
<dt><code>load_end_addr</code></dt>
<dd><p>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.
</p>
</dd>
<dt><code>bss_end_addr</code></dt>
<dd><p>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.
</p>
</dd>
<dt><code>entry_addr</code></dt>
<dd><p>The physical address to which the boot loader should jump in order to
start running the operating system.
</p></dd>
</dl>
<hr>
<a name="Header-graphics-fields"></a>
<div class="header">
<p>
Previous: <a href="#Header-address-fields" accesskey="p" rel="previous">Header address fields</a>, Up: <a href="#OS-image-format" accesskey="u" rel="up">OS image format</a> [<a href="Index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Index.html#Index" title="Index" rel="index">Index</a>]</p>
</div>
<a name="The-graphics-fields-of-Multiboot-header"></a>
<h4 class="subsection">3.1.4 The graphics fields of Multiboot header</h4>
<p>All of the graphics fields are enabled by flag bit 2. They specify the
preferred graphics mode. Note that that is only a <em>recommended</em>
mode by the OS image. Boot loader may choose a different mode if it sees fit.
</p>
<p>The meaning of each is as follows:
</p>
<dl compact="compact">
<dt><code>mode_type</code></dt>
<dd><p>Contains ‘<samp>0</samp>’ for linear graphics mode or ‘<samp>1</samp>’ 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</samp>’, or set a video mode even if this field contains
‘<samp>1</samp>’.
</p>
</dd>
<dt><code>width</code></dt>
<dd><p>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.
</p>
</dd>
<dt><code>height</code></dt>
<dd><p>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.
</p>
</dd>
<dt><code>depth</code></dt>
<dd><p>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.
</p></dd>
</dl>
<hr>
<a name="Machine-state"></a>
<div class="header">
<p>
Next: <a href="#Boot-information-format" accesskey="n" rel="next">Boot information format</a>, Previous: <a href="#OS-image-format" accesskey="p" rel="previous">OS image format</a>, Up: <a href="#Specification" accesskey="u" rel="up">Specification</a> [<a href="Index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Index.html#Index" title="Index" rel="index">Index</a>]</p>
</div>
<a name="Machine-state-1"></a>
<h3 class="section">3.2 Machine state</h3>
<p>When the boot loader invokes the 32-bit operating system, the machine
must have the following state:
</p>
<dl compact="compact">
<dt>‘<samp>EAX</samp>’</dt>
<dd><p>Must contain the magic value ‘<samp>0x2BADB002</samp>’; 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).
</p>
</dd>
<dt>‘<samp>EBX</samp>’</dt>
<dd><p>Must contain the 32-bit physical address of the Multiboot
information structure provided by the boot loader (see <a href="#Boot-information-format">Boot information format</a>).
</p>
</dd>
<dt>‘<samp>CS</samp>’</dt>
<dd><p>Must be a 32-bit read/execute code segment with an offset of ‘<samp>0</samp>’
and a limit of ‘<samp>0xFFFFFFFF</samp>’. The exact value is undefined.
</p>
</dd>
<dt>‘<samp>DS</samp>’</dt>
<dt>‘<samp>ES</samp>’</dt>
<dt>‘<samp>FS</samp>’</dt>
<dt>‘<samp>GS</samp>’</dt>
<dt>‘<samp>SS</samp>’</dt>
<dd><p>Must be a 32-bit read/write data segment with an offset of ‘<samp>0</samp>’
and a limit of ‘<samp>0xFFFFFFFF</samp>’. The exact values are all undefined.
</p>
</dd>
<dt>‘<samp>A20 gate</samp>’</dt>
<dd><p>Must be enabled.
</p>
</dd>
<dt>‘<samp>CR0</samp>’</dt>
<dd><p>Bit 31 (PG) must be cleared. Bit 0 (PE) must be set. Other bits are
all undefined.
</p>
</dd>
<dt>‘<samp>EFLAGS</samp>’</dt>
<dd><p>Bit 17 (VM) must be cleared. Bit 9 (IF) must be cleared. Other bits
are all undefined.
</p></dd>
</dl>
<p>All other processor registers and flag bits are undefined. This
includes, in particular:
</p>
<dl compact="compact">
<dt>‘<samp>ESP</samp>’</dt>
<dd><p>The OS image must create its own stack as soon as it needs one.
</p>
</dd>
<dt>‘<samp>GDTR</samp>’</dt>
<dd><p>Even though the segment registers are set up as described above, the
‘<samp>GDTR</samp>’ 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</samp>’.
</p>
</dd>
<dt>‘<samp>IDTR</samp>’</dt>
<dd><p>The OS image must leave interrupts disabled until it sets up its own
<code>IDT</code>.
</p></dd>
</dl>
<p>However, other machine state should be left by the boot loader in
<em>normal working order</em>, i.e. as initialized by the <small>BIOS</small> (or
DOS, if that’s what the boot loader runs from). In other words, the
operating system should be able to make <small>BIOS</small> calls and such after
being loaded, as long as it does not overwrite the <small>BIOS</small> data
structures before doing so. Also, the boot loader must leave the
<small>PIC</small> programmed with the normal <small>BIOS</small>/DOS values, even if it
changed them during the switch to 32-bit mode.
</p>
<hr>
<a name="Boot-information-format"></a>
<div class="header">
<p>
Previous: <a href="#Machine-state" accesskey="p" rel="previous">Machine state</a>, Up: <a href="#Specification" accesskey="u" rel="up">Specification</a> [<a href="Index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Index.html#Index" title="Index" rel="index">Index</a>]</p>
</div>
<a name="Boot-information-format-1"></a>
<h3 class="section">3.3 Boot information format</h3>
<p>FIXME: Split this chapter like the chapter “OS image format”.
</p>
<p>Upon entry to the operating system, the <code>EBX</code> register contains the
physical address of a <em>Multiboot information</em> 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.
</p>
<p>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.
</p>
<p>The format of the Multiboot information structure (as defined so far)
follows:
</p>
<div class="example">
<pre class="example"> +-------------------+
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)
+-------------------+
52 | drives_length | (present if flags[7] is set)
56 | drives_addr | (present if flags[7] is set)
+-------------------+
60 | config_table | (present if flags[8] is set)
+-------------------+
64 | boot_loader_name | (present if flags[9] is set)
+-------------------+
68 | apm_table | (present if flags[10] is set)
+-------------------+
72 | vbe_control_info | (present if flags[11] is set)
76 | vbe_mode_info |
80 | vbe_mode |
82 | vbe_interface_seg |
84 | vbe_interface_off |
86 | vbe_interface_len |
+-------------------+
88 | framebuffer_addr | (present if flags[12] is set)
96 | framebuffer_pitch |
100 | framebuffer_width |
104 | framebuffer_height|
108 | framebuffer_bpp |
109 | framebuffer_type |
110-115 | color_info |
+-------------------+
</pre></div>
<p>The first longword indicates the presence and validity of other fields
in the Multiboot information structure. All as-yet-undefined bits must
be set to zero by the boot loader. Any set bits that the operating
system does not understand should be ignored. Thus, the ‘<samp>flags</samp>’
field also functions as a version indicator, allowing the Multiboot
information structure to be expanded in the future without breaking
anything.
</p>
<p>If bit 0 in the ‘<samp>flags</samp>’ word is set, then the ‘<samp>mem_*</samp>’ fields
are valid. ‘<samp>mem_lower</samp>’ and ‘<samp>mem_upper</samp>’ indicate the amount of
lower and upper memory, respectively, in kilobytes. Lower memory starts
at address 0, and upper memory starts at address 1 megabyte. The maximum
possible value for lower memory is 640 kilobytes. The value returned for
upper memory is maximally the address of the first upper memory hole
minus 1 megabyte. It is not guaranteed to be this value.
</p>
<p>If bit 1 in the ‘<samp>flags</samp>’ word is set, then the ‘<samp>boot_device</samp>’
field is valid, and indicates which <small>BIOS</small> disk device the boot
loader loaded the OS image from. If the OS image was not loaded from a
<small>BIOS</small> disk, then this field must not be present (bit 3 must be
clear). The operating system may use this field as a hint for
determining its own <em>root</em> device, but is not required to. The
‘<samp>boot_device</samp>’ field is laid out in four one-byte subfields as
follows:
</p>
<div class="example">
<pre class="example">+-------+-------+-------+-------+
| part3 | part2 | part1 | drive |
+-------+-------+-------+-------+
Least significant Most significant
</pre></div>
<p>The most significant byte contains the <small>BIOS</small> drive number
as understood by the
<small>BIOS</small> INT 0x13 low-level disk interface: e.g. 0x00 for the first
floppy disk or 0x80 for the first hard disk.
</p>
<p>The three remaining bytes specify the boot partition. ‘<samp>part1</samp>’
specifies the <em>top-level</em> partition number, ‘<samp>part2</samp>’ specifies a
<em>sub-partition</em> in the top-level partition, etc. Partition numbers
always start from zero. Unused partition bytes must be set to 0xFF. For
example, if the disk is partitioned using a simple one-level DOS
partitioning scheme, then ‘<samp>part1</samp>’ contains the DOS partition
number, and ‘<samp>part2</samp>’ and ‘<samp>part3</samp>’ are both 0xFF. As another
example, if a disk is partitioned first into DOS partitions, and then
one of those DOS partitions is subdivided into several BSD partitions
using BSD’s <em>disklabel</em> strategy, then ‘<samp>part1</samp>’ contains the DOS
partition number, ‘<samp>part2</samp>’ contains the BSD sub-partition within
that DOS partition, and ‘<samp>part3</samp>’ is 0xFF.
</p>
<p>DOS extended partitions are indicated as partition numbers starting from
4 and 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
partition on a disk partitioned in conventional DOS style, then
‘<samp>part1</samp>’ will be 5, and ‘<samp>part2</samp>’ and ‘<samp>part3</samp>’ will both be
0xFF.
</p>
<p>If bit 2 of the ‘<samp>flags</samp>’ longword is set, the ‘<samp>cmdline</samp>’ field
is valid, and contains the physical address of the command line to
be passed to the kernel. The command line is a normal C-style
zero-terminated string. The exact format of command line is left to
OS developpers. General-purpose boot loaders should allow user a complete
control on command line independently of other factors like image name.
Boot loaders with specific payload in mind may completely or partially generate
it algorithmically.
</p>
<p>If bit 3 of the ‘<samp>flags</samp>’ is set, then the ‘<samp>mods</samp>’ fields
indicate to the kernel what boot modules were loaded along with the
kernel image, and where they can be found. ‘<samp>mods_count</samp>’ contains
the number of modules loaded; ‘<samp>mods_addr</samp>’ contains the physical
address of the first module structure. ‘<samp>mods_count</samp>’ may be zero,
indicating no boot modules were loaded, even if bit 3 of ‘<samp>flags</samp>’ is
set. Each module structure is formatted as follows:
</p>
<div class="example">
<pre class="example"> +-------------------+
0 | mod_start |
4 | mod_end |
+-------------------+
8 | string |
+-------------------+
12 | reserved (0) |
+-------------------+
</pre></div>
<p>The first two fields contain the start and end addresses of the boot
module itself. The ‘<samp>string</samp>’ field provides an arbitrary string to
be associated with that particular boot module; it is a zero-terminated
ASCII string, just like the kernel command line. The ‘<samp>string</samp>’ field
may be 0 if there is no string associated with the module. Typically the
string might be a command line (e.g. if the operating system treats boot
modules as executable programs), or a pathname (e.g. if the operating
system treats boot modules as files in a file system), but its exact use
is specific to the operating system. The ‘<samp>reserved</samp>’ field must be
set to 0 by the boot loader and ignored by the operating system.
</p>
<p><strong>Caution:</strong> Bits 4 & 5 are mutually exclusive.
</p>
<p>If bit 4 in the ‘<samp>flags</samp>’ word is set, then the following fields in
the Multiboot information structure starting at byte 28 are valid:
</p>
<div class="example">
<pre class="example"> +-------------------+
28 | tabsize |
32 | strsize |
36 | addr |
40 | reserved (0) |
+-------------------+
</pre></div>
<p>These indicate where the symbol table from an a.out kernel image can be
found. ‘<samp>addr</samp>’ is the physical address of the size (4-byte unsigned
long) of an array of a.out format <em>nlist</em> structures, followed
immediately by the array itself, then the size (4-byte unsigned long) of
a set of zero-terminated <small>ASCII</small> strings (plus sizeof(unsigned long) in
this case), and finally the set of strings itself. ‘<samp>tabsize</samp>’ is
equal to its size parameter (found at the beginning of the symbol
section), and ‘<samp>strsize</samp>’ is equal to its size parameter (found at
the beginning of the string section) of the following string table to
which the symbol table refers. Note that ‘<samp>tabsize</samp>’ may be 0,
indicating no symbols, even if bit 4 in the ‘<samp>flags</samp>’ word is set.
</p>
<p>If bit 5 in the ‘<samp>flags</samp>’ word is set, then the following fields in
the Multiboot information structure starting at byte 28 are valid:
</p>
<div class="example">
<pre class="example"> +-------------------+
28 | num |
32 | size |
36 | addr |
40 | shndx |
+-------------------+
</pre></div>
<p>These indicate where the section header table from an ELF kernel is, the
size of each entry, number of entries, and the string table used as the
index of names. They correspond to the ‘<samp>shdr_*</samp>’ entries
(‘<samp>shdr_num</samp>’, etc.) in the Executable and Linkable Format (<small>ELF</small>)
specification in the program header. All sections are loaded, and the
physical address fields of the <small>ELF</small> section header then refer to where
the sections are in memory (refer to the i386 <small>ELF</small> documentation for
details as to how to read the section header(s)). Note that
‘<samp>shdr_num</samp>’ may be 0, indicating no symbols, even if bit 5 in the
‘<samp>flags</samp>’ word is set.
</p>
<p>If bit 6 in the ‘<samp>flags</samp>’ word is set, then the ‘<samp>mmap_*</samp>’ fields
are valid, and indicate the address and length of a buffer containing a
memory map of the machine provided by the <small>BIOS</small>. ‘<samp>mmap_addr</samp>’ is
the address, and ‘<samp>mmap_length</samp>’ is the total size of the buffer. The
buffer consists of one or more of the following size/structure pairs
(‘<samp>size</samp>’ is really used for skipping to the next pair):
</p>
<div class="example">
<pre class="example"> +-------------------+
-4 | size |
+-------------------+
0 | base_addr |
8 | length |
16 | type |
+-------------------+
</pre></div>
<p>where ‘<samp>size</samp>’ is the size of the associated structure in bytes, which
can be greater than the minimum of 20 bytes. ‘<samp>base_addr</samp>’ is the
starting address. ‘<samp>length</samp>’ is the size of the memory region in bytes.
‘<samp>type</samp>’ is the variety of address range represented, where a
value of 1 indicates available <small>RAM</small>, value of 3 indicates usable memory
holding ACPI information, value of 4 indicates reserved memory which needs to
be preserved on hibernation, value of 5 indicates a memory which is occupied by defective RAM modules and all other values currently
indicated a reserved area.
</p>
<p>The map provided is guaranteed to list all standard <small>RAM</small> that should
be available for normal use.
</p>
<p>If bit 7 in the ‘<samp>flags</samp>’ is set, then the ‘<samp>drives_*</samp>’ fields
are valid, and indicate the address of the physical address of the first
drive structure and the size of drive structures. ‘<samp>drives_addr</samp>’
is the address, and ‘<samp>drives_length</samp>’ is the total size of drive
structures. Note that ‘<samp>drives_length</samp>’ may be zero. Each drive
structure is formatted as follows:
</p>
<div class="example">
<pre class="example"> +-------------------+
0 | size |
+-------------------+
4 | drive_number |
+-------------------+
5 | drive_mode |
+-------------------+
6 | drive_cylinders |
8 | drive_heads |
9 | drive_sectors |
+-------------------+
10 - xx | drive_ports |
+-------------------+
</pre></div>
<p>The ‘<samp>size</samp>’ field specifies the size of this structure. The size
varies, depending on the number of ports. Note that the size may not be
equal to (10 + 2 * the number of ports), because of an alignment.
</p>
<p>The ‘<samp>drive_number</samp>’ field contains the BIOS drive number. The
‘<samp>drive_mode</samp>’ field represents the access mode used by the boot
loader. Currently, the following modes are defined:
</p>
<dl compact="compact">
<dt>‘<samp>0</samp>’</dt>
<dd><p>CHS mode (traditional cylinder/head/sector addressing mode).
</p>
</dd>
<dt>‘<samp>1</samp>’</dt>
<dd><p>LBA mode (Logical Block Addressing mode).
</p></dd>
</dl>
<p>The three fields, ‘<samp>drive_cylinders</samp>’, ‘<samp>drive_heads</samp>’ and
‘<samp>drive_sectors</samp>’, indicate the geometry of the drive detected by the
<small>BIOS</small>. ‘<samp>drive_cylinders</samp>’ contains the number of the
cylinders. ‘<samp>drive_heads</samp>’ contains the number of the
heads. ‘<samp>drive_sectors</samp>’ contains the number of the sectors per
track.
</p>
<p>The ‘<samp>drive_ports</samp>’ field contains the array of the I/O ports used
for the drive in the <small>BIOS</small> code. The array consists of zero or more
unsigned two-bytes integers, and is terminated with zero. Note that the
array may contain any number of I/O ports that are not related to the
drive actually (such as <small>DMA</small> controller’s ports).
</p>
<p>If bit 8 in the ‘<samp>flags</samp>’ is set, then the ‘<samp>config_table</samp>’ field
is valid, and indicates the address of the <small>ROM</small> configuration table
returned by the <em>GET CONFIGURATION</em> <small>BIOS</small> call. If the <small>BIOS</small>
call fails, then the size of the table must be <em>zero</em>.
</p>
<p>If bit 9 in the ‘<samp>flags</samp>’ is set, the ‘<samp>boot_loader_name</samp>’ field
is valid, and contains the physical address of the name of a boot
loader booting the kernel. The name is a normal C-style zero-terminated
string.
</p>
<p>If bit 10 in the ‘<samp>flags</samp>’ is set, the ‘<samp>apm_table</samp>’ field is
valid, and contains the physical address of an <small>APM</small> table defined as
below:
</p>
<div class="example">
<pre class="example"> +----------------------+
0 | version |
2 | cseg |
4 | offset |
8 | cseg_16 |
10 | dseg |
12 | flags |
14 | cseg_len |
16 | cseg_16_len |
18 | dseg_len |
+----------------------+
</pre></div>
<p>The fields ‘<samp>version</samp>’, ‘<samp>cseg</samp>’, ‘<samp>offset</samp>’, ‘<samp>cseg_16</samp>’,
‘<samp>dseg</samp>’, ‘<samp>flags</samp>’, ‘<samp>cseg_len</samp>’, ‘<samp>cseg_16_len</samp>’,
‘<samp>dseg_len</samp>’ indicate the version number, the protected mode 32-bit
code segment, the offset of the entry point, the protected mode 16-bit
code segment, the protected mode 16-bit data segment, the flags, the
length of the protected mode 32-bit code segment, the length of the
protected mode 16-bit code segment, and the length of the protected mode
16-bit data segment, respectively. Only the field ‘<samp>offset</samp>’ is 4
bytes, and the others are 2 bytes. See
<a href="http://www.microsoft.com/hwdev/busbios/amp_12.htm">Advanced Power
Management (APM) BIOS Interface Specification</a>, for more information.
</p>
<p>If bit 11 in the ‘<samp>flags</samp>’ is set, the <small>VBE</small> table is available.
</p>
<p>The fields ‘<samp>vbe_control_info</samp>’ and ‘<samp>vbe_mode_info</samp>’ contain
the physical addresses of <small>VBE</small> control information returned by the
<small>VBE</small> Function 00h and <small>VBE</small> mode information returned by the
<small>VBE</small> Function 01h, respectively.
</p>
<p>The field ‘<samp>vbe_mode</samp>’ indicates current video mode in the format
specified in <small>VBE</small> 3.0.
</p>
<p>The rest fields ‘<samp>vbe_interface_seg</samp>’, ‘<samp>vbe_interface_off</samp>’, and
‘<samp>vbe_interface_len</samp>’ contain the table of a protected mode interface
defined in <small>VBE</small> 2.0+. If this information is not available, those
fields contain zero. Note that <small>VBE</small> 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.
</p>
<p>The fields for the graphics table are designed for <small>VBE</small>, but
Multiboot boot loaders may simulate <small>VBE</small> on non-<small>VBE</small> modes, as
if they were <small>VBE</small> modes.
</p>
<p>If bit 12 in the ‘<samp>flags</samp>’ is set, the <small>FRAMEBUFFER</small> table is available.
</p>
<p>The field ‘<samp>framebuffer_addr</samp>’ contains framebuffer physical address. This
field is 64-bit wide but bootloader <em>should</em> set it under 4 GiB if possible
for compatibility with kernels which aren’t aware of PAE or AMD64. The field
‘<samp>framebuffer_pitch</samp>’ contains the framebuffer pitch in bytes. The fields
‘<samp>framebuffer_width</samp>’, ‘<samp>framebuffer_height</samp>’ contain the framebuffer
dimensions in pixels. The field ‘<samp>framebuffer_bpp</samp>’ contains the number of
bits per pixel. If ‘<samp>framebuffer_type</samp>’ is set to ‘<samp>0</samp>’ it means
indexed color will be used. In this case color_info is defined as follows:
</p><div class="example">
<pre class="example"> +----------------------------------+
110 | framebuffer_palette_addr |
114 | framebuffer_palette_num_colors |
+----------------------------------+
</pre></div>
<p>‘<samp>framebuffer_palette_addr</samp>’ contains the address of the color palette,
which is an array of color descriptors. Each color descriptor has the
following structure:
</p><div class="example">
<pre class="example"> +-------------+
0 | red_value |
1 | green_value |
2 | blue_value |
+-------------+
</pre></div>
<p>If ‘<samp>framebuffer_type</samp>’ is set to ‘<samp>1</samp>’ it means direct RGB color will
be used. Then color_type is defined as follows:
</p>
<div class="example">
<pre class="example"> +----------------------------------+
110 | framebuffer_red_field_position |
111 | framebuffer_red_mask_size |
112 | framebuffer_green_field_position |
113 | framebuffer_green_mask_size |
114 | framebuffer_blue_field_position |
115 | framebuffer_blue_mask_size |
+----------------------------------+
</pre></div>
<p>If ‘<samp>framebuffer_type</samp>’ is set to ‘<samp>2</samp>’ it means EGA-standard text mode
will be used. In this case ‘<samp>framebuffer_width</samp>’ and
‘<samp>framebuffer_height</samp>’ are expressed in characters instead of pixels.
‘<samp>framebuffer_bpp</samp>’ is equal to 16 (bits per character) and
‘<samp>framebuffer_pitch</samp>’ is expressed in bytes per text line.
All further values of ‘<samp>framebuffer_type</samp>’ are reserved for future expansion.
</p>
<hr>
<div class="header">
<p>
Previous: <a href="#Machine-state" accesskey="p" rel="previous">Machine state</a>, Up: <a href="#Specification" accesskey="u" rel="up">Specification</a> [<a href="Index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Index.html#Index" title="Index" rel="index">Index</a>]</p>
</div>
</body>
</html>
|