Lines Matching refs:boot
82 This file documents Multiboot Specification, the proposal for the boot
116 Every operating system ever created tends to have its own boot loader.
118 installing a whole new set of boot mechanisms, each with completely
119 different install-time and boot-time user interfaces. Getting multiple
122 choice of boot loaders for a particular operating system --- if the one
131 boot loader and a operating system, such that any complying boot loader
133 specification does @emph{not} specify how boot loaders should work ---
141 most common and have the largest variety of operating systems and boot
143 need a boot specification and do not have one already, a variation of
157 immediately be able to take advantage of existing boot loaders. It would
165 It should be possible to write compliant boot loaders that load the OS
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),
173 special @dfn{boot partition} (e.g. OS/2), or even loading from within
174 another operating system (e.g. the VSTa boot code, which loads from
175 DOS). Similarly, network-based boot loaders could use a variety of
178 It is hoped that boot loaders will be created that support multiple
184 @section Configure an operating system at boot-time
188 dynamically at boot time. While this specification should not dictate
189 how this configuration information is obtained by the boot loader, it
190 should provide a standard means for the boot loader to pass such
203 a boot loader, that is probably appropriate, because all the memory
204 consumed by the boot loader will typically be made available again after
205 the boot process is created, whereas every bit of code in the OS image
208 switching code generally needs to be in the boot loader anyway in order
217 to @sc{elf}. It is highly desirable for boot loaders not to have to be
219 existence in order to load the OS image --- otherwise the boot loader
224 @dfn{Multiboot header} (@pxref{OS image format}), which allows the boot
238 boot time in order to access devices, mount file systems, etc. While
243 system and user if the boot loader can load these additional modules
246 Thus, this specification should provide a standard method for a boot
247 loader to indicate to the operating system what auxiliary boot modules
249 support multiple boot modules, but they are strongly encouraged to,
250 because some operating systems will be unable to boot without them.
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}
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
270 @item boot loader
272 operating system to be run on the machine. The boot loader may itself
274 relevant to this specification. Only the @emph{final} stage of the boot
277 to be @dfn{Multiboot-compliant}; earlier boot loader stages may be
281 The initial binary image that a boot loader loads into memory and
285 @item boot module
286 Other auxiliary files that a boot loader loads into memory along with
291 A boot loader or an OS image which follows the rules defined as
293 rule as @dfn{should} or @dfn{may}, a Multiboot-complaint boot loader/OS
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.
323 The state of a machine when a boot loader starts an operating
327 The format of information passed by a boot loader to an operating
402 requires of an boot loader. Bits 0-15 indicate requirements; if the
403 boot loader sees any of these bits set but doesn't understand the flag
406 optional features; if any bits in this range are set but the boot loader
412 If bit 0 in the @samp{flags} word is set, then all boot modules loaded
415 containing boot modules directly into a paged address space during
416 startup, and thus need the boot modules to be page-aligned.
421 boot loader is capable of passing a memory map (the @samp{mmap_*} fields)
429 8-24 in the Multiboot header are valid, and the boot loader should use
434 format. Compliant boot loaders must be able to load images that either
470 If this field is zero, the boot loader assumes that the text and data
474 Contains the physical address of the end of the bss segment. The boot
476 occupies to avoid placing boot modules and other data relevant to the
477 operating system in that area. If this field is zero, the boot loader
481 The physical address to which the boot loader should jump in order to
491 mode by the OS image. If the mode exists, the boot loader should set
493 boot loader should fall back to a similar mode, if available.
501 expansion. Note that the boot loader may set a text mode, even if this
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
532 boot loader that the operating system can also be loaded from).
536 information structure provided by the boot loader (@pxref{Boot
581 However, other machine state should be left by the boot loader in
583 DOS, if that's what the boot loader runs from). In other words, the
586 structures before doing so. Also, the boot loader must leave the
598 through which the boot loader communicates vital information to the
600 the structure as it chooses; all information passed by the boot loader
604 placed anywhere in memory by the boot loader (with the exception of the
605 memory reserved for the kernel and boot modules, of course). It is the
654 be set to zero by the boot loader. Any set bits that the operating
669 field is valid, and indicates which @sc{bios} disk device the boot
689 The three remaining bytes specify the boot partition. @samp{part1}
705 nature. For example, if the boot loader boots from the second extended
716 indicate to the kernel what boot modules were loaded along with the
720 indicating no boot modules were loaded, even if bit 1 of @samp{flags} is
736 The first two fields contain the start and end addresses of the boot
738 be associated with that particular boot module; it is a zero-terminated
741 string might be a command line (e.g. if the operating system treats boot
743 system treats boot modules as files in a file system), but its exact use
745 set to 0 by the boot loader and ignored by the operating system.
864 @samp{drive_mode} field represents the access mode used by the boot
894 is valid, and contains the physical address of the name of a boot
951 Multiboot boot loaders may simulate @sc{vbe} on non-@sc{vbe} modes, as
959 document, but are included for prospective operating system and boot
966 * Example boot loader code::
977 memory may be reported. It is @emph{highly} recommended that boot
995 boot loader to work unmodified with any reasonable extensions of the
1092 Multiboot-compliant boot loader and for reference to how to implement a
1096 The kernel @file{kernel} consists of only three files: @file{boot.S},
1098 @file{boot.S} is written in GAS (@pxref{Top, , GNU assembler, as.info,
1100 comply with the specification. When a Multiboot-compliant boot loader
1106 which checks if the magic number passed by the boot loader is valid and
1114 * boot.S::
1130 @node boot.S
1131 @subsection boot.S
1133 In the file @file{boot.S}:
1136 @include boot.S.texi
1160 @node Example boot loader code
1161 @section Example boot loader code
1164 is a full Multiboot-compliant boot loader, supporting all required and
1187 BIOS drive information, BIOS configuration table, the name of a boot