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
|
$OpenBSD: README,v 1.4 1997/04/11 19:21:50 weingart Exp $
Ok, just a couple quick pointers to people hacking on this stuff. These
are things that I have found out, and hopefully will make things easier
for the next dude.
First of all, don't trust gas to get the opcodes right. Look at the
listing (-Wa,a), and check them. In particular, check for EIP relative
and absolute addressing. Some of this stuff is pretty hairy in that way.
Debugging this stuff is hell. Remember that stores directly to video
memory will go a long way towards tracking how far things are getting,
especially when you don't have the BIOS handy. (movl %0x07410741, 0xb8000)
The basics of the /boot system is the following:
biosboot: 512 bytes of the first sector on the disk/partition. This loads
/boot (or whatever you did with installboot) into ram.
boot: starts protected mode, and process simple command line.
There is some magic here in terms of the placement and size of the various
segments, as this piece of code has to switch between real and protected
mode many times to load the next piece of the puzzle, /bsd.gz.
bsd: The kernel itself, can be gzipped if ya want.
The basic steps at creating a boot floppy for yourself, and checking things
out are the following:
1.) Compile a kernel you wish to use.
2.) Compile the new stand stuff.
3.) Mount floppy.
4.) Copy boot and kernel to floppy. (Kernel could be gzipped if needed)
5.) Run installboot on floppy.
6.) Unmount floppy.
7.) Test...
A quick pasto for ya:
> natasha# mount /dev/fd0a /mnt
> natasha# cp boot/obj/boot /mnt
> natasha# gzip -9c bsd > /mnt/bsd.gz
> natasha# installboot -v /mnt/boot biosboot /dev/rfd0a
> boot: /mnt/boot
> proto: biosboot/obj/biosboot
> device: /dev/rfd0a
>
> biosboot/obj/biosboot: entry point 0
> proto bootblock size 512
> room for 32 filesystem blocks at 0x138
> Will load 9 blocks of size 4096 each.
> 0: 4 @(2 1 15) (104-107)
> 1: 18 @(3 0 1) (108-125)
> 2: 18 @(3 1 1) (126-143)
> 3: 18 @(4 0 1) (144-161)
> 4: 14 @(4 1 1) (162-175)
> /mnt/boot: 5 entries total
> natasha# umount /mnt
> natasha#
Sun Apr 6 20:16:55 CDT 1997
----------------------------
Ok, from general comments on icb leads me to believe this stuff has a ways
to go. First of all, there are a lot of debug frobs to video memory at
0xb8000 when DEBUG* is defined. Also, if you boot a kernel, and find that
you get a scrolling screen, press pause to get it to stop. You should then
be able to read the register dump.
Note, currently gzipped kernel do not work. Do not know the reason, we are
working on resolving that.
Fri Apr 11 14:18:41 CDT 1997
----------------------------
Ok, yeah, the .gz kernel gets to the probe (and then cacks later due to
no swap). Things should start working nicer from now on. The problem
was with -DSAVE_MEMORY, I believe that the stuff in libsa/cread.c was
not (and still is not with the define) being done right. I suspect
the inflateInit2(), which had a parameter changed from -15 to -11.
The problem manifested itself by loading a corrupted kernel. On the
other hand, it checksumed ok though, so there might be a small bug in
the libz stuff. Also, I don't understand libz, but I do know that
things work withouth -DSAVE_MEMORY, and don't with it defined.
|
