Lines Matching +full:image +full:- +full:specific
4 INFO-DIR-SECTION Kernel
5 START-INFO-DIR-ENTRY
7 END-INFO-DIR-ENTRY
59 * Boot-time configuration::
72 different install-time and boot-time user interfaces. Getting multiple
75 of boot loaders for a particular operating system -- if the one that
86 specification does _not_ specify how boot loaders should work -- only
99 this specification, stripped of the x86-specific details, could be
108 This specification is targeted toward free 32-bit operating systems
119 File: multiboot.info, Node: Boot sources, Next: Boot-time configuration, Prev: Operating systems, Up: Overview
125 image from a variety of sources, including floppy disk, hard disk, and
128 Disk-based boot loaders may use a variety of techniques to find the
129 relevant OS image and boot module data on disk, such as by
130 interpretation of specific file systems (e.g. the BSD/Mach boot loader),
134 Similarly, network-based boot loaders could use a variety of network
139 user-friendliness.
142 File: multiboot.info, Node: Boot-time configuration, Next: Convenience to operating systems, Prev: Boot sources, Up: Overview
144 1.5 Configure an operating system at boot-time
155 File: multiboot.info, Node: Convenience to operating systems, Next: Boot modules, Prev: Boot-time configuration, Up: Overview
160 OS images should be easy to generate. Ideally, an OS image should simply
161 be an ordinary 32-bit executable file in whatever file format the
168 boot process is created, whereas every bit of code in the OS image
170 not have to worry about getting into 32-bit mode initially, because mode
177 formats even among free Unix-like PC-based operating systems --
182 formats in existence in order to load the OS image -- otherwise the
183 boot loader effectively becomes operating system specific again.
186 Multiboot-compliant OS images always contain a magic "Multiboot header"
187 (*note OS image format::), which allows the boot loader to load the
188 image without having to understand numerous a.out variants or other
191 the local a.out format variant in addition to being Multiboot-compliant.
203 these additional modules could be embedded in the main OS image along
204 with the kernel itself, and the resulting image be split apart manually
206 flexible, more space-efficient, and more convenient to the operating
223 We use the term "must", when any boot loader or OS image needs to
224 follow a rule -- otherwise, the boot loader or OS image is _not_
225 Multiboot-compliant.
228 We use the term "should", when any boot loader or OS image is
233 We use the term "may", when any boot loader or OS image is allowed
237 Whatever program or set of programs loads the image of the final
241 of the boot loader -- the stage that eventually transfers control
242 to an operating system -- must follow the rules specified in this
243 document in order to be "Multiboot-compliant"; earlier boot loader
246 "OS image"
247 The initial binary image that a boot loader loads into memory and
248 transfers control to start an operating system. The OS image is
253 with an OS image, but does not interpret in any way other than
256 "Multiboot-compliant"
257 A boot loader or an OS image which follows the rules defined as
258 "must" is Multiboot-compliant. When this specification specifies a
259 rule as "should" or "may", a Multiboot-complaint boot loader/OS
260 image doesn't need to follow the rule.
263 The type of unsigned 8-bit data.
266 The type of unsigned 16-bit data. Because the target architecture
267 is little-endian, u16 is coded in little-endian.
270 The type of unsigned 32-bit data. Because the target architecture
271 is little-endian, u32 is coded in little-endian.
274 The type of unsigned 64-bit data. Because the target architecture
275 is little-endian, u64 is coded in little-endian.
283 There are three main aspects of a boot loader/OS image interface:
285 1. The format of an OS image as seen by a boot loader.
295 * OS image format::
300 File: multiboot.info, Node: OS image format, Next: Machine state, Up: Specification
302 3.1 OS image format
305 An OS image may be an ordinary 32-bit executable file in the standard
307 linked at a non-default load address to avoid loading on top of the
311 An OS image must contain an additional header called "Multiboot
312 header", besides the headers of the format used by the OS image. The
314 bytes of the OS image, and must be longword (32-bit) aligned. In
326 File: multiboot.info, Node: Header layout, Next: Header magic fields, Up: OS image format
329 ------------------------------------
354 File: multiboot.info, Node: Header magic fields, Next: Header address fields, Prev: Header layout, Up: OS image format
357 ------------------------------------------
364 The field `flags' specifies features that the OS image requests or
365 requires of an boot loader. Bits 0-15 indicate requirements; if the
368 reason, it must notify the user and fail to load the OS image.
369 Bits 16-31 indicate optional features; if any bits in this range
371 ignore them and proceed as usual. Naturally, all as-yet-undefined
380 during startup, and thus need the boot modules to be page-aligned.
393 8-24 in the Multiboot header are valid, and the boot loader should
395 calculate where to load the OS image. This information does not
396 need to be provided if the kernel image is in ELF format, but it
405 The field `checksum' is a 32-bit unsigned value which, when added
407 32-bit unsigned sum of zero.
410 File: multiboot.info, Node: Header address fields, Next: Header graphics fields, Prev: Header magic fields, Up: OS image format
413 --------------------------------------------
420 Multiboot header -- the physical memory location at which the
422 "synchronize" the mapping between OS image offsets and physical
427 segment. The offset in the OS image file at which to start loading
429 (header_addr - load_addr). load_addr must be less than or equal to
434 (load_end_addr - load_addr) specifies how much data to load. This
436 OS image; this is true for existing a.out executable formats. If
438 segments occupy the whole OS image file.
452 File: multiboot.info, Node: Header graphics fields, Prev: Header address fields, Up: OS image format
455 ---------------------------------------------
459 the OS image. If the mode exists, the boot loader should set it, when
466 Contains `0' for linear graphics mode or `1' for EGA-standard text
474 indicates that the OS image has no preference.
479 indicates that the OS image has no preference.
483 in a text mode. The value zero indicates that the OS image has no
487 File: multiboot.info, Node: Machine state, Next: Boot information format, Prev: OS image format, Up: Specification
492 When the boot loader invokes the 32-bit operating system, the machine
498 Multiboot-compliant boot loader (e.g. as opposed to another type of
502 Must contain the 32-bit physical address of the Multiboot
507 Must be a 32-bit read/execute code segment with an offset of `0'
515 Must be a 32-bit read/write data segment with an offset of `0' and
533 The OS image must create its own stack as soon as it needs one.
537 the `GDTR' may be invalid, so the OS image must not load any
542 The OS image must leave interrupts disabled until it sets up its
551 BIOS/DOS values, even if it changed them during the switch to 32-bit
560 FIXME: Split this chapter like the chapter "OS image format".
578 +-------------------+
580 +-------------------+
583 +-------------------+
585 +-------------------+
587 +-------------------+
590 +-------------------+
591 28 - 40 | syms | (present if flags[4] or
593 +-------------------+
596 +-------------------+
599 +-------------------+
601 +-------------------+
603 +-------------------+
605 +-------------------+
612 +-------------------+
615 fields in the Multiboot information structure. All as-yet-undefined
632 OS image from. If the OS image was not loaded from a BIOS disk, then
636 four one-byte subfields as follows:
638 +-------+-------+-------+-------+
640 +-------+-------+-------+-------+
643 BIOS INT 0x13 low-level disk interface: e.g. 0x00 for the first floppy
647 specifies the "top-level" partition number, `part2' specifies a
648 "sub-partition" in the top-level partition, etc. Partition numbers
650 example, if the disk is partitioned using a simple one-level DOS
656 `part2' contains the BSD sub-partition within that DOS partition, and
660 from 4 and increasing, rather than as nested sub-partitions, even
669 passed to the kernel. The command line is a normal C-style
670 zero-terminated string.
673 the kernel what boot modules were loaded along with the kernel image,
680 +-------------------+
683 +-------------------+
685 +-------------------+
687 +-------------------+
691 associated with that particular boot module; it is a zero-terminated
697 is specific to the operating system. The `reserved' field must be set
705 +-------------------+
710 +-------------------+
712 These indicate where the symbol table from an a.out kernel image can
713 be found. `addr' is the physical address of the size (4-byte unsigned
715 immediately by the array itself, then the size (4-byte unsigned long) of
716 a set of zero-terminated ASCII strings (plus sizeof(unsigned long) in
727 +-------------------+
732 +-------------------+
752 +-------------------+
753 -4 | size |
754 +-------------------+
760 +-------------------+
765 upper 32 bits, for a total of a 64-bit starting address. `length_low'
767 `length_high' is the upper 32 bits, for a total of a 64-bit length.
782 +-------------------+
784 +-------------------+
786 +-------------------+
788 +-------------------+
792 +-------------------+
793 10 - xx | drive_ports |
794 +-------------------+
818 two-bytes integers, and is terminated with zero. Note that the array
829 booting the kernel. The name is a normal C-style zero-terminated string.
834 +----------------------+
844 +----------------------+
848 protected mode 32-bit code segment, the offset of the entry point, the
849 protected mode 16-bit code segment, the protected mode 16-bit data
850 segment, the flags, the length of the protected mode 32-bit code
851 segment, the length of the protected mode 16-bit code segment, and the
852 length of the protected mode 16-bit data segment, respectively. Only
879 Multiboot boot loaders may simulate VBE on non-VBE modes, as if they
915 non-trivial, at best. Many kludges have been made to various operating
917 many conditions. To encourage the use of general-purpose solutions to
924 INT 15h, AX=E820h -- Query System Address Map call. See *Note Query
960 -------------------------------
984 -------------------------------
986 This first step may be unnecessary, but first create copy-on-write
1021 Multiboot-compliant boot loader and for reference to how to implement a
1029 Multiboot-compliant boot loader loads and execute it, it initialize the
1051 -----------------
1055 /* multiboot.h - the header for Multiboot */
1084 /* The magic number passed by a Multiboot-compliant boot loader. */
1179 ------------
1183 /* boot.S - bootstrap the kernel */
1220 .long -(MULTIBOOT_HEADER_MAGIC + MULTIBOOT_HEADER_FLAGS)
1267 --------------
1271 /* kernel.c - the C part of the kernel */
1330 /* Am I booted by a Multiboot-compliant boot loader? */
1341 printf ("flags = 0x%x\n", (unsigned) mbi->flags);
1344 if (CHECK_FLAG (mbi->flags, 0))
1346 (unsigned) mbi->mem_lower, (unsigned) mbi->mem_upper);
1349 if (CHECK_FLAG (mbi->flags, 1))
1350 printf ("boot_device = 0x%x\n", (unsigned) mbi->boot_device);
1353 if (CHECK_FLAG (mbi->flags, 2))
1354 printf ("cmdline = %s\n", (char *) mbi->cmdline);
1357 if (CHECK_FLAG (mbi->flags, 3))
1363 (int) mbi->mods_count, (int) mbi->mods_addr);
1364 for (i = 0, mod = (module_t *) mbi->mods_addr;
1365 i < mbi->mods_count;
1368 (unsigned) mod->mod_start,
1369 (unsigned) mod->mod_end,
1370 (char *) mod->string);
1374 if (CHECK_FLAG (mbi->flags, 4) && CHECK_FLAG (mbi->flags, 5))
1381 if (CHECK_FLAG (mbi->flags, 4))
1383 aout_symbol_table_t *aout_sym = &(mbi->u.aout_sym);
1387 (unsigned) aout_sym->tabsize,
1388 (unsigned) aout_sym->strsize,
1389 (unsigned) aout_sym->addr);
1393 if (CHECK_FLAG (mbi->flags, 5))
1395 elf_section_header_table_t *elf_sec = &(mbi->u.elf_sec);
1399 (unsigned) elf_sec->num, (unsigned) elf_sec->size,
1400 (unsigned) elf_sec->addr, (unsigned) elf_sec->shndx);
1404 if (CHECK_FLAG (mbi->flags, 6))
1409 (unsigned) mbi->mmap_addr, (unsigned) mbi->mmap_length);
1410 for (mmap = (memory_map_t *) mbi->mmap_addr;
1411 (unsigned long) mmap < mbi->mmap_addr + mbi->mmap_length;
1413 + mmap->size + sizeof (mmap->size)))
1416 (unsigned) mmap->size,
1417 (unsigned) mmap->base_addr_high,
1418 (unsigned) mmap->base_addr_low,
1419 (unsigned) mmap->length_high,
1420 (unsigned) mmap->length_low,
1421 (unsigned) mmap->type);
1451 /* If %d is specified and D is minus, put `-' in the head. */
1454 *p++ = '-';
1456 ud = -d;
1466 *p++ = (remainder < 10) ? remainder + '0' : remainder + 'a' - 10;
1475 p2 = p - 1;
1482 p2--;
1560 -----------------------------
1563 as GNU Mach and Fiasco `http://os.inf.tu-dresden.de/fiasco/'. And, it
1575 Multiboot-compliant boot loader, supporting all required and optional
1604 <bug-grub@gnu.org>, from Bryan Ford and Erich Stefan Boleyn.
1636 Node: Boot-time configuration5488
1641 Node: OS image format12418