1N/AINFO-DIR-SECTION Kernel
1N/A* Multiboot Specification: (multiboot). Multiboot Specification.
1N/A Copyright (C) 1995, 96 Bryan Ford <baford@cs.utah.edu> Copyright (C)
1N/A1995, 96 Erich Stefan Boleyn <erich@uruk.org> Copyright (C) 1999, 2000,
1N/A2001, 2002 Free Software Foundation, Inc.
1N/A Permission is granted to make and distribute verbatim copies of this
1N/Amanual provided the copyright notice and this permission notice are
1N/Apreserved on all copies.
1N/A Permission is granted to copy and distribute modified versions of
1N/Athis manual under the conditions for verbatim copying, provided also
1N/Athat the entire resulting derived work is distributed under the terms
1N/Aof a permission notice identical to this one.
1N/A Permission is granted to copy and distribute translations of this
1N/Amanual into another language, under the above conditions for modified
1N/AMultiboot Specification
1N/A***********************
1N/AThis file documents Multiboot Specification, the proposal for the boot
1N/Asequence standard. This edition documents version 0.6.93.
1N/A1 Introduction to Multiboot Specification
1N/A*****************************************
1N/AThis chapter describes some rough information on the Multiboot
1N/ASpecification. Note that this is not a part of the specification itself.
1N/A* Operating systems::
1N/A* Boot-time configuration::
1N/A* Convenience to operating systems::
1N/A1.1 The background of Multiboot Specification
1N/A=============================================
1N/AEvery operating system ever created tends to have its own boot loader.
1N/AInstalling a new operating system on a machine generally involves
1N/Ainstalling a whole new set of boot mechanisms, each with completely
1N/Adifferent install-time and boot-time user interfaces. Getting multiple
1N/Aoperating systems to coexist reliably on one machine through typical
1N/A"chaining" mechanisms can be a nightmare. There is little or no choice
1N/Aof boot loaders for a particular operating system -- if the one that
1N/Acomes with the operating system doesn't do exactly what you want, or
1N/Adoesn't work on your machine, you're screwed.
1N/A While we may not be able to fix this problem in existing commercial
1N/Aoperating systems, it shouldn't be too difficult for a few people in the
1N/Afree operating system communities to put their heads together and solve
1N/Athis problem for the popular free operating systems. That's what this
1N/Aspecification aims for. Basically, it specifies an interface between a
1N/Aboot loader and a operating system, such that any complying boot loader
1N/Ashould be able to load any complying operating system. This
1N/Aspecification does _not_ specify how boot loaders should work -- only
1N/Ahow they must interface with the operating system being loaded.
1N/AFile:
multiboot.info, Node: Architecture, Next: Operating systems, Prev: Motivation, Up: Overview
1N/A1.2 The target architecture
1N/A===========================
1N/AThis specification is primarily targeted at PC, since they are the most
1N/Acommon and have the largest variety of operating systems and boot
1N/Aloaders. However, to the extent that certain other architectures may
1N/Aneed a boot specification and do not have one already, a variation of
1N/Athis specification, stripped of the x86-specific details, could be
1N/Aadopted for them as well.
1N/AFile:
multiboot.info, Node: Operating systems, Next: Boot sources, Prev: Architecture, Up: Overview
1N/A1.3 The target operating systems
1N/A================================
1N/AThis specification is targeted toward free 32-bit operating systems
1N/Athat can be fairly easily modified to support the specification without
1N/Agoing through lots of bureaucratic rigmarole. The particular free
1N/Aoperating systems that this specification is being primarily designed
1N/Afor are Linux, FreeBSD, NetBSD, Mach, and VSTa. It is hoped that other
1N/Aemerging free operating systems will adopt it from the start, and thus
1N/Aimmediately be able to take advantage of existing boot loaders. It would
1N/Abe nice if commercial operating system vendors eventually adopted this
1N/Aspecification as well, but that's probably a pipe dream.
1N/AFile:
multiboot.info, Node: Boot sources, Next: Boot-time configuration, Prev: Operating systems, Up: Overview
1N/AIt should be possible to write compliant boot loaders that load the OS
1N/Aimage from a variety of sources, including floppy disk, hard disk, and
1N/A Disk-based boot loaders may use a variety of techniques to find the
1N/Arelevant OS image and boot module data on disk, such as by
1N/Ausing precalculated "block lists" (
e.g. LILO), loading from a special
1N/A"boot partition" (
e.g. OS/2), or even loading from within another
1N/Aoperating system (
e.g. the VSTa boot code, which loads from DOS).
1N/ASimilarly, network-based boot loaders could use a variety of network
1N/Ahardware and protocols.
1N/A It is hoped that boot loaders will be created that support multiple
1N/Aloading mechanisms, increasing their portability, robustness, and
1N/AFile:
multiboot.info, Node: Boot-time configuration, Next: Convenience to operating systems, Prev: Boot sources, Up: Overview
1N/A1.5 Configure an operating system at boot-time
1N/A==============================================
1N/AIt is often necessary for one reason or another for the user to be able
1N/Ato provide some configuration information to an operating system
1N/Adynamically at boot time. While this specification should not dictate
1N/Ahow this configuration information is obtained by the boot loader, it
1N/Ashould provide a standard means for the boot loader to pass such
1N/Ainformation to the operating system.
1N/AFile:
multiboot.info, Node: Convenience to operating systems, Next: Boot modules, Prev: Boot-time configuration, Up: Overview
1N/A1.6 How to make OS development easier
1N/A=====================================
1N/AOS images should be easy to generate. Ideally, an OS image should simply
1N/Abe an ordinary 32-bit executable file in whatever file format the
1N/Aoperating system normally uses. It should be possible to `nm' or
1N/Adisassemble OS images just like normal executables. Specialized tools
1N/Ashould not be required to create OS images in a _special_ file format.
1N/AIf this means shifting some work from the operating system to a boot
1N/Aloader, that is probably appropriate, because all the memory consumed
1N/Aby the boot loader will typically be made available again after the
1N/Aboot process is created, whereas every bit of code in the OS image
1N/Atypically has to remain in memory forever. The operating system should
1N/Anot have to worry about getting into 32-bit mode initially, because mode
1N/Aswitching code generally needs to be in the boot loader anyway in order
1N/Ato load operating system data above the 1MB boundary, and forcing the
1N/Aoperating system to do this makes creation of OS images much more
1N/A Unfortunately, there is a horrendous variety of executable file
1N/Aformats even among free Unix-like PC-based operating systems --
1N/Agenerally a different format for each operating system. Most of the
1N/Arelevant free operating systems use some variant of
a.out format, but
1N/Asome are moving to ELF. It is highly desirable for boot loaders not to
1N/Ahave to be able to interpret all the different types of executable file
1N/Aformats in existence in order to load the OS image -- otherwise the
1N/Aboot loader effectively becomes operating system specific again.
1N/A This specification adopts a compromise solution to this problem.
1N/AMultiboot-compliant OS images always contain a magic "Multiboot header"
1N/A(*note OS image format::), which allows the boot loader to load the
1N/Aimage without having to understand numerous
a.out variants or other
1N/Aexecutable formats. This magic header does not need to be at the very
1N/Abeginning of the executable file, so kernel images can still conform to
1N/Athe local
a.out format variant in addition to being Multiboot-compliant.
1N/AFile:
multiboot.info, Node: Boot modules, Prev: Convenience to operating systems, Up: Overview
1N/AMany modern operating system kernels, such as those of VSTa and Mach, do
1N/Anot by themselves contain enough mechanism to get the system fully
1N/Aoperational: they require the presence of additional software modules at
1N/Aboot time in order to access devices, mount file systems, etc. While
1N/Athese additional modules could be embedded in the main OS image along
1N/Awith the kernel itself, and the resulting image be split apart manually
1N/Aby the operating system when it receives control, it is often more
1N/Aflexible, more space-efficient, and more convenient to the operating
1N/Asystem and user if the boot loader can load these additional modules
1N/Aindependently in the first place.
1N/A Thus, this specification should provide a standard method for a boot
1N/Aloader to indicate to the operating system what auxiliary boot modules
1N/Awere loaded, and where they can be found. Boot loaders don't have to
1N/Asupport multiple boot modules, but they are strongly encouraged to,
1N/Abecause some operating systems will be unable to boot without them.
1N/A2 The definitions of terms used through the specification
1N/A*********************************************************
1N/A We use the term "must", when any boot loader or OS image needs to
1N/A follow a rule -- otherwise, the boot loader or OS image is _not_
1N/A Multiboot-compliant.
1N/A We use the term "should", when any boot loader or OS image is
1N/A recommended to follow a rule, but it doesn't need to follow the
1N/A We use the term "may", when any boot loader or OS image is allowed
1N/A Whatever program or set of programs loads the image of the final
1N/A operating system to be run on the machine. The boot loader may
1N/A itself consist of several stages, but that is an implementation
1N/A detail not relevant to this specification. Only the _final_ stage
1N/A of the boot loader -- the stage that eventually transfers control
1N/A to an operating system -- must follow the rules specified in this
1N/A document in order to be "Multiboot-compliant"; earlier boot loader
1N/A stages may be designed in whatever way is most convenient.
1N/A The initial binary image that a boot loader loads into memory and
1N/A transfers control to start an operating system. The OS image is
1N/A typically an executable containing the operating system kernel.
1N/A Other auxiliary files that a boot loader loads into memory along
1N/A with an OS image, but does not interpret in any way other than
1N/A passing their locations to the operating system when it is invoked.
1N/A"Multiboot-compliant"
1N/A A boot loader or an OS image which follows the rules defined as
1N/A "must" is Multiboot-compliant. When this specification specifies a
1N/A rule as "should" or "may", a Multiboot-complaint boot
loader/OS 1N/A image doesn't need to follow the rule.
1N/A The type of unsigned 8-bit data.
1N/A The type of unsigned 16-bit data. Because the target architecture
1N/A is little-endian, u16 is coded in little-endian.
1N/A The type of unsigned 32-bit data. Because the target architecture
1N/A is little-endian, u32 is coded in little-endian.
1N/A The type of unsigned 64-bit data. Because the target architecture
1N/A is little-endian, u64 is coded in little-endian.
1N/A3 The exact definitions of Multiboot Specification
1N/A**************************************************
1N/AThere are three main aspects of a boot
loader/OS image interface:
1N/A 1. The format of an OS image as seen by a boot loader.
1N/A 2. The state of a machine when a boot loader starts an operating
1N/A 3. The format of information passed by a boot loader to an operating
1N/A* Boot information format::
1N/AAn OS image may be an ordinary 32-bit executable file in the standard
1N/Aformat for that particular operating system, except that it may be
1N/Alinked at a non-default load address to avoid loading on top of the
1N/APC's I/O region or other reserved areas, and of course it should not
1N/Ause shared libraries or other fancy features.
1N/A An OS image must contain an additional header called "Multiboot
1N/Aheader", besides the headers of the format used by the OS image. The
1N/AMultiboot header must be contained completely within the first 8192
1N/Abytes of the OS image, and must be longword (32-bit) aligned. In
1N/Ageneral, it should come _as early as possible_, and may be embedded in
1N/Athe beginning of the text segment after the _real_ executable header.
1N/A* Header layout:: The layout of Multiboot header
1N/A* Header magic fields:: The magic fields of Multiboot header
1N/A* Header address fields::
1N/A* Header graphics fields::
1N/AFile:
multiboot.info, Node: Header layout, Next: Header magic fields, Up: OS image format
1N/A3.1.1 The layout of Multiboot header
1N/A------------------------------------
1N/AThe layout of the Multiboot header must be as follows:
1N/AOffset Type Field Name Note
1N/A8 u32 checksum required
1N/A12 u32 header_addr if flags[16] is set
1N/A16 u32 load_addr if flags[16] is set
1N/A20 u32 load_end_addr if flags[16] is set
1N/A24 u32 bss_end_addr if flags[16] is set
1N/A28 u32 entry_addr if flags[16] is set
1N/A32 u32 mode_type if flags[2] is set
1N/A36 u32 width if flags[2] is set
1N/A40 u32 height if flags[2] is set
1N/A44 u32 depth if flags[2] is set
1N/A The fields `magic', `flags' and `checksum' are defined in *Note
1N/AHeader magic fields::, the fields `header_addr', `load_addr',
1N/A`load_end_addr', `bss_end_addr' and `entry_addr' are defined in *Note
1N/AHeader address fields::, and the fields `mode_type', `width', `height'
1N/Aand `depth' are defind in *Note Header graphics fields::.
1N/AFile:
multiboot.info, Node: Header magic fields, Next: Header address fields, Prev: Header layout, Up: OS image format
1N/A3.1.2 The magic fields of Multiboot header
1N/A------------------------------------------
1N/A The field `magic' is the magic number identifying the header,
1N/A which must be the hexadecimal value `0x1BADB002'.
1N/A The field `flags' specifies features that the OS image requests or
1N/A requires of an boot loader. Bits 0-15 indicate requirements; if the
1N/A boot loader sees any of these bits set but doesn't understand the
1N/A flag or can't fulfill the requirements it indicates for some
1N/A reason, it must notify the user and fail to load the OS image.
1N/A Bits 16-31 indicate optional features; if any bits in this range
1N/A are set but the boot loader doesn't understand them, it may simply
1N/A ignore them and proceed as usual. Naturally, all as-yet-undefined
1N/A bits in the `flags' word must be set to zero in OS images. This
1N/A way, the `flags' fields serves for version control as well as
1N/A simple feature selection.
1N/A If bit 0 in the `flags' word is set, then all boot modules loaded
1N/A along with the operating system must be aligned on page (4KB)
1N/A boundaries. Some operating systems expect to be able to map the
1N/A pages containing boot modules directly into a paged address space
1N/A during startup, and thus need the boot modules to be page-aligned.
1N/A If bit 1 in the `flags' word is set, then information on available
1N/A memory via at least the `mem_*' fields of the Multiboot information
1N/A structure (*note Boot information format::) must be included. If
1N/A the boot loader is capable of passing a memory map (the `mmap_*'
1N/A fields) and one exists, then it may be included as well.
1N/A If bit 2 in the `flags' word is set, information about the video
1N/A mode table (*note Boot information format::) must be available to
1N/A If bit 16 in the `flags' word is set, then the fields at offsets
1N/A 8-24 in the Multiboot header are valid, and the boot loader should
1N/A use them instead of the fields in the actual executable header to
1N/A calculate where to load the OS image. This information does not
1N/A need to be provided if the kernel image is in ELF format, but it
1N/A _must_ be provided if the images is in
a.out format or in some
1N/A other format. Compliant boot loaders must be able to load images
1N/A that either are in ELF format or contain the load address
1N/A information embedded in the Multiboot header; they may also
1N/A directly support other executable formats, such as particular
1N/A a.out variants, but are not required to.
1N/A The field `checksum' is a 32-bit unsigned value which, when added
1N/A to the other magic fields (
i.e. `magic' and `flags'), must have a
1N/A 32-bit unsigned sum of zero.
1N/AFile:
multiboot.info, Node: Header address fields, Next: Header graphics fields, Prev: Header magic fields, Up: OS image format
1N/A3.1.3 The address fields of Multiboot header
1N/A--------------------------------------------
1N/AAll of the address fields enabled by flag bit 16 are physical addresses.
1N/AThe meaning of each is as follows:
1N/A Contains the address corresponding to the beginning of the
1N/A Multiboot header -- the physical memory location at which the
1N/A magic value is supposed to be loaded. This field serves to
1N/A "synchronize" the mapping between OS image offsets and physical
1N/A Contains the physical address of the beginning of the text
1N/A segment. The offset in the OS image file at which to start loading
1N/A is defined by the offset at which the header was found, minus
1N/A (header_addr - load_addr). load_addr must be less than or equal to
1N/A Contains the physical address of the end of the data segment.
1N/A (load_end_addr - load_addr) specifies how much data to load. This
1N/A implies that the text and data segments must be consecutive in the
1N/A OS image; this is true for existing
a.out executable formats. If
1N/A this field is zero, the boot loader assumes that the text and data
1N/A segments occupy the whole OS image file.
1N/A Contains the physical address of the end of the bss segment. The
1N/A boot loader initializes this area to zero, and reserves the memory
1N/A it occupies to avoid placing boot modules and other data relevant
1N/A to the operating system in that area. If this field is zero, the
1N/A boot loader assumes that no bss segment is present.
1N/A The physical address to which the boot loader should jump in order
1N/A to start running the operating system.
1N/AFile:
multiboot.info, Node: Header graphics fields, Prev: Header address fields, Up: OS image format
1N/A3.1.4 The graphics fields of Multiboot header
1N/A---------------------------------------------
1N/AAll of the graphics fields are enabled by flag bit 2. They specify the
1N/Apreferred graphics mode. Note that that is only a _recommended_ mode by
1N/Athe OS image. If the mode exists, the boot loader should set it, when
1N/Athe user doesn't specify a mode explicitly. Otherwise, the boot loader
1N/Ashould fall back to a similar mode, if available.
1N/A The meaning of each is as follows:
1N/A Contains `0' for linear graphics mode or `1' for EGA-standard text
1N/A mode. Everything else is reserved for future expansion. Note that
1N/A the boot loader may set a text mode, even if this field contains
1N/A Contains the number of the columns. This is specified in pixels in
1N/A a graphics mode, and in characters in a text mode. The value zero
1N/A indicates that the OS image has no preference.
1N/A Contains the number of the lines. This is specified in pixels in a
1N/A graphics mode, and in characters in a text mode. The value zero
1N/A indicates that the OS image has no preference.
1N/A Contains the number of bits per pixel in a graphics mode, and zero
1N/A in a text mode. The value zero indicates that the OS image has no
1N/AFile:
multiboot.info, Node: Machine state, Next: Boot information format, Prev: OS image format, Up: Specification
1N/AWhen the boot loader invokes the 32-bit operating system, the machine
1N/Amust have the following state:
1N/A Must contain the magic value `0x2BADB002'; the presence of this
1N/A value indicates to the operating system that it was loaded by a
1N/A Multiboot-compliant boot loader (
e.g. as opposed to another type of
1N/A boot loader that the operating system can also be loaded from).
1N/A Must contain the 32-bit physical address of the Multiboot
1N/A information structure provided by the boot loader (*note Boot
1N/A information format::).
1N/A and a limit of `0xFFFFFFFF'. The exact value is undefined.
1N/A Must be a 32-bit
read/write data segment with an offset of `0' and
1N/A a limit of `0xFFFFFFFF'. The exact values are all undefined.
1N/A Bit 31 (PG) must be cleared. Bit 0 (PE) must be set. Other bits are
1N/A Bit 17 (VM) must be cleared. Bit 9 (IF) must be cleared. Other bits
1N/A All other processor registers and flag bits are undefined. This
1N/Aincludes, in particular:
1N/A The OS image must create its own stack as soon as it needs one.
1N/A Even though the segment registers are set up as described above,
1N/A the `GDTR' may be invalid, so the OS image must not load any
1N/A segment registers (even just reloading the same values!) until it
1N/A sets up its own `GDT'.
1N/A The OS image must leave interrupts disabled until it sets up its
1N/A However, other machine state should be left by the boot loader in
1N/A"normal working order",
i.e. as initialized by the BIOS (or DOS, if
1N/Athat's what the boot loader runs from). In other words, the operating
1N/Asystem should be able to make BIOS calls and such after being loaded,
1N/Aas long as it does not overwrite the BIOS data structures before doing
1N/Aso. Also, the boot loader must leave the PIC programmed with the normal
1N/ABIOS/DOS values, even if it changed them during the switch to 32-bit
1N/AFile:
multiboot.info, Node: Boot information format, Prev: Machine state, Up: Specification
1N/A3.3 Boot information format
1N/A===========================
1N/AFIXME: Split this chapter like the chapter "OS image format".
1N/A Upon entry to the operating system, the `EBX' register contains the
1N/Aphysical address of a "Multiboot information" data structure, through
1N/Awhich the boot loader communicates vital information to the operating
1N/Asystem. The operating system can use or ignore any parts of the
1N/Astructure as it chooses; all information passed by the boot loader is
1N/A The Multiboot information structure and its related substructures
1N/Amay be placed anywhere in memory by the boot loader (with the exception
1N/Aof the memory reserved for the kernel and boot modules, of course). It
1N/Ais the operating system's responsibility to avoid overwriting this
1N/Amemory until it is done using it.
1N/A The format of the Multiboot information structure (as defined so far)
1N/A +-------------------+
1N/A 0 | flags | (required)
1N/A +-------------------+
1N/A 4 | mem_lower | (present if flags[0] is set)
1N/A 8 | mem_upper | (present if flags[0] is set)
1N/A +-------------------+
1N/A 12 | boot_device | (present if flags[1] is set)
1N/A +-------------------+
1N/A 16 | cmdline | (present if flags[2] is set)
1N/A +-------------------+
1N/A 20 | mods_count | (present if flags[3] is set)
1N/A 24 | mods_addr | (present if flags[3] is set)
1N/A +-------------------+
1N/A 28 - 40 | syms | (present if flags[4] or
1N/A | | flags[5] is set)
1N/A +-------------------+
1N/A 44 | mmap_length | (present if flags[6] is set)
1N/A 48 | mmap_addr | (present if flags[6] is set)
1N/A +-------------------+
1N/A 52 | drives_length | (present if flags[7] is set)
1N/A 56 | drives_addr | (present if flags[7] is set)
1N/A +-------------------+
1N/A 60 | config_table | (present if flags[8] is set)
1N/A +-------------------+
1N/A 64 | boot_loader_name | (present if flags[9] is set)
1N/A +-------------------+
1N/A 68 | apm_table | (present if flags[10] is set)
1N/A +-------------------+
1N/A 72 | vbe_control_info | (present if flags[11] is set)
1N/A 76 | vbe_mode_info |
1N/A 82 | vbe_interface_seg |
1N/A 84 | vbe_interface_off |
1N/A 86 | vbe_interface_len |
1N/A +-------------------+
1N/A The first longword indicates the presence and validity of other
1N/Afields in the Multiboot information structure. All as-yet-undefined
1N/Abits must be set to zero by the boot loader. Any set bits that the
1N/Aoperating system does not understand should be ignored. Thus, the
1N/A`flags' field also functions as a version indicator, allowing the
1N/AMultiboot information structure to be expanded in the future without
1N/A If bit 0 in the `flags' word is set, then the `mem_*' fields are
1N/Avalid. `mem_lower' and `mem_upper' indicate the amount of lower and
1N/Aupper memory, respectively, in kilobytes. Lower memory starts at
1N/Aaddress 0, and upper memory starts at address 1 megabyte. The maximum
1N/Apossible value for lower memory is 640 kilobytes. The value returned for
1N/Aupper memory is maximally the address of the first upper memory hole
1N/Aminus 1 megabyte. It is not guaranteed to be this value.
1N/A If bit 1 in the `flags' word is set, then the `boot_device' field is
1N/Avalid, and indicates which BIOS disk device the boot loader loaded the
1N/AOS image from. If the OS image was not loaded from a BIOS disk, then
1N/Athis field must not be present (bit 3 must be clear). The operating
1N/Asystem may use this field as a hint for determining its own "root"
1N/Adevice, but is not required to. The `boot_device' field is laid out in
1N/Afour one-byte subfields as follows:
1N/A +-------+-------+-------+-------+
1N/A | drive | part1 | part2 | part3 |
1N/A +-------+-------+-------+-------+
1N/A The first byte contains the BIOS drive number as understood by the
1N/ABIOS INT 0x13 low-level disk interface:
e.g. 0x00 for the first floppy
1N/Adisk or 0x80 for the first hard disk.
1N/A The three remaining bytes specify the boot partition. `part1'
1N/Aspecifies the "top-level" partition number, `part2' specifies a
1N/A"sub-partition" in the top-level partition, etc. Partition numbers
1N/Aalways start from zero. Unused partition bytes must be set to 0xFF. For
1N/Aexample, if the disk is partitioned using a simple one-level DOS
1N/Apartitioning scheme, then `part1' contains the DOS partition number,
1N/Aand `part2' and `part3' are both 0xFF. As another example, if a disk is
1N/Apartitioned first into DOS partitions, and then one of those DOS
1N/Apartitions is subdivided into several BSD partitions using BSD's
1N/A"disklabel" strategy, then `part1' contains the DOS partition number,
1N/A`part2' contains the BSD sub-partition within that DOS partition, and
1N/A DOS extended partitions are indicated as partition numbers starting
1N/Afrom 4 and increasing, rather than as nested sub-partitions, even
1N/Athough the underlying disk layout of extended partitions is
1N/Ahierarchical in nature. For example, if the boot loader boots from the
1N/Asecond extended partition on a disk partitioned in conventional DOS
1N/Astyle, then `part1' will be 5, and `part2' and `part3' will both be
1N/A If bit 2 of the `flags' longword is set, the `cmdline' field is
1N/Avalid, and contains the physical address of the command line to be
1N/Apassed to the kernel. The command line is a normal C-style
1N/Azero-terminated string.
1N/A If bit 3 of the `flags' is set, then the `mods' fields indicate to
1N/Athe kernel what boot modules were loaded along with the kernel image,
1N/Aand where they can be found. `mods_count' contains the number of
1N/Amodules loaded; `mods_addr' contains the physical address of the first
1N/Amodule structure. `mods_count' may be zero, indicating no boot modules
1N/Awere loaded, even if bit 1 of `flags' is set. Each module structure is
1N/Aformatted as follows:
1N/A +-------------------+
1N/A +-------------------+
1N/A +-------------------+
1N/A +-------------------+
1N/A The first two fields contain the start and end addresses of the boot
1N/Amodule itself. The `string' field provides an arbitrary string to be
1N/Aassociated with that particular boot module; it is a zero-terminated
1N/AASCII string, just like the kernel command line. The `string' field may
1N/Abe 0 if there is no string associated with the module. Typically the
1N/Astring might be a command line (
e.g. if the operating system treats boot
1N/Amodules as executable programs), or a pathname (
e.g. if the operating
1N/Asystem treats boot modules as files in a file system), but its exact use
1N/Ais specific to the operating system. The `reserved' field must be set
1N/Ato 0 by the boot loader and ignored by the operating system.
1N/A *Caution:* Bits 4 & 5 are mutually exclusive.
1N/A If bit 4 in the `flags' word is set, then the following fields in
1N/Athe Multiboot information structure starting at byte 28 are valid:
1N/A +-------------------+
1N/A +-------------------+
1N/A These indicate where the symbol table from an
a.out kernel image can
1N/Abe found. `addr' is the physical address of the size (4-byte unsigned
1N/Along) of an array of
a.out format "nlist" structures, followed
1N/Aimmediately by the array itself, then the size (4-byte unsigned long) of
1N/Aa set of zero-terminated ASCII strings (plus sizeof(unsigned long) in
1N/Athis case), and finally the set of strings itself. `tabsize' is equal
1N/Ato its size parameter (found at the beginning of the symbol section),
1N/Aand `strsize' is equal to its size parameter (found at the beginning of
1N/Athe string section) of the following string table to which the symbol
1N/Atable refers. Note that `tabsize' may be 0, indicating no symbols, even
1N/Aif bit 4 in the `flags' word is set.
1N/A If bit 5 in the `flags' word is set, then the following fields in
1N/Athe Multiboot information structure starting at byte 28 are valid:
1N/A +-------------------+
1N/A +-------------------+
1N/A These indicate where the section header table from an ELF kernel is,
1N/Athe size of each entry, number of entries, and the string table used as
1N/Athe index of names. They correspond to the `shdr_*' entries
1N/A(`shdr_num', etc.) in the Executable and Linkable Format (ELF)
1N/Aspecification in the program header. All sections are loaded, and the
1N/Aphysical address fields of the ELF section header then refer to where
1N/Athe sections are in memory (refer to the i386 ELF documentation for
1N/Adetails as to how to read the section header(s)). Note that `shdr_num'
1N/Amay be 0, indicating no symbols, even if bit 5 in the `flags' word is
1N/A If bit 6 in the `flags' word is set, then the `mmap_*' fields are
1N/Avalid, and indicate the address and length of a buffer containing a
1N/Amemory map of the machine provided by the BIOS. `mmap_addr' is the
1N/Aaddress, and `mmap_length' is the total size of the buffer. The buffer
1N/Ais really used for skipping to the next pair):
1N/A +-------------------+
1N/A +-------------------+
1N/A 4 | base_addr_high |
1N/A +-------------------+
1N/A where `size' is the size of the associated structure in bytes, which
1N/Acan be greater than the minimum of 20 bytes. `base_addr_low' is the
1N/Alower 32 bits of the starting address, and `base_addr_high' is the
1N/Aupper 32 bits, for a total of a 64-bit starting address. `length_low'
1N/Ais the lower 32 bits of the size of the memory region in bytes, and
1N/A`length_high' is the upper 32 bits, for a total of a 64-bit length.
1N/A`type' is the variety of address range represented, where a value of 1
1N/Aindicates available RAM, and all other values currently indicated a
1N/A The map provided is guaranteed to list all standard RAM that should
1N/Abe available for normal use.
1N/A If bit 7 in the `flags' is set, then the `drives_*' fields are
1N/Avalid, and indicate the address of the physical address of the first
1N/Adrive structure and the size of drive structures. `drives_addr' is the
1N/Aaddress, and `drives_length' is the total size of drive structures.
1N/ANote that `drives_length' may be zero. Each drive structure is
1N/Aformatted as follows:
1N/A +-------------------+
1N/A +-------------------+
1N/A +-------------------+
1N/A +-------------------+
1N/A 6 | drive_cylinders |
1N/A +-------------------+
1N/A 10 - xx | drive_ports |
1N/A +-------------------+
1N/A The `size' field specifies the size of this structure. The size
1N/Avaries, depending on the number of ports. Note that the size may not be
1N/Aequal to (10 + 2 * the number of ports), because of an alignment.
1N/A The `drive_number' field contains the BIOS drive number. The
1N/A`drive_mode' field represents the access mode used by the boot loader.
1N/ACurrently, the following modes are defined:
1N/A LBA mode (Logical Block Addressing mode).
1N/A The three fields, `drive_cylinders', `drive_heads' and
1N/A`drive_sectors', indicate the geometry of the drive detected by the
1N/ABIOS. `drive_cylinders' contains the number of the cylinders.
1N/A`drive_heads' contains the number of the heads. `drive_sectors'
1N/Acontains the number of the sectors per track.
1N/A The `drive_ports' field contains the array of the I/O ports used for
1N/Athe drive in the BIOS code. The array consists of zero or more unsigned
1N/Atwo-bytes integers, and is terminated with zero. Note that the array
1N/Amay contain any number of I/O ports that are not related to the drive
1N/Aactually (such as DMA controller's ports).
1N/A If bit 8 in the `flags' is set, then the `config_table' field is
1N/Avalid, and indicates the address of the ROM configuration table
1N/Areturned by the "GET CONFIGURATION" BIOS call. If the BIOS call fails,
1N/Athen the size of the table must be _zero_.
1N/A If bit 9 in the `flags' is set, the `boot_loader_name' field is
1N/Avalid, and contains the physical address of the name of a boot loader
1N/Abooting the kernel. The name is a normal C-style zero-terminated string.
1N/A If bit 10 in the `flags' is set, the `apm_table' field is valid, and
1N/Acontains the physical address of an APM table defined as below:
1N/A +----------------------+
1N/A +----------------------+
1N/A The fields `version', `cseg', `offset', `cseg_16', `dseg', `flags',
1N/A`cseg_len', `cseg_16_len', `dseg_len' indicate the version number, the
1N/Aprotected mode 32-bit code segment, the offset of the entry point, the
1N/Aprotected mode 16-bit code segment, the protected mode 16-bit data
1N/Asegment, the flags, the length of the protected mode 32-bit code
1N/Asegment, the length of the protected mode 16-bit code segment, and the
1N/Alength of the protected mode 16-bit data segment, respectively. Only
1N/Athe field `offset' is 4 bytes, and the others are 2 bytes. See Advanced
1N/APower Management (APM) BIOS Interface Specification
1N/A If bit 11 in the `flags' is set, the graphics table is available.
1N/AThis must only be done if the kernel has indicated in the `Multiboot
1N/AHeader' that it accepts a graphics mode.
1N/A The fields `vbe_control_info' and `vbe_mode_info' contain the
1N/Aphysical addresses of VBE control information returned by the VBE
1N/AFunction 00h and VBE mode information returned by the VBE Function 01h,
1N/A The field `vbe_mode' indicates current video mode in the format
1N/Aspecified in VBE 3.0.
1N/A The rest fields `vbe_interface_seg', `vbe_interface_off', and
1N/A`vbe_interface_len' contain the table of a protected mode interface
1N/Adefined in VBE 2.0+. If this information is not available, those fields
1N/Acontain zero. Note that VBE 3.0 defines another protected mode
1N/Ainterface which is incompatible with the old one. If you want to use
1N/Athe new protected mode interface, you will have to find the table
1N/A The fields for the graphics table are designed for VBE, but
1N/AMultiboot boot loaders may simulate VBE on non-VBE modes, as if they
1N/A*Caution:* The following items are not part of the specification
1N/Adocument, but are included for prospective operating system and boot
1N/A* BIOS device mapping techniques::
1N/A* Example boot loader code::
1N/AFile:
multiboot.info, Node: Notes on PC, Next: BIOS device mapping techniques, Up: Examples
1N/AIn reference to bit 0 of the `flags' parameter in the Multiboot
1N/Ainformation structure, if the bootloader in question uses older BIOS
1N/Ainterfaces, or the newest ones are not available (see description about
1N/Abit 6), then a maximum of either 15 or 63 megabytes of memory may be
1N/Areported. It is _highly_ recommended that boot loaders perform a
1N/Athorough memory probe.
1N/A In reference to bit 1 of the `flags' parameter in the Multiboot
1N/Ainformation structure, it is recognized that determination of which
1N/ABIOS drive maps to which device driver in an operating system is
1N/Anon-trivial, at best. Many kludges have been made to various operating
1N/Asystems instead of solving this problem, most of them breaking under
1N/Amany conditions. To encourage the use of general-purpose solutions to
1N/Athis problem, there are 2 BIOS device mapping techniques (*note BIOS
1N/Adevice mapping techniques::).
1N/A In reference to bit 6 of the `flags' parameter in the Multiboot
1N/Ainformation structure, it is important to note that the data structure
1N/Aused there (starting with `BaseAddrLow') is the data returned by the
1N/AINT 15h, AX=E820h -- Query System Address Map call. See *Note Query
1N/ASystem Address Map: (
grub.info)Query System Address Map, for more
1N/Ainformation. The interface here is meant to allow a boot loader to work
1N/Aunmodified with any reasonable extensions of the BIOS interface,
1N/Apassing along any extra data to be interpreted by the operating system
1N/AFile:
multiboot.info, Node: BIOS device mapping techniques, Next: Example OS code, Prev: Notes on PC, Up: Examples
1N/A4.2 BIOS device mapping techniques
1N/A==================================
1N/ABoth of these techniques should be usable from any PC operating system,
1N/Aand neither require any special support in the drivers themselves. This
1N/Asection will be flushed out into detailed explanations, particularly for
1N/Athe I/O restriction technique.
1N/A The general rule is that the data comparison technique is the quick
1N/Aand dirty solution. It works most of the time, but doesn't cover all the
1N/Abases, and is relatively simple.
1N/A The I/O restriction technique is much more complex, but it has
1N/Apotential to solve the problem under all conditions, plus allow access
1N/Aof the remaining BIOS devices when not all of them have operating system
1N/A* Data comparison technique::
1N/A* I/O restriction technique::
1N/AFile:
multiboot.info, Node: Data comparison technique, Next: I/O restriction technique, Up: BIOS device mapping techniques
1N/A4.2.1 Data comparison technique
1N/A-------------------------------
1N/ABefore activating _any_ of the device drivers, gather enough data from
1N/Asimilar sectors on each of the disks such that each one can be uniquely
1N/A After activating the device drivers, compare data from the drives
1N/Ausing the operating system drivers. This should hopefully be sufficient
1N/Ato provide such a mapping.
1N/A 1. The data on some BIOS devices might be identical (so the part
1N/A reading the drives from the BIOS should have some mechanism to give
1N/A 2. There might be extra drives not accessible from the BIOS which are
1N/A identical to some drive used by the BIOS (so it should be capable
1N/A of giving up there as well).
1N/AFile:
multiboot.info, Node: I/O restriction technique, Prev: Data comparison technique, Up: BIOS device mapping techniques
1N/A4.2.2 I/O restriction technique
1N/A-------------------------------
1N/AThis first step may be unnecessary, but first create copy-on-write
1N/Amappings for the device drivers writing into PC RAM. Keep the original
1N/Acopies for the "clean BIOS virtual machine" to be created later.
1N/A For each device driver brought online, determine which BIOS devices
1N/Abecome inaccessible by:
1N/A 1. Create a "clean BIOS virtual machine".
1N/A 2. Set the I/O permission map for the I/O area claimed by the device
1N/A driver to no permissions (neither read nor write).
1N/A 3. Access each device.
1N/A 4. Record which devices succeed, and those which try to access the
1N/A "restricted" I/O areas (hopefully, this will be an "xor"
1N/A For each device driver, given how many of the BIOS devices were
1N/Asubsumed by it (there should be no gaps in this list), it should be easy
1N/Ato determine which devices on the controller these are.
1N/A In general, you have at most 2 disks from each controller given BIOS
1N/Anumbers, but they pretty much always count from the lowest logically
1N/Anumbered devices on the controller.
1N/AFile:
multiboot.info, Node: Example OS code, Next: Example boot loader code, Prev: BIOS device mapping techniques, Up: Examples
1N/AIn this distribution, the example Multiboot kernel `kernel' is
1N/Aincluded. The kernel just prints out the Multiboot information structure
1N/Aon the screen, so you can make use of the kernel to test a
1N/AMultiboot-compliant boot loader and for reference to how to implement a
1N/AMultiboot kernel. The source files can be found under the directory
1N/A`docs' in the GRUB distribution.
1N/A The kernel `kernel' consists of only three files: `
boot.S',
1N/Ain GAS (*note GNU assembler: (
as.info)Top.), and contains the Multiboot
1N/Ainformation structure to comply with the specification. When a
1N/AMultiboot-compliant boot loader loads and execute it, it initialize the
1N/Astack pointer and `EFLAGS', and then call the function `cmain' defined
1N/Ain `
kernel.c'. If `cmain' returns to the callee, then it shows a
1N/Amessage to inform the user of the halt state and stops forever until
1N/Ayou push the reset key. The file `
kernel.c' contains the function
1N/A`cmain', which checks if the magic number passed by the boot loader is
1N/Avalid and so on, and some functions to print messages on the screen.
1N/Afor the Multiboot header, the Multiboot header structure and the
1N/AMultiboot information structure.
1N/A* Other Multiboot kernels::
1N/A /* Copyright (C) 1999, 2001 Free Software Foundation, Inc.
1N/A This program is free software; you can redistribute it
and/or modify
1N/A it under the terms of the GNU General Public License as published by
1N/A the Free Software Foundation; either version 2 of the License, or
1N/A (at your option) any later version.
1N/A This program is distributed in the hope that it will be useful,
1N/A but WITHOUT ANY WARRANTY; without even the implied warranty of
1N/A MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
1N/A GNU General Public License for more details.
1N/A You should have received a copy of the GNU General Public License
1N/A along with this program; if not, write to the Free Software
1N/A Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. */
1N/A /* The magic number for the Multiboot header. */
1N/A #define MULTIBOOT_HEADER_MAGIC 0x1BADB002
1N/A /* The flags for the Multiboot header. */
1N/A # define MULTIBOOT_HEADER_FLAGS 0x00000003
1N/A # define MULTIBOOT_HEADER_FLAGS 0x00010003
1N/A /* The magic number passed by a Multiboot-compliant boot loader. */
1N/A #define MULTIBOOT_BOOTLOADER_MAGIC 0x2BADB002
1N/A /* The size of our stack (16KB). */
1N/A #define STACK_SIZE 0x4000
1N/A /* C symbol format. HAVE_ASM_USCORE is defined by configure. */
1N/A #ifdef HAVE_ASM_USCORE
1N/A # define EXT_C(sym) _ ## sym
1N/A # define EXT_C(sym) sym
1N/A /* The Multiboot header. */
1N/A typedef struct multiboot_header
1N/A unsigned long magic;
1N/A unsigned long flags;
1N/A unsigned long checksum;
1N/A unsigned long header_addr;
1N/A unsigned long load_addr;
1N/A unsigned long load_end_addr;
1N/A unsigned long bss_end_addr;
1N/A unsigned long entry_addr;
1N/A } multiboot_header_t;
1N/A typedef struct aout_symbol_table
1N/A unsigned long tabsize;
1N/A unsigned long strsize;
1N/A unsigned long reserved;
1N/A } aout_symbol_table_t;
1N/A /* The section header table for ELF. */
1N/A typedef struct elf_section_header_table
1N/A unsigned long shndx;
1N/A } elf_section_header_table_t;
1N/A /* The Multiboot information. */
1N/A typedef struct multiboot_info
1N/A unsigned long flags;
1N/A unsigned long mem_lower;
1N/A unsigned long mem_upper;
1N/A unsigned long boot_device;
1N/A unsigned long cmdline;
1N/A unsigned long mods_count;
1N/A unsigned long mods_addr;
1N/A aout_symbol_table_t aout_sym;
1N/A elf_section_header_table_t elf_sec;
1N/A unsigned long mmap_length;
1N/A unsigned long mmap_addr;
1N/A /* The module structure. */
1N/A typedef struct module
1N/A unsigned long mod_start;
1N/A unsigned long mod_end;
1N/A unsigned long string;
1N/A unsigned long reserved;
1N/A /* The memory map. Be careful that the offset 0 is base_addr_low
1N/A typedef struct memory_map
1N/A unsigned long base_addr_low;
1N/A unsigned long base_addr_high;
1N/A unsigned long length_low;
1N/A unsigned long length_high;
1N/A /* Copyright (C) 1999, 2001 Free Software Foundation, Inc.
1N/A This program is free software; you can redistribute it
and/or modify
1N/A it under the terms of the GNU General Public License as published by
1N/A the Free Software Foundation; either version 2 of the License, or
1N/A (at your option) any later version.
1N/A This program is distributed in the hope that it will be useful,
1N/A but WITHOUT ANY WARRANTY; without even the implied warranty of
1N/A MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
1N/A GNU General Public License for more details.
1N/A You should have received a copy of the GNU General Public License
1N/A along with this program; if not, write to the Free Software
1N/A Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. */
1N/A .globl start, _start
1N/A /* Align 32 bits boundary. */
1N/A /* Multiboot header. */
1N/A .long MULTIBOOT_HEADER_MAGIC
1N/A .long MULTIBOOT_HEADER_FLAGS
1N/A .long -(MULTIBOOT_HEADER_MAGIC + MULTIBOOT_HEADER_FLAGS)
1N/A .long multiboot_header
1N/A .long multiboot_entry
1N/A #endif /* ! __ELF__ */
1N/A /* Initialize the stack pointer. */
1N/A movl $(stack + STACK_SIZE), %esp
1N/A /* Push the pointer to the Multiboot information structure. */
1N/A /* Push the magic value. */
1N/A /* Now enter the C main function... */
1N/A /* Our stack area. */
1N/A .comm stack, STACK_SIZE
1N/A /* Copyright (C) 1999 Free Software Foundation, Inc.
1N/A This program is free software; you can redistribute it
and/or modify
1N/A it under the terms of the GNU General Public License as published by
1N/A the Free Software Foundation; either version 2 of the License, or
1N/A (at your option) any later version.
1N/A This program is distributed in the hope that it will be useful,
1N/A but WITHOUT ANY WARRANTY; without even the implied warranty of
1N/A MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
1N/A GNU General Public License for more details.
1N/A You should have received a copy of the GNU General Public License
1N/A along with this program; if not, write to the Free Software
1N/A Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. */
1N/A /* Check if the bit BIT in FLAGS is set. */
1N/A #define CHECK_FLAG(flags,bit) ((flags) & (1 << (bit)))
1N/A /* Some screen stuff. */
1N/A /* The number of columns. */
1N/A /* The number of lines. */
1N/A /* The attribute of an character. */
1N/A /* The video memory address. */
1N/A #define VIDEO 0xB8000
1N/A /* Save the X position. */
1N/A /* Save the Y position. */
1N/A /* Point to the video memory. */
1N/A static volatile unsigned char *video;
1N/A /* Forward declarations. */
1N/A void cmain (unsigned long magic, unsigned long addr);
1N/A static void cls (void);
1N/A static void itoa (char *buf, int base, int d);
1N/A static void putchar (int c);
1N/A void printf (const char *format, ...);
1N/A /* Check if MAGIC is valid and print the Multiboot information structure
1N/A cmain (unsigned long magic, unsigned long addr)
1N/A multiboot_info_t *mbi;
1N/A /* Clear the screen. */
1N/A /* Am I booted by a Multiboot-compliant boot loader? */
1N/A if (magic != MULTIBOOT_BOOTLOADER_MAGIC)
1N/A printf ("Invalid magic number: 0x%x\n", (unsigned) magic);
1N/A /* Set MBI to the address of the Multiboot information structure. */
1N/A mbi = (multiboot_info_t *) addr;
1N/A /* Print out the flags. */
1N/A printf ("flags = 0x%x\n", (unsigned) mbi->flags);
1N/A /* Are mem_* valid? */
1N/A if (CHECK_FLAG (mbi->flags, 0))
1N/A printf ("mem_lower = %uKB, mem_upper = %uKB\n",
1N/A (unsigned) mbi->mem_lower, (unsigned) mbi->mem_upper);
1N/A /* Is boot_device valid? */
1N/A if (CHECK_FLAG (mbi->flags, 1))
1N/A printf ("boot_device = 0x%x\n", (unsigned) mbi->boot_device);
1N/A /* Is the command line passed? */
1N/A if (CHECK_FLAG (mbi->flags, 2))
1N/A printf ("cmdline = %s\n", (char *) mbi->cmdline);
1N/A /* Are mods_* valid? */
1N/A if (CHECK_FLAG (mbi->flags, 3))
1N/A printf ("mods_count = %d, mods_addr = 0x%x\n",
1N/A (int) mbi->mods_count, (int) mbi->mods_addr);
1N/A for (i = 0, mod = (module_t *) mbi->mods_addr;
1N/A i < mbi->mods_count;
1N/A printf (" mod_start = 0x%x, mod_end = 0x%x, string = %s\n",
1N/A (unsigned) mod->mod_start,
1N/A (unsigned) mod->mod_end,
1N/A (char *) mod->string);
1N/A /* Bits 4 and 5 are mutually exclusive! */
1N/A if (CHECK_FLAG (mbi->flags, 4) && CHECK_FLAG (mbi->flags, 5))
1N/A printf ("Both bits 4 and 5 are set.\n");
1N/A /* Is the symbol table of
a.out valid? */
1N/A if (CHECK_FLAG (mbi->flags, 4))
1N/A printf ("aout_symbol_table: tabsize = 0x%0x, "
1N/A "strsize = 0x%x, addr = 0x%x\n",
1N/A (unsigned) aout_sym->tabsize,
1N/A (unsigned) aout_sym->strsize,
1N/A (unsigned) aout_sym->addr);
1N/A /* Is the section header table of ELF valid? */
1N/A if (CHECK_FLAG (mbi->flags, 5))
1N/A printf ("elf_sec: num = %u, size = 0x%x,"
1N/A " addr = 0x%x, shndx = 0x%x\n",
1N/A (unsigned) elf_sec->num, (unsigned) elf_sec->size,
1N/A (unsigned) elf_sec->addr, (unsigned) elf_sec->shndx);
1N/A /* Are mmap_* valid? */
1N/A if (CHECK_FLAG (mbi->flags, 6))
1N/A printf ("mmap_addr = 0x%x, mmap_length = 0x%x\n",
1N/A (unsigned) mbi->mmap_addr, (unsigned) mbi->mmap_length);
1N/A for (mmap = (memory_map_t *) mbi->mmap_addr;
1N/A (unsigned long) mmap < mbi->mmap_addr + mbi->mmap_length;
1N/A mmap = (memory_map_t *) ((unsigned long) mmap
1N/A + mmap->size + sizeof (mmap->size)))
1N/A printf (" size = 0x%x, base_addr = 0x%x%x,"
1N/A " length = 0x%x%x, type = 0x%x\n",
1N/A (unsigned) mmap->size,
1N/A (unsigned) mmap->base_addr_high,
1N/A (unsigned) mmap->base_addr_low,
1N/A (unsigned) mmap->length_high,
1N/A (unsigned) mmap->length_low,
1N/A (unsigned) mmap->type);
1N/A /* Clear the screen and initialize VIDEO, XPOS and YPOS. */
1N/A video = (unsigned char *) VIDEO;
1N/A for (i = 0; i < COLUMNS * LINES * 2; i++)
1N/A /* Convert the integer D to a string and save the string in BUF. If
1N/A BASE is equal to 'd', interpret that D is decimal, and if BASE is
1N/A equal to 'x', interpret that D is hexadecimal. */
1N/A itoa (char *buf, int base, int d)
1N/A unsigned long ud = d;
1N/A /* If %d is specified and D is minus, put `-' in the head. */
1N/A if (base == 'd' && d < 0)
1N/A else if (base == 'x')
1N/A /* Divide UD by DIVISOR until UD == 0. */
1N/A int remainder = ud % divisor;
1N/A *p++ = (remainder < 10) ? remainder + '0' : remainder + 'a' - 10;
1N/A while (ud /= divisor);
1N/A /* Terminate BUF. */
1N/A /* Put the character C on the screen. */
1N/A if (c == '\n' || c == '\r')
1N/A *(video + (xpos + ypos * COLUMNS) * 2) = c & 0xFF;
1N/A *(video + (xpos + ypos * COLUMNS) * 2 + 1) = ATTRIBUTE;
1N/A if (xpos >= COLUMNS)
1N/A /* Format a string and print it on the screen, just like the libc
1N/A printf (const char *format, ...)
1N/A char **arg = (char **) &format;
1N/A while ((c = *format++) != 0)
1N/A itoa (buf, c, *((int *) arg++));
1N/A putchar (*((int *) arg++));
1N/A4.3.4 Other Multiboot kernels
1N/A-----------------------------
1N/AOther useful information should be available in Multiboot kernels, such
1N/Ais worth mentioning the OSKit
1N/Asupporting the specification.
1N/AFile:
multiboot.info, Node: Example boot loader code, Prev: Example OS code, Up: Examples
1N/A4.4 Example boot loader code
1N/A============================
1N/AMultiboot-compliant boot loader, supporting all required and optional
1N/Afeatures present in this specification. A public release has not been
1N/Amade, but the test release is available from:
1N/A5 The change log of this specification
1N/A**************************************
1N/A * "Multiboot Standard" is renamed to "Multiboot Specification".
1N/A * Graphics fields are added to Multiboot header.
1N/A * BIOS drive information, BIOS configuration table, the name of
1N/A a boot loader, APM information, and graphics information are
1N/A added to Multiboot information.
1N/A * Rewritten in Texinfo format.
1N/A * Rewritten, using more strict words.
1N/A * The maintainer changes to the GNU GRUB maintainer team
1N/A <bug-grub@gnu.org>, from Bryan Ford and Erich Stefan Boleyn.
1N/A * A few wording changes.
1N/A * Clasification of machine state passed to an operating system.
1N/A * Major changes plus HTMLification.
1N/ANode: Motivation1794
1N/ANode: Architecture3191
1N/ANode: Operating systems3724
1N/ANode: Boot sources4518
1N/ANode: Boot-time configuration5488
1N/ANode: Convenience to operating systems6096
1N/ANode: Boot modules8327
1N/ANode: Terminology9476
1N/ANode: Specification11855
1N/ANode: OS image format12418
1N/ANode: Header layout13476
1N/ANode: Header magic fields14644
1N/ANode: Header address fields17505
1N/ANode: Header graphics fields19351
1N/ANode: Machine state20737
1N/ANode: Boot information format22997
1N/ANode: Notes on PC38741
1N/ANode: BIOS device mapping techniques40307
1N/ANode: Data comparison technique41217
1N/ANode: I/O restriction technique42079
1N/ANode: Example OS code43296
1N/ANode: Other Multiboot kernels60013
1N/ANode: Example boot loader code60444