Remove... almost 10 years, and things have changed enough that this

is more historic than anything else.  If ya want it, find it in the
Attic.

ok tom@

1 files changed, 0 insertions, 151 deletions

diff --git a/sys/arch/i386/stand/README b/sys/arch/i386/stand/README
deleted file mode 100644
index 9803dbc1030..00000000000
--- a/sys/arch/i386/stand/README
+++ /dev/null
@@ -1,151 +0,0 @@
-$OpenBSD: README,v 1.13 2003/11/08 19:17:28 jmc 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 than 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.
-