1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
|
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$
|
