Lines Matching refs:image

166 image from a variety of sources, including floppy disk, hard disk, and
170 relevant OS image and boot module data on disk, such as by
197 OS images should be easy to generate. Ideally, an OS image should simply
205 the boot process is created, whereas every bit of code in the OS image
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
225 loader to load the image without having to understand numerous a.out
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
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
271 Whatever program or set of programs loads the image of the final
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
291 A boot loader or an OS image which follows the rules defined as
294 image doesn't need to follow the rule.
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
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
405 notify the user and fail to load the OS image. Bits 16-31 indicate
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}
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
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
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
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
594 FIXME: Split this chapter like the chapter ``OS image format''.
670 loader loaded the OS image from. If the OS image was not loaded from a
717 kernel image, and where they can be found. @samp{mods_count} contains
763 These indicate where the symbol table from an a.out kernel image can be