mirror of
https://git.FreeBSD.org/src.git
synced 2024-12-22 11:17:19 +00:00
dd05fde699
minor cleanup. Added $Id$ to files that did not have any version info, etc
152 lines
6.7 KiB
Plaintext
152 lines
6.7 KiB
Plaintext
This Boot code is different from the original boot code that came with
|
|
386BSD in that it uses the BIOS to load the kernel and to provide all i/o
|
|
services. The advantage ofthis is that the same boot code exactly, can run
|
|
on any device that is supported by the BIOS. (That's most of them)
|
|
This is important for the 'generic scsi' project because it means we can
|
|
write drivers for new scsi adapters without having to develop an new
|
|
set of boot blocks for each.
|
|
|
|
At this point you should read the first part of README.MACH... come back here
|
|
when you have done that:
|
|
|
|
In normal operation, when co-existing with other operating systems, the
|
|
following operations occur:
|
|
|
|
1/ the BIOS loads the first block of the disk (called the Master Boot Record
|
|
or MBR) and if it has the correct magic numbers, jumps into it:
|
|
|
|
2/ The MBR code, looks at the Partition table that is embedded within it,
|
|
to detirmine which is the partition to boot from. If you are using the os-bs
|
|
bootblocks (highly recommended) then it will give you a menu to choose from.
|
|
|
|
3/ The MBR will load the first record of the selected partition and
|
|
if it has (the same) magic numbers, jumps into it. In 386bsd this is the
|
|
first stage boot, (or boot1) it is represented in /usr/mdec by
|
|
wdboot, asboot and sdboot. If the disk has been set up without DOS partitioning
|
|
then this block will be at block zero, and will have been loaded directly by
|
|
the BIOS.
|
|
|
|
4/ Boot1 will look at block0 (which might be itself if there are no DOS
|
|
partitions) and will find the 386bsd partition, and using the information
|
|
regarding the start position of that partition, will load the next 13 sectors
|
|
or so, to around 90000 (640k - 64k). and will jump into it at the appropriate
|
|
entry point. Since boot1 and boot2 were compiled together as one file
|
|
and then split later, boot1 knows the exact position within boot2 of the
|
|
entry point.
|
|
|
|
Boot 1 also contains a compiled in DOS partition table
|
|
(in case it is at block 0), which contains a 386bsd partition starting
|
|
at 0. This ensures that the same code can work whether or not
|
|
boot1 is at block 0.
|
|
|
|
5/ Boot2 asks the user for a boot device, partition and filename, and then
|
|
loads the MBR of the selected device. This may or may not be the device
|
|
which was originally used to boot the first MBR. The partition table
|
|
of the new MBR is searched for a 386bsd partition, and if one is found,
|
|
that is then in turn searched for the disklabel. This could all be on the
|
|
second disk at this point, if the user selected it.
|
|
|
|
6/On finding the disklabel, boot2 can find the correct unix partition
|
|
within the 386bsd partition, and using cutdown filesystem code,
|
|
look for the file to boot (e.g. 386bsd).
|
|
|
|
7/ Boot2 loads this file starting at the location specified by the a.out header,
|
|
(see later) and leaps into it at the location specified in he header.
|
|
|
|
if the file does not exist or cannot be loaded, boot2 goes back to step 5.
|
|
|
|
386bsd is now running and will hopefully start vm etc. and get to multi-user
|
|
mode.
|
|
|
|
##########################################################################
|
|
During all these steps, all i/o is performed using the BIOS. This has a number
|
|
of side effects:
|
|
|
|
1/ Since BIOS disk calls are specified in terms of cylinder,head and sector,
|
|
and the BIOS read the disk information from either the CMOS or from some other
|
|
location which is un-available to us, we must use the cyl,head,sec information
|
|
that is given in the MBR, rather than the start address in the MBR, because
|
|
we cannot guarentee that we can corectly calculate C,H,S from the start address.
|
|
|
|
Therefore, the C,H,S information in the MBR must be as correct for this boot
|
|
to work as it would be for DOS to boot. For example, adaptec BIOS routines
|
|
assume a layout of 64 heads and 32 sectors giving 1MB per ficticious cylinder.
|
|
You must use these figures to calculate the correct values. Luckily, the DOS
|
|
fdisk program will do all this for you if you tell it to give you a DOS
|
|
partition, and you can change it to a 386BSD partition later. If you use
|
|
no DOS partitioning, then the compiled in table in Boot1 will do just fine.
|
|
|
|
If you want to do it by hand remember that BIOS counts sectors starting at 1.
|
|
(cylinders and heads start at 0 (??))
|
|
|
|
2/ you cannot overwrite the bottom 4k of ram until you have finished ALL
|
|
bios calls, as BIOS uses this area as scratch memory.
|
|
|
|
3/ Since BIOS runs in REAL mode, and Boot2 runs in protected mode,
|
|
Boot 2 switches back to real mode just before each BIOS call and then
|
|
back to protected mode on each return. Touch this at your peril.!
|
|
|
|
#########################################################################
|
|
In answering the prompt from Boot2:
|
|
you can,
|
|
1/ leave it alone.. it will boot the indicated file from the first
|
|
partition of the first drive seen by the BIOS (C:)
|
|
|
|
2/ enter only "-s" to boot the default to single user mode
|
|
|
|
3/ enter only a filename (optionally with -s) to boot that kernel,
|
|
|
|
4/ enter a whole line of the form shown in the prompt. This allows you to
|
|
boot some other partition, possibly on the second drive, as root.
|
|
|
|
|
|
##########################################################################
|
|
In the case you have two drives the same type (both scsi or bith IDE/ESDI),
|
|
wd(0,a)xxx
|
|
will boot xxx from drive 0, a partition.
|
|
wd(1,a)xxx
|
|
will boot xxx from drive 1, a partition.
|
|
|
|
similarly for sd.
|
|
|
|
if you have one wd drive and one scsi drive, then you MUST
|
|
use device 'hd'
|
|
|
|
otherwise the following will happen:
|
|
|
|
with wd0 and sd0, you specify sd1 or wd1 to indicate the 2nd drive.
|
|
it boots the kernel correctly, then tells the kernel to use sd1 as root.
|
|
you however may not have an sd1, and problems arise.
|
|
|
|
hd is special in that the kernel is always told to use unit 0,
|
|
The correct TYPE of device will be specified too, so the kernel
|
|
will be told either sd0 or wd0.
|
|
|
|
Whether sd or wd is specified to the kernel is read from the disklabel,
|
|
so ensure that all SCSI disks have type SCSI in their disklabel or the
|
|
boot code will assume they are ESDI or IDE. (Remember, because it is
|
|
working through the BIOS it has ho idea what kind of disk it is.
|
|
|
|
##########################################################################
|
|
Installing:
|
|
The makefile supplied has a target install which will create the
|
|
files wdboot,bootwd ,sdboot and bootsd in /usr/mdec.
|
|
BEWARE these will overwrite the existing wdboot and bootwd. (so back
|
|
them up)
|
|
|
|
there are also targets wd and sd which wil only do one of them
|
|
|
|
The commented out targets wd0 and sd0 are examples of how to
|
|
load the new bootblocks, however,make sure you change the
|
|
device type and label to suit your drive if you uncomment them.
|
|
(see 'man disklabel')
|
|
|
|
If you already have made partitions using the old bootblocks
|
|
these should install painlessly.
|
|
|
|
Before you do this ensure you have a booting floppy with correct
|
|
disktab and bootblock files on it so that if it doesn't work, you can
|
|
re-disklabel from the floppy.
|
|
|
|
$Id$
|