summaryrefslogtreecommitdiff
path: root/sys/arch/i386/stand/README
blob: 170ef1fb3545b4561f460fd9a870a2a62802fcd7 (plain)
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
$OpenBSD: README,v 1.12 1998/02/24 22:06:37 weingart Exp $

# hmm, no copyright

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 checksummed 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 without -DSAVE_MEMORY, and don't with it defined.


Mon Apr 21 15:25:42 EDT 1997
----------------------------

Now memory limits are not a concern. No more restrictions on placement
and size of code/data. It would be an idea to move PMMM code from kernel
into /boot to use low memory somehow.  Also remember that the upper 64k is
used by apm, so do not grow heap too much... Low 64k is used for real mode
IDT, BIOS data, stack for /boot, so stack is big enough (about 60k).
All the magic w/ prot-real mode interface now in one place <libsa/gidt.S>.
BIOS (and DOS soon) interrupt entry points are now just as simple as
they are in real mode (just use a macro BIOSINT, which shifts int number
by 0x20, that all! ;).


Sat May 31 12:06:37 EDT 1997
----------------------------

usleep(int15,f86) BIOS call is not supported well in all the BIOSes,
especially some laptop BIOSes and Compaq machines. Everybody is encouraged
to use sleep instead, it's known to work.


Thu Jul 17 21:24:42 EDT 1997
----------------------------

Return to the way when code has to be less then 64k, or better say that
whole gidt.S code must be in the 1st 64k of /boot .text section.
This saves about 2k of code (idt initialization).
APM information is now gathered and passed to the locore.s upon kernel
startup as a pointer to the struct apm_connect_info.


Wed Aug 27 16:30:51 EDT 1997
----------------------------

BIOS boot device number is passed to the kernel along with BIOS geometry
for that drive and other info. APM connect info is passed as well not in
that apm0 structure, so apm0 will become a slave on bios0 soon.
To get your /boot installed properly on a hardrive you have to load /bsd
from that hd/partition (since only boot drive geometry is passed).


Mon Oct 13 16:41:18 CDT 1997
----------------------------

Clean up memprobe some, adding support for querying the BIOS for the
memory map.  Resort to the old invasive probe if all else fails.  Add
preliminary support for passing a memory map to the kernel, instead of
cnvmem/extmem.  This should make weird boards easier to support in the
future.


Tue Jan  6 19:51:43 CST 1998
----------------------------

Query and pass PCI BIOS information to the kernel.  This should help in
determening the correct configuration mode to use.  Pass in cnvmem/extmem
as the user sets the amount of memory with the 'set memory' command, or
the amount calculated by the memory find/probe routines.