Lines Matching +full:image +full:- +full:specific
1 \input texinfo @c -*-texinfo-*-
2 @c -*-texinfo-*-
107 * Boot-time configuration::
119 different install-time and boot-time user interfaces. Getting multiple
122 choice of boot loaders for a particular operating system --- if the one
133 specification does @emph{not} specify how boot loaders should work ---
144 this specification, stripped of the x86-specific details, could be
151 This specification is targeted toward free 32-bit operating systems
166 image from a variety of sources, including floppy disk, hard disk, and
169 Disk-based boot loaders may use a variety of techniques to find the
170 relevant OS image and boot module data on disk, such as by
171 interpretation of specific file systems (e.g. the BSD/Mach boot loader),
175 DOS). Similarly, network-based boot loaders could use a variety of
180 user-friendliness.
183 @node Boot-time configuration
184 @section Configure an operating system at boot-time
197 OS images should be easy to generate. Ideally, an OS image should simply
198 be an ordinary 32-bit executable file in whatever file format the
205 the boot process is created, whereas every bit of code in the OS image
207 not have to worry about getting into 32-bit mode initially, because mode
214 even among free Unix-like @sc{pc}-based operating systems --- generally
219 existence in order to load the OS image --- otherwise the boot loader
220 effectively becomes operating system specific again.
223 problem. Multiboot-compliant OS images always contain a magic
224 @dfn{Multiboot header} (@pxref{OS image format}), which allows the boot
225 loader to load the image without having to understand numerous a.out
229 Multiboot-compliant.
239 these additional modules could be embedded in the main OS image along
240 with the kernel itself, and the resulting image be split apart manually
242 flexible, more space-efficient, and more convenient to the operating
258 We use the term @dfn{must}, when any boot loader or OS image needs to
259 follow a rule --- otherwise, the boot loader or OS image is @emph{not}
260 Multiboot-compliant.
263 We use the term @dfn{should}, when any boot loader or OS image is
267 We use the term @dfn{may}, when any boot loader or OS image is allowed
271 Whatever program or set of programs loads the image of the final
275 loader --- the stage that eventually transfers control to an operating
276 system --- must follow the rules specified in this document in order
277 to be @dfn{Multiboot-compliant}; earlier boot loader stages may be
280 @item OS image
281 The initial binary image that a boot loader loads into memory and
282 transfers control to start an operating system. The OS image is
287 an OS image, but does not interpret in any way other than passing their
290 @item Multiboot-compliant
291 A boot loader or an OS image which follows the rules defined as
292 @dfn{must} is Multiboot-compliant. When this specification specifies a
293 rule as @dfn{should} or @dfn{may}, a Multiboot-complaint boot loader/OS
294 image doesn't need to follow the rule.
297 The type of unsigned 8-bit data.
300 The type of unsigned 16-bit data. Because the target architecture is
301 little-endian, u16 is coded in little-endian.
304 The type of unsigned 32-bit data. Because the target architecture is
305 little-endian, u32 is coded in little-endian.
308 The type of unsigned 64-bit data. Because the target architecture is
309 little-endian, u64 is coded in little-endian.
316 There are three main aspects of a boot loader/OS image interface:
320 The format of an OS image as seen by a boot loader.
332 * OS image format::
338 @node OS image format
339 @section OS image format
341 An OS image may be an ordinary 32-bit executable file in the standard
343 linked at a non-default load address to avoid loading on top of the
347 An OS image must contain an additional header called @dfn{Multiboot
348 header}, besides the headers of the format used by the OS image. The
350 bytes of the OS image, and must be longword (32-bit) aligned. In
401 The field @samp{flags} specifies features that the OS image requests or
402 requires of an boot loader. Bits 0-15 indicate requirements; if the
405 notify the user and fail to load the OS image. Bits 16-31 indicate
408 usual. Naturally, all as-yet-undefined bits in the @samp{flags} word
416 startup, and thus need the boot modules to be page-aligned.
429 8-24 in the Multiboot header are valid, and the boot loader should use
431 where to load the OS image. This information does not need to be
432 provided if the kernel image is in @sc{elf} format, but it @emph{must}
440 The field @samp{checksum} is a 32-bit unsigned value which, when added
442 have a 32-bit unsigned sum of zero.
455 header --- the physical memory location at which the magic value is
457 mapping between OS image offsets and physical memory addresses.
461 offset in the OS image file at which to start loading is defined by the
462 offset at which the header was found, minus (header_addr -
467 segment. (load_end_addr - load_addr) specifies how much data to load.
469 OS image; this is true for existing a.out executable formats.
471 segments occupy the whole OS image file.
491 mode by the OS image. If the mode exists, the boot loader should set
500 EGA-standard text mode. Everything else is reserved for future
507 indicates that the OS image has no preference.
512 indicates that the OS image has no preference.
516 a text mode. The value zero indicates that the OS image has no
524 When the boot loader invokes the 32-bit operating system, the machine
531 Multiboot-compliant boot loader (e.g. as opposed to another type of
535 Must contain the 32-bit physical address of the Multiboot
540 Must be a 32-bit read/execute code segment with an offset of @samp{0}
548 Must be a 32-bit read/write data segment with an offset of @samp{0}
568 The OS image must create its own stack as soon as it needs one.
572 @samp{GDTR} may be invalid, so the OS image must not load any segment
577 The OS image must leave interrupts disabled until it sets up its own
588 changed them during the switch to 32-bit mode.
594 FIXME: Split this chapter like the chapter ``OS image format''.
614 +-------------------+
616 +-------------------+
619 +-------------------+
621 +-------------------+
623 +-------------------+
626 +-------------------+
627 28 - 40 | syms | (present if flags[4] or
629 +-------------------+
632 +-------------------+
635 +-------------------+
637 +-------------------+
639 +-------------------+
641 +-------------------+
648 +-------------------+
653 in the Multiboot information structure. All as-yet-undefined bits must
670 loader loaded the OS image from. If the OS image was not loaded from a
674 @samp{boot_device} field is laid out in four one-byte subfields as
679 +-------+-------+-------+-------+
681 +-------+-------+-------+-------+
686 @sc{bios} INT 0x13 low-level disk interface: e.g. 0x00 for the first
690 specifies the @dfn{top-level} partition number, @samp{part2} specifies a
691 @dfn{sub-partition} in the top-level partition, etc. Partition numbers
693 example, if the disk is partitioned using a simple one-level DOS
699 partition number, @samp{part2} contains the BSD sub-partition within
703 4 and increasing, rather than as nested sub-partitions, even though the
712 be passed to the kernel. The command line is a normal C-style
713 zero-terminated string.
717 kernel image, and where they can be found. @samp{mods_count} contains
725 +-------------------+
728 +-------------------+
730 +-------------------+
732 +-------------------+
738 be associated with that particular boot module; it is a zero-terminated
744 is specific to the operating system. The @samp{reserved} field must be
754 +-------------------+
759 +-------------------+
763 These indicate where the symbol table from an a.out kernel image can be
764 found. @samp{addr} is the physical address of the size (4-byte unsigned
766 immediately by the array itself, then the size (4-byte unsigned long) of
767 a set of zero-terminated @sc{ascii} strings (plus sizeof(unsigned long) in
780 +-------------------+
785 +-------------------+
809 +-------------------+
810 -4 | size |
811 +-------------------+
817 +-------------------+
824 upper 32 bits, for a total of a 64-bit starting address. @samp{length_low}
826 @samp{length_high} is the upper 32 bits, for a total of a 64-bit
843 +-------------------+
845 +-------------------+
847 +-------------------+
849 +-------------------+
853 +-------------------+
854 10 - xx | drive_ports |
855 +-------------------+
884 unsigned two-bytes integers, and is terminated with zero. Note that the
895 loader booting the kernel. The name is a normal C-style zero-terminated
904 +----------------------+
914 +----------------------+
920 @samp{dseg_len} indicate the version number, the protected mode 32-bit
921 code segment, the offset of the entry point, the protected mode 16-bit
922 code segment, the protected mode 16-bit data segment, the flags, the
923 length of the protected mode 32-bit code segment, the length of the
924 protected mode 16-bit code segment, and the length of the protected mode
925 16-bit data segment, respectively. Only the field @samp{offset} is 4
951 Multiboot boot loaders may simulate @sc{vbe} on non-@sc{vbe} modes, as
983 non-trivial, at best. Many kludges have been made to various operating
985 many conditions. To encourage the use of general-purpose solutions to
992 the INT 15h, AX=E820h --- Query System Address Map call. See @xref{Query
1052 This first step may be unnecessary, but first create copy-on-write
1092 Multiboot-compliant boot loader and for reference to how to implement a
1100 comply with the specification. When a Multiboot-compliant boot loader
1154 as GNU Mach and Fiasco @url{http://os.inf.tu-dresden.de/fiasco/}. And,
1164 is a full Multiboot-compliant boot loader, supporting all required and
1199 @email{bug-grub@@gnu.org}, from Bryan Ford and Erich Stefan Boleyn.