NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/os/minix/4238

Internet Message Format | 1992-08-18 | 29.5 KB

Xref: sparky comp.os.minix:4238 fj.sources:658 fj.os.minix:217
Path: sparky!uunet!sun-barr!sh.wide!ascwide!ascgw!uitecgw!nemossan
From: [e-mail] (Sakurao NEMOTO)
Newsgroups: comp.os.minix,fj.sources,fj.os.minix
Subject: Inside of MXboot/minix-V: Part-1....booting processes (English)
Summary: Inside document on MXboot-201/minix-V for IBM-PCs/clones
     supports both v1(minix-1.5) and v2(minix-1.6.16) File-Sytems
     and 16/32-bits minix.
Keywords: MXboot, HDD-boot, minix, minix-V, PC/clones, Japanese-Kanji
Message-ID: <[e-mail]>
Date: 19 Aug 92 03:11:17 GMT
References: <[e-mail]> <[e-mail]>
Followup-To: comp.os.minix
Organization: Univ. Industrial Tech., Sagamihara, JAPAN
Lines: 632


This  is  the Part-1  of "inside-documents" of  MXboot and minix-V,  and
describes processes to boot-up Minix.

In this document, "Bible" should be read as our text book by  Prof. Andy
    Operating Systems: Design and Implementation
        by Andrew S. Tanenbaum
        Prentice-Hall, 1987


This is originally written by takamiti@mix, the developper of MXboot and
minix-V,  the former is a system  to  boot-up Minix from HDDs,  and  the
latter is a system  to display  Japanese-Kanji (and  other  2-byte-coded
Language) in Minix on IBM-AT/clones.

This is  originally  written in  Japanese  and  trially translated  into
(broken :-) English by nemossan@mix == [e-mail].

========================================================================
Table of contents
0.    Introduction
1.0    Reading the DISK-IPL
2.0    Booting process from the floppy
2.1    structure of Minix-boot-disks
2.1.1        How original "bootblok.s" works
2.2.2        how "bootblok.x" in Mix-version (MXboot/minix-V) works
3.0    Booting from Hard Disks
3.1    How to control the Hard-disks
3.2    Master-IPL of a Hard-disk
3.2.1        Master-IPL of a standard Hard-disk
3.2.2        assistIPL
3.2.2.1        Memory-map of assistIPL
3.2.2.2        How assistIPL works
3.3    MXboot: boot-loader of Minix on Hard-disks
3.3.1        Memory-map of MXboot
3.3.2        outline of MXboot
3.3.2.1        preparation stage
3.2.2.2        searching the image file
3.3.2.3        Loading the image-file.
3.3.2.4        Transfering control from MXboot to mune
3.4    what "menu" do when booted from Hard-drive.
========================================================================
0.    Introduction
    How do you think about the process  after the machine is powered on?
It is written in our Bible about the process  after the control is given
to the kernel of Minix, so refer it on the process after it.  Here let's
consider  about  the  processes  after  the  System-ROM initialized  the
hardware,  and  how to read the kernel of Minix from a floppy or a Hard-
disk,  and  how to  give the control  to  the start-up routine of Minix.
Official-Minix  does not support  booting  from  Hard-disks,  but we can
boot-up minix via "assistIPL" + "MXboot", so  I'll explain the processes
in this system as an example.

    By the way, the structure of the Minix-File-system is written in our
Bible,  so  I'll not write here, please refer it.  You can get the manul
on  managing  the partition  from  IBM-Japan,   titled  "BIOS  interface
manual", so refer it.  This was the best manual I've ever had,  in other
words, there is very little amount of manuals... ;-)   But, it should be
good for us that official manual is availalbe.  There are many makers in
Japan, who want to keep secret their hardwares.

    There may be many mistakes  where I explain with the pseud-code, but
I hope you can understand.  (^_^;;)



1.0    Reading the DISK-IPL

    After the initializations of the hardware by the system-ROM,   trial
