i86/mtx/docs/02-booting.txt

   1 460 Notes #2 Booting OS
   2
   3
   4 1. Booting in General:
   5    The process of starting up an operating system from a disk or equivalent is
   6    called booting or bootstrap. Different machines may have different sequence
   7    of actions during booting. To be more specific, we shall consider the booting
   8    sequence of Intel 80x86 based PCs.
   9
  10    Every PC has a ROM, which contains a set of programs called the BIOS.
  11    When power is turned on or following a reset, the CPU starts executing
  12    BIOS.  BIOS checks the system hardware, initializes itself, including
  13    setting up the interrupt vectors at low memory area to point to its
  14    service routines.  Then, it starts to look for a device to boot.
  15    Bootable devices are maintained in a programmable CMOS memory, which include
  16    floppy disk, hard disk, CDROM and USB drive. The booting order is usually
  17    A:(floppy disk), then C: (first hard disk). If there is a diskette in A:,
  18    BIOS will try to boot form it. Otherwise, it will try to boot from C: etc.
  19
  20    A booter is a program that boots up itself first. Then it loads another
  21    program, such as an operating system, into memory for execution. A booter
  22    usually occupies the first sector (or block) of a bootable device.
  23
  24 1.1. Boot from floppy disk.
  25    When booting from a FD, BIOS loads the very first sector (512 bytes) of
  26    the disk into (segment, offset)=(0x0000, 0x7C00), and jump to there to
  27    executes the booter.  After this, it is entirely up to the booter code
  28    to do the rest.
  29
  30    In order to make room for the OS to be loaded, the booter usually relocates
  31    itself to a high memory area, from where it continues to load the OS image
  32    into memory. When loading completes, the booter simply transfers control to
  33    the OS, causing it to start up.
  34
  35 1.2  Boot from hard disk
  36    Booting from a hard disk is only slightly more complex. A hard disk is
  37    usually divided into several logically independent units, called
  38    partitions.  The start cylinder, end cylinder and size of the partitions
  39    are recorded in a Partition Table. The very first sector of a hard disk
  40    is called the Master Boot Record (MBR). It contains a boot program, the
  41    Partition Table, and the boot signature at the end. Each partition may
  42    contain a bootable system. If so, each partition may have its own booter
  43    in the first sector (or block) of that partition.
  44
  45    During booting, BIOS loads the MBR to (0x0000, 0x7C00) as usual, and turns
  46    control over to it. Once execution starts, the MBR boot program has two
  47    options:
  48    (1). it may boot an OS directly, as the Linux booters LILO (LInux LOader),
  49         GRUB (GRneral Universal Booter) and KCW's booter do, OR
  50    (2). it may act as a CHAIN booter, in which case it searches for an active
  51         partition to boot, and then loads the partition's boot sector to
  52         (0x0000,0x7c00) and truns control over to it. It is now up to the
  53         partition's booter to load and start the OS from that partition.
  54
  55 1.3. Boot from CD(DVD)ROM:
  56     A bootable CD(DVD)ROM is created by first creating an ISO9600 file system
  57     and then writing it to a CD or DVD disc. A bootable CD-DVD has three
  58     options:
  59     (1). Emulating a floppy disk: the boot image is a bootable FD image. Upon
  60          booting up, the FD image is accessed as drive A: while the physical A:
  61          drive is demoted to B: drive.
  62     (2). Emulating a hard disk: the boot image is a bootable HD image with a
  63          single partition. Upon booting up, the HD image becomes C: while the
  64          phisical C: drive is demoted to D:, etc.
  65     (3). NON-emulated booting: the boot image is booted as is. Upon booting up,
  66          the CD (DVD) is accessed as a device determined by BIOS, i.e. device
  67          number = a byte value randomly assigned by BIOS.
  68
  69     It is noted that in all the above cases, although the boot device is known,
  70     the contents of the CD(DVD)ROM are NOT accessible unless the booted up
  71     environment includes drivers to access the file system on the CD(DVD).
  72
  73 1.4. Boot from USB drive: This is almost identical to booting from HD. During
  74      booting, BIOS emulates a USB drive as C: drive.
  75
  76 2. Bootable MTX Image
  77
  78 MTX is a Unix-like operating system developed by KCW. It is designed to run on
  79 Intel-based PCs or any PC emulators, such as DOSEMU, QEMU, VirtualBox, VMware,
  80 etc. It has several versions: The simplest version is RMTX, which runs in 16-bit
  81 unprotected mode from either a floppy disk or hard disk partition. PMTX is MTX
  82 in 32-bit protected mode, which runs on hard disk partitions. In protected mode,
  83 MTX uses virtual memory by either segmentation or dynamic paging. SMP_MTX is for
  84 SMP operations in protected mode. It runs on either real multi-core PCs or
  85 VMware VMs on multi-core PC hosts. For simplicity (and safety), we shall begin
  86 with MTX on floppy disks.
  87
  88 From the samples/LAB1/ directory, you can download the file mtximage (or
  89 mtximage.bin). Dump it to a floppy disk by
  90                dd if=mtximage of=/dev/fd0
  91 The resulting floppy disk is a bootable MTX system composed of the following
  92
  93     block0 | EXT2 file system (1 KB blocks)
  94     BOOTER |             /
  95                          |
  96                ------------------------
  97                bin  boot dev  etc  user
  98                      |
  99                     mtx
 100
 101 where block0 contains a MTX booter and /boot/mtx is a bootable MTX image file.
 102 During booting, the MTX booter is loaded into memory and runs first. It prompts
 103 for a MTX image (file) name in the /boot directory to boot. The default image
 104 name is mtx. It loads a mtx image to the segment 0x1000, and then jumps to
 105 (segment, offset)=(0x1000, 0) to start up MTX.
 106
 107 4. Working Environment:
 108
 109    When the PC starts up, it is in the so called 16-bit or unprotected
 110    mode. While in this mode, it can only execute 16-bit code (and access
 111    1M bytes of memory).
 112
 113    During booting, we must use BIOS to do I/O because there is NO operating
 114    system yet. BIOS functions are called by the
 115                INT  #n
 116    instruction, where the number n indicates which BIOS function we are
 117    calling. Parameters to BIOS functions are passed in CPU registers.
 118    Return value is in the AX register.
 119
 120    Boot programs are usually written entirely in (16-bit) assembly code
 121    becaue their logic is quite simple, namely, to load the disk sectors
 122    of an OS into memory. They do not have to know how to FIND the image
 123    of an OS.
 124
 125    Based on the above discussions, a quick summary is in order:
 126
 127                     During booting:
 128
 129    (1). We must call BIOS functions to do I/O, so assembly code is
 130         un-avoidable !!!!  But this should be kept to a minimum.
 131
 132    (2). Our boot program must FIND a bootable OS image, such as Linux or MTX,
 133         file to load. Although it is possible to write such a program in
 134         assembly, it would be rather silly to do so. The major part of it should
 135         be written in C.
 136
 137    (3). Linux's gcc compiler generates 32-bit code, whcih is unusable during
 138         booting.  We must use a C compiler and a linker that generate 16-bit
 139         machine code.
 140
 141    (4). To meet these requriements, we will use bcc, as86 and ld86 package,
 142         which runs under Linux but generates 16-bit code for Intel processors.
 143
 144 5. Boot Generic Linux Kernel with initrd (Initial Ramdisk) support:
 145    The configurations of Linux systems vary greatly. It is impractical to
 146    generate a Linux kernel with all possible device drivers built-in. A common
 147    way of dealing with different Linux configurations is to compile the device
 148    drivers as modules, and generate a generic bootable kernel that can boot
 149    up and run off a RAMdisk (initrd) first. The initrd provides a minimum root
 150    file system for the Linux kernel, including a sh interpreter. While in this
 151    simple environment, Linux can execute an init sh script to install the
 152    needed device drivers for the REAL root file system. After that, the kernel
 153    can umount the initrd and mount the REAL root file system.
 154
 155    As an example, I have installed Linux on a USB drive. During booting, the
 156    Linux (2.6.27.7 SMP kernel) is booted up first with an initrd image as root.
 157    Then it executes an init file to install the USB driver modules. Then it
 158    switches the root device from initrd to the USB drive and run on the USB
 159    drive.
 160    Another common example is to install Linux from a bootable CD (DVD). During
 161    booting, a generic Linux kernel is booted up from the CD with an initrd
 162    image as root. It then install the CD (DVD) driver modules, allowing the
 163    Linux kernel to mount and read the CD(DVD) contents, which are Linux
 164    installation files in either tgz or RPM formats.
 165
 166