Lines Matching refs:image
125 image from a variety of sources, including floppy disk, hard disk, and
129 relevant OS image and boot module data on disk, such as by
160 OS images should be easy to generate. Ideally, an OS image should simply
168 boot process is created, whereas every bit of code in the OS image
182 formats in existence in order to load the OS image -- otherwise the
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
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
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_
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
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
257 A boot loader or an OS image which follows the rules defined as
260 image doesn't need to follow the rule.
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
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
354 …Node: Header magic fields, Next: Header address fields, Prev: Header layout, Up: OS image format
364 The field `flags' specifies features that the OS image requests or
368 reason, it must notify the user and fail to load the OS image.
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
410 …der address fields, Next: Header graphics fields, Prev: Header magic fields, Up: OS image format
422 "synchronize" the mapping between OS image offsets and physical
427 segment. The offset in the OS image file at which to start loading
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 fo…
459 the OS image. If the mode exists, the boot loader should set it, when
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,…
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
560 FIXME: Split this chapter like the chapter "OS image format".
632 OS image from. If the OS image was not loaded from a BIOS disk, then
673 the kernel what boot modules were loaded along with the kernel image,
712 These indicate where the symbol table from an a.out kernel image can
1641 Node: OS image format12418