to load the "disk-IPL" from Floppy:system-#0 (usually Drive A:) is made.
If the no-floppy is inserted into the drive  the trial fails,  then BIOS
tries to read from the First-HDDrive.  If this fails too, ps55 from IBM-
Japan boots ROM-Basic, according to the manual from IBM-Japan,  and IBM-
clones will show BIOS-setup menu (really?  this is the case of my clone,
I don't know other machines).

    This Disk-IPL  is  written in its physical top-sector,  in both FDDs
and HDDs,  and it will be loaded to  the absolute address  0x7C00 at the
last of the BIOS routine,  and  the cotrol  will be transfered  into the
address 0x7C00.  After that,  all the control will be done  by  the code
written in the disk, and thus the Operating-System written there will be
booted.



2.0    Booting process from the floppy

2.1    structure of Minix-boot-disks

    Boot disk  of  Minix  differs  its  structure  from usual Minix-file
system.  You can see  the layout of normal file systems  at 5.6.2 in our
Bible,  it has  super block,  bit-map, i-nodes and data-blocks....  Boot
disks differ from them and there written core-image  made by tools/build
sequentially from its start, rather simple structure.   512-bytes of the
top of the core-image  is  written on the first sector of the boot-disk,
and it was loaded at 0x7C00 by BIOS-ROM,  and the rest of the core image
will be loaded by this program onto the memory.



2.1.1    How original "bootblok.s" works

    The  boot-sector,  at the top of the boot-disk,  whose size is  512-
bytes, can be seen such structure as

    struct org_boot_sector {
    byte  ipl_code[504];    /* boot code */
    short load_sectors;    /* number of sectors loaded by bootblok */
    short menu_ds;        /* value of DS in menu */
    long  menu_pc;        /* start-address of menu */
    }

Where  "ipl_code[]"  contains  the program code  to load  the core-image
shown tools/bootblok.s, and "load_sectors",  "menu_ds" and "menu_pc" are
calculated by "build" when it combines "kernel", "mm", "fs", "init"  and
"menu" to make boot-image, they are written on the first-sector.

    Initial-Program-Loader of the ROM-BIOS  loads this "org_boot_sector"
to absolute address 0x7C00, and the control is given to its top-address,
ipl_code[].  After  it, "bootblok.s", of the original PH-code, relocates
itself to  absolute address 0x3F700  and  loads the main body of kernel-
image  onto  the absolute address at  0x600.   After  all of the sectors
shown in  "load_sectors"  have been  loaded  from  the boot-floppy,  the
values shown "menu_ds" are set to the data-segments, DS, ES and SS, then
it indirectly-long-jumps  to  the address written on "menu_pc", which is
the start-address of the "menu"-program.

    After the "menu" starts, it is a usual course of changing the "boot-
disk" to "root-file-system", pressing <=>-key, then Minix starts.



2.2.2    how "bootblok.x" in Mix-version (MXboot/minix-V) works

    "bootblok.x" accompanied with  "MXboot-2.01"  or  "minix-V" from Mix
has the same concept with the original "bootblok.s" from PH,  but it has
different structure for loading big (more than 400kB) core-image  or  to
support "MXboot".  It looks like

    struct mix_boot_sector {
    short jmp_id; (0x02EB)    /* jmp short &ipl_code[0] */
    short open_msg;        /* address of subroutine for opening message */
    byte  ipl_code[500];    /* boot code */
    short load_sectors;    /* number of sectors loaded by bootblok */
    short menu_ds;        /* value of DS in "menu" */
    long  menu_pc;        /* start-address of "menu" */
    }

Different from PH-original,  you will see  0x02EB constant at the top of
it, then the start address of the subroutine to show "Booting MINIX ..."
message follows.  The constant "0x02EB" is  a short-jump instruction  to
the address of "ipl_code[0]".   Those  4-bytes may be seen as  wastes of
memory at first glance,  but it is prepared for MXboot,  which I'll tell
you later.  In  MXboot, "0x02EB" is treated as a kind of  identifier and
"open_msg"   is  refered   at  the  time  of  subroutine  call  to  show
"Booting ...".

    Instruction-codes  for  booting  the kernel-image  are  contained in
"ipl_code[]",  and after the control is given from ROM-BIOS,  it  starts
running via "0x02EB" short-jump instruction.   Program-codes  start from
ipl_code[]  loads  "kernel" onto absolulte address 0x600  and  jumps  to
"menu"  same as  original PH-version, but the address to relocate itself
differs.  In  case of  PH-original-version,  the  relocating address  is
written in the source-code, thus the address is fixed, while Mix-version
tests the upper-limit of the real-memory  by "int 0x12" and relocates to
the address below 4kB of the upper_limit.  For example, if the amount of
the real-memory is 640-kB, the upper-limit address is 0xA0000,  then the
contents of the boot-sector will be relocated to 0x9F000. Thus the load-
ing of  more than 400kB  of  kernel-image  (of 32-bit-Minix) can be made
successfully to boot-up it.



3.0    Booting from Hard Disks

    Original Minix does not support booting from the Hard-disk, but I'll
tell you  how  the master-IPL of the hard-disk loads an OS  and  tranfer
control on it, and booting process of Minix by "assistIPL" + "MXboot".



3.1    How to control the Hard-disks

    "BIOS-interface manual" from IBM-Japan tells how to control the par-
tition-table of hard-disk  in detail.  The followings are the summary of
it.
    One hard-disk  is able to  have upto four-partitions, and any one of
the partition  can  boot-up an OS.  The table for control the partitions
is  placed from the 446-th byte of the boot-sector of the Hard-disk, and
it uses 16-bytes  to control  one partition, its structure is equivalent
to the one listed below.   At the last 2-byte of the boot-sector (510-th
and 511-th byte counting from 0), there written "boot-sector-ID", "0x55"
and "0xAA", which show this is valid boot-sector.

    typedef struct {
    byte head;
    byte sector;
    byte cyl;
    } hd_addr;

    typedef struct {            /* shows one partition */
    byte    boot_id;    /* bootable-partition (0x80) or not (0x00) */
                /* "fdisk" writes 0x80 to active-partiton */
                /* plural partitions may not be active */
    hd_addr    start;        /* head/sector/cylinder of the start */
    byte    system_id;    /* shows the OS-type in the partition */
    hd_addr end;        /* head/sector/cylindar of the end */
    long    start_sector;    /* top sector address of the partition */
    long    nr_sector;    /* number of sectors in the partition */
    } partition;

    struct hd_boot_sector {        /* shows total of the drive */
    byte ipl_code[446];    /* master-IPL codes for Hard-disk */
    partition part_tab[4];    /* partition-tables */
    short ipl_id; (0xAA55)    /* ID to show effective boot-sector 0xAA55 */
    }

where
    partition.system_id:
    is a code to show the type of OSs installed in this partition.
    Codes for various OSs are as follows (quoted from fdisk.c/*systype()).
        0x00:    not used area
        0x01:    PC-DOS, 12-bit-FAT
        0x02:    XENIX
        0x03:    XENIX(OLD)
        0x04:    PC-DOS, 16-bit-FAT (less than 32MB)
        0x05:    PC-DOS extended
        0x06:    PC-DOS, 16-bit-FAT (more than 32MB)
        0x08:    AIX
        0x09:    OPUS
        0x51:    NOVELL?
        0x52:    CP/M?
        0x63:    386/IX
        0x64:    NOVELL
        0x75:    PCIX
        0x80:    OLD-MINIX
        0x81:    MINIX
        0xDB:    CP/M
        0xFF:    BAD BLOCKS

    partition.start, partition.end
    They contain start and end addresses of cylindar/head/sector  in
    this partition.  Every partition (except the top partition which
    starts from the drive) should be aligned to head=0, sector=1.
    "start.cyl" and "start.sector" correspond to the value to be set
    on CX-register at the DISK-BIOS call (int 0x13), and 2-bits from
    MSB of "start.sector"  and 8-bits of "start.cyl" decide the cyl-
    indar address in 10-bits.

    partition.start_sector
    This contains the start sector address of the partition.

    partition.nr_sectors
    This contains the number of sectors in the partition.



3.2    Master-IPL of a Hard-disk

    Master-Initial-Program-Loader  is placed at the top of an Hard-disk,
ie. boot-sector,  in order to  boot-up the OSs installed in every parti-
tion,  as well as  the managing table  for partitions.  This IPL will be
loaded onto 0x7C00  after  ROM-BIOS's initialization, and the control is
moved to the code written in the master-IPL of the Hard-drive.



3.2.1    Master-IPL of a standard Hard-disk

    Standard master-IPL of IBM-PCs and its clones works as follows;
    At first, it relocates itself, because the address of the loader for
the OSs to be loaded after the Master-IPL is 0x7C00, same address of the
Master-IPL.  In many cases its relocating address is 0x600.

    Next, it searches partition-table to find the active-partition, then
the loader of the OS (of the active-partition) is loaded onto 0x7C00, at
last the control will be transfered into the address.  In these process,
such checks  will be  done as  "Is there 'boot-ID:0xAA55'?",  "Do plural
partitions have active-flag?"  or  "Does no partiton have active-flag?".
If any trouble are found, it displays an Error-messaage and stops.

    If no error is found in the checks and the loader of the OSs written
in the active partition  (size is 1 [sector] == 512 [bytes]) is success-
fully loaded,  then  the top-address of the partition table  is  set  to
DS:SI, and control moves there.   For example, when the second partition
is active  and  the OS  is  loaded  from  the  partition,  then
"&hd_boot_sector.part_tab[1]" will be set to DS:SI.



3.2.2    assistIPL

    At the time of  boot,  you cannot  select OSs  to be booted-up,   if
limited to the standard master-IPL.   If you use only one OS, it must be
no problem, but if you use ex. both ??-dos and Minix, you have to change
active-partition  by the tool like "fdisk",  every time when you want to
change OS.   It is very inconvenient, isn't it?    "assisstIPL"  has the
function of standard-IPL,  further more,  it has the function to  select
OSs.   Functions  of "assistIPL" are as follows;
    1.  For the active-OS,  you can  boot it up  without any manual-
        operation (same as standard-IPL).
    2.  You can select  boot-OS  at the time of  booting.   You  can
        boot-up the OS even the partition is non-active (changing it
        to be active or remaining non-active).
    3.  The setting of active-partition  can be done by  the conven-
        tional tools such as "fdisk",  moreover "assistIPL"  has the
        function  to select the partition  and  set  it  as  active-
        partition, allowing next boot automatically from this parti-
        tion. This can be done at the time of booting (not after the
        boot).
    4.  If the OS's loader has its function, the OS can be booted up
        even from the second-Hard-Drive (at least Minix under MXboot
        can be booted).



3.2.2.1    Memory-map of assistIPL

    "assistIPL" is  a masterIPL  of a hard-disk  and placed at the boot-
sector.  It will be loaded  on  0x7C00  by  the IPL-routine of ROM-BIOS,
then it works.   Like the other masterIPLs,  assistiIPL reloactes itself
to 0x600,  then does its own  works.  The memory map  at the time  is as
follows;

    ^                      ^
    ^                      ^
    |----------------------|
    |     512 bytes        | <- assistIPL loads OS-loader, here
0x07C00 +======================+ <- upper-limit of assistIPL's stack
    |                      |        (sp is set here at the start)
    ^                      ^
    ^                      ^
    |------------------55AA|
    |      64 bytes        | <- work-area of partition-table
    |~~~~~~~~~~~~~~~~~~~~~~|
    |     446 bytes        | <- code and data area of assistIPL
0x00600 +======================+
    ^                      ^
    ^                      ^
    |                      | <- work-area for BIOS and table for
    |                      | <- interrupt-vectors
0x00000 +----------------------+
    ////////////////////////



3.2.2.2    How assistIPL works

    "assistIPL"  has compatible mode with the standard-IPL, and has also
specific function to select boot-partition.   The latter  does not  work
unless  the  operator  intendedly  call,  thus  usually  it  works  like
standard-IPL.

    "assistIPL"  checks  if the <shift>-key  is pressed,  at the time of
waiting the stopping of the FDD-motor.  As I have said earlier,  ROM-IPL
tries to boot from floppy at first,  and if it fails,  it tries  to boot
from HDD.  The motor for FDD keeps rotating after the failure of booting
from FDD by its momemt of inertia.  While waiting this, assistIPL checks
if the <shift>-key is pressed  or  not,  it means partition-selection is
specified or not.

    If <shift>-key has not been pressed in this waiting time,  assistIPL
searches active-partition in the partition-table,  and  loads the loader
of the OS in that partition onto 0x7C00, then jumps there.   This is the
same action as the conventional masterIPL.

    If the <shift>-key has been pressed, or if it has never been pressed
but active partition cannot be  found,  assistIPL enters into  selection
mode of boot-partition. In the selection mode, you will see "No. of HDD-
drives",  "Partition No-s"  and  "system-ID" on the CRT.  Current active
partition number will be shown after the  "Which?" prompt.  (If there is
no-active-partition, it will show "1".)   If you choose a number  from 1
to 4, and press <Enter> or <End>,   the partiton  will be selected,  and
the  machine  will  boot-up  from  the  specified  partition.   In  this
selection,  if  you choose  <Enter>-key,  the OS will be loaded from the
specified  partiton,  while if choose  <End>-key instead of <Enter>-key,
the selected-partition will be set as "active",  and  it is written back
to the boot-sector of the partition,  then  boots-up from the partition,
thus next booting will be done  from this partition  if you do not enter
into the selection-mode.

    After the <Enter> or <End> key,  specifying start of booting, loader
of the OS is loaded.   In datail,  at first it checks whether the parti-
tion is "unused",  then  one-sector  from the partition  be  loaded  and
checked if the first 2-bytes are code or not.  If all of them are normal
in those simple checks,  "boot_id" of the corresponding area  is written
by "0x80", specifying active-area,  and its top-address is set to DS:SI,
then the control will be moved to the loader of the OS just loaded. When
started by <End>-key, partition-table of the drive will be  written-back
before the control transfered into the OS's loader.

    Limiting only to Minix,  you can boot-up even from  any parition  of
the second drive, like in the case of the first-drive.  As usual, IBM-PC
does not support booting from the second-drive (NEC-PC9801 can be booted
from the second drive), so booting-from-2nd-drive may be limited only to
Minix (in Minix, it is done by both "assistIPL" and "MXboot").

    In order to boot-up Minix from the second-drive,  specify "0" parti-
tion on selection-menu of assistIPL.   Then the boot-sector of the other
drive will be loaded to 0x7C00, and assistIPL copies the partition-table
of it.  After that,  the same processes of the selection will be done as
the first drive.   Only one-difference is that "0x81" will be written on
the "boot_id" of the correspondig area.    Loaders of usual OSs check if
the "boot_id" is "0x80", and  if not,  they  cause  error.  Thus MS-DOS,
ex., will fail to boot from the second drive.   This function to boot-up
from the second-drive  is  made in order to boot-up Minix  even there is
no-space for Minix in the first drive.

    At the time of  making  this,  I have read  several MasterIPLs,  and
tried  to find  the conditions  common to them,  and made  assistIPL  to
satisfy such conditions.  Later, I have had the manual  from  IBM-Japan,
and there written as "two 'mov' instructions are enough to set the para-
meter for Disk-BIOS on DX and CX, then the drive-number 0x80 (set at DL)
corresponds to boot_id".



3.3    MXboot: boot-loader of Minix on Hard-disks

    "MXboot"  is  written  on  the   "bootblock"  of  Minix-File-System,
reserved by "mkfs", size of which is 1k-byte,  located at the top of the
Minix-FS,  (refer to our Bible, 5.6.2:File System Layout).   And  MXboot
loads kernel-image from pre-defined Minix-file (usually "/system/minix.sys")
onto the memory, then jumps to "menu"-program.



3.3.1    Memory-map of MXboot

     MXboot will be loaded by assistIPL from 0x7C00, at first 512-bytes,
half  of  its size.   Then  it will load itself again  to the address of
"upper-limit" minus 4kB, this time all of the MXboot is loaded and jumps
normal entry point of MXboot.   The memory map  of  MXboot at the normal
run is as follows;


Upper-limit of Memory
limit   //////////////////////// <- upper-limit returned by "int 0x12"
    |                      |
    | DiskBuff_#2          |
    |    (i-node buffer)   |
    |            (1K bytes)|
limit-1K|======================|
    |                      |
    | DiskBuff_#1          |   ___________________________________
    |    (data buffer)     |  / auxiliary disk buffer (28 bytes max.)
    |            (1K bytes)| /  |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
limit-2K|======================|/   |
    | work area (64 bytes) |    |
    |~~~~~~~~~~~~~~~~~~~~~~|\   |   MXboot work area (28 bytes)
    | stack area           | \  |
    |           (958 bytes)|  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
limit-3K|======================|
    |                      |
    |                      |
    |   MXboot code area   | ___________________________________
    |            (1K bytes)|/       key buffer (14 bytes)
limit-4K|======================|------------------------------------
    ^                      ^
        ^                      ^
        |                      |



3.3.2    outline of MXboot

3.3.2.1    preparation stage

    After the reload to "upper_limit - 4kB"  and  start  its own  entry,
MXboot saves the booted drive number (shown in boot_id of the partition-
table given by DS:SI)  and  relative sector address of the partition  to
its own variables.  Then MXboot decides the entry of the partition-table
(at the boot-sector of the drive)  from  which  MXboot is called.   This
decision is done according to the address shown by DS:SI and  the  boot-
sector-ID, 0xAA55.   Thus MXboot  gets parameters (by Disk-BIOS call) of
the Hard-Drive where it was booted.  All the preparations to access (via
Disk-BIOS) the partition are ready, now.

    Then, MXboot reads the super-block (next to the bootblock) to access
this partition  as a Minix-file-system.   From  the super-block,  MXboot
reads  several data  and  saves  them  to  its  own  work area (slightly
modifying).  These data are 2-bytes magic_number to distinguish the type
of  Minix-File-systems  (V1 or V2),  start addresses (block)  of i-node-
block or zone-block, in short  they are the necessary data  to specify a
certain file and to read the file.   From the magic_number, MXboot knows
the version of  File-system of Minix  (V1:until Minix-1.5   or  V2:after
Minix-1.6), and changes/modifies not only parameter-tables  for the two-
versions of File-systems  but also  program codes  incident to the File-
systems.



3.2.2.2    searching the image file

    MXboot checks  key-board status  before searching predefined kernel-
image file (usualy "/system/minix.sys").  If <shift>-key is pressed,  it
is  operator's command  to change the boot-image  temporaly,  and MXboot
prompts its version-number ("MX.201>" in case of MXboot-V2.01) and waits
for input file name.   The File name of the kernel-image is limited upto
13-characters  in length  and  path  cannot be  specified (restricted to
/system or /).  The  input-buffer  used  here  is  the area  where  were
program-code already used  and  not be used in future.  Key-input can be
edited by <BackSpace>-key, so  miss-typing  can be corrected by <BS> and
if you press  <Enter>  witout  any  keyinput  (including  as a result of
<BS>s),  standard boot-image ("/system/minix.sys") file will be tried to
load.

    Here,  I'll tell you the order of the searching the boot-image file.
    If <shift>-key is not pressed,  MXboot searches "/system/minix.sys".
If it is pressed,  MXboot  prompts file name of boot-image, as mentioned
above, and after the file-name is  given, it searchs the file,  at first
in root (/) directory.  If it fails, MXboot searchs in the sub-directory
"/system".     This   order  of  directories   may  be   curious,    but
"/system/minix.sys" is  the  full-name of the file  including full-path,
and the file-name given by key-input is the only file-name,  which lacks
its path.   Further, even if <shift>-key is not pressed, if there was no
"/system/minix.sys" file,  MXboot  forces to enter into File-name-input-
mode.

    Process to approach to the intended file  is  described in detail on
our  Bible,  see   Fig.5-11  "The  steps  in looking up  /usr/ast/mbox".
According to the steps described there, MXboot searchs the intended file
looking up i-nodes and data-zones.   In order to  read  i-node,  i-node-
buffer mentioed at the memory-map in 3.3.1 is used. For data-zone, data-
buffer is used.   Reading is always done  in block of Minix (1024-bytes,
2-sectors).

    If  the file specified from key-board  cannot be found, MXboot gives
up booting showing "No File. Please reboot".



3.3.2.3    Loading the image-file.

    After finding the i-node of the inteded kernel-image-file, next step
is loading the file onto the memory. At first, contents of i-node.zone[0]
will be loaded into data buffer.  The boot-image to be loaded is the one
which made by "build",  and this is the same as one of the floppy-disks.
So, the contents of the data-block shown by zone[0] is  512-bytes of the
boot-routine from floppy (former-half) and the latter-512-bytes contains
kernel's start-up routine which should be loaded from 0x600. In order to
load the kernel-image,  MXboot should proceed the  first-block.   MXboot
checks,  at first,  top of 2-bytes  of the block.  If they are "0x02EB",
key-word of "bootblok.x" of Mix-version as mentioned in 2.2.2, then next
2-bytes  are  regarded as  the entry-point  to  the Opening-message,  so
(adjusting the data-segment) indirectly-calls to the address
(mix_boot_sector.open_msg) to show "Booting.." message.   If the 2-bytes
are not "0x02EB",  MXboot regards this image-file  as  one of  original-
version (not Mix-version), and resets the variable for automatic-booting
(it will be used after the image-file loaded) and keeps booting.
"*_boot_sector" has the entry address of "menu"  and  the value of data-
segment,  so  MXboot copies them  on its variables  and  calculates  the
block-number to be loaded  by *_boot_sector.load_sectors.   After  these
values are obtained,  the latter 512-bytes  will be  copied into  0x600,
thus ends reading of the most complex block.

    Then  MXboot loads  boot-image of the kernel,  from 0x0600 + 0x0200,
sequentially, moving the pointer.  One point to be careful  at this time
is  block-specification of the i-node, which type is used from "direct",
"indirect"  or  "double-indirect".  MXboot  copies the contents  of from
zone[1]  to zone[6],  direct-zone, to the  auxiliary  disk-buffer.  Then
saving the value of zone[7], indirect-zone, reads the contents  shown by
zone[8] into i-node buffer.   Next, the block shown by zone[7] (saved in
a variable) is read to data buffer.  In case of V2-File-system, indirect
zone continues to zone[9],  but considering the size of the kernel-boot-
image,  the process is  enough upto zone[8] (64-MB, see "5.6.4. I-nodes"
at our Bible).   The disk buffer usage at this time is as follows;
    ________________________
    |                      |
    |                      | <- contents of data block shown
    |     DiskBuff_#2      |    by zone[8]  (double indirect zone)
    |                      |
    |======================|
    |                      |
    |                      | <- contents of data block shown by zone[7]
    |     DiskBuff_#1      |
    |                      |
    |======================|~~~~~~~~~~~~~~~~~~~~ contens of zone[6]..[1]
    |     work area        |\ aux disk buffer    ques here downward to
    |~~~~~~~~~~~~~~~~~~~~~~| \__________________ lower memory address
    |    stack area        |


    Thus the numbers of blocks which show the addresses of boot-image of
Minix  is arranged  from  top of the auxiliary buffer,  ie.  the  lowest
address, to DiskBuff_#1.  To read image-file, put the pointer to the top
of the aux-buffer  and  read  the contents of block shown by it, sequen-
tially.   When the pointer arrived at the bottom of the Buffer_#1,  then
get the indirect-block address from DiskBuff_#2 and the contents of  the
block  should be  loaded  into  memory  increasing  the pointer  to  the
DisdBuff_#1.....until the block-number is satisfied.  Of course, increa-
sing the pointer should be in 1024-bytes.



3.3.2.4    Transfering control from MXboot to mune

    After the boot-image loaded successfully,  MXboot  long-jumps to the
entry of "menu" setting partition number (where started booting) to  BH,
and  data-segment value to DS, ES  and SS.   When "bootblock" is not one
expected and automatic booting is suspended, "0x000F" will be set on BX.
(no matter if MSB of "BL" is reset).



3.4    what "menu" do when booted from Hard-drive.

    MXboot  loads  kernel-image-file  from Minix's file system.   MXboot
knows the drive-number  and  its partition number  where it is  written,
so it tells to  "menu", and  "menu"  sets these  as root-file-system  of
Minix.  Setting the root-file-system  is  made by  setting  the  device-
number at boot_parameters.bp_rootdev defined in /usr/include/minix/boot.h.
This is done in function setparam() in menu.c, which gets boot drive and
its partition number in BX-register from MXboot.  If it is the partition
of the hard-disk,  it reads the partition-table of the drive  from which
it was booted,  then  sorts the table.   This sort is necessary to match
with Minix's driver.   Then  it calculates device-number from the drive-
number and partition-number after sort, and set it to
boot_parameters.bp_rootdev.

    In case of minix-V,  further works such as reading font-files placed
in  /system directory  or  checks for OADG-keyboards....  are  necessary
besides setting root-file-system.  Routines for font-files are placed in
tools/option.c,  and it is almost same as MXboot's logic,  expressed  in
C-language.

            (to be continued.)
========================================================================
This is  originally  written in  Japanese  and  trially translated  into
(broken :-) English by nemossan@mix == [e-mail].

    Aug 19 '92 (Wed) 11:00 JST(+9:00)   [e-mail]