i86/mtx-16-bit/mtx/booting.html

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