$OpenBSD: README,v 1.10 1997/09/02 21:41:29 kstailey 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 in concern. No any restrictions on placement and sizes of code/data. It would be an idea to move PMMM code from kernel into /boot to use low memory somehow, then remember that upper 64k are used by apm, so do not grow too much... Low 64k are 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 . 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# 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 have 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 pointer to the struct apm_connect_info. Wed Aug 27 16:30:51 EDT 1997 ---------------------------- BIOS boot device number is passed to 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). The passed geometry will be used for all the drives, if you will try to installboot on other disks (floppies and pseudo-disks will honor the disklabel), that might be useful on some bioses, esp. SCSI HAs which use fixed translated geometry for all the drives.