Return to BSD News archive
Newsgroups: comp.unix.bsd Path: sserve!manuel.anu.edu.au!munnari.oz.au!spool.mu.edu!snorkelwacker.mit.edu!ira.uka.de!gmd.de!jvnc.net!nuscc!ntuix!eoahmad From: eoahmad@ntuix.ntu.ac.sg (Othman Ahmad) Subject: Re: DOS and 386BSD (and NT and OS2) Message-ID: <1992Oct17.060946.25764@ntuix.ntu.ac.sg> Organization: Nanyang Technological University - Singapore X-Newsreader: TIN [version 1.1 PL6] References: <1992Oct15.171833.25427@fcom.cc.utah.edu> Date: Sat, 17 Oct 1992 06:09:46 GMT Lines: 196 A Wizard of Earth C (terry@cs.weber.edu) wrote: : : The translation is done by the disk BIOS *on* the controller, or it may be : done by the drive itself. You don't use the BIOS for access, you don't : get translation. I believe this is the crux of the problem. The question is: where is the translation done? Options are: i) controller; ii)bios on controller; 386BSD does not use bios interrupts except during boot-time. 386BSD cannot handle variable no of sector. Therefor option ii) does not make sense, if the harddisk can work at all. Most of the problems are not due to inability of 386BSD to work, rather, its problem when co-existing with DOS. Putting the translation inside the controller is not at all difficult. The manufacturer of the IDE controller may be very stupid indeed if he uses bios to do the translation. The main processing power will be disturbed. Since my 386BSD works with Maxtor, Conner and Western Digital, these manufacturers most probably uses IDE controllers that can do translation them selves without resorting to BIOS ROM inside it. : : There is a probe request (which not all controllers support!) that is done : to ask the controller the disk's geometry. This is because the raw driver There is a control register that can give the default translation for that IDE controller. There is no reason to doubt that that figure can be changed. Maybe most BIOS should do that. Read the article in Byte March 1991, page 321: There the tables on register definitions, and commands. It is not complete though. : used in 386BSD doesn't use the BIOS (for reasons which should be obvious) : and talks to the controller directly -- thus there is no such thing as a : translated geometry as far as 386BSD (or any other non-BIOS OS) is : concerned. Without this, instructions to the controller for "translated" : addresses not going through the "lookup" code (the BIOS) would fail. : : : >Theoretically, we can just choose any geometry on the bios, and it will work. : >Provided your bios/software know the geometry that you store your data in. : >I did this on a Western Digital 40Mbyte hard disk. : : This is a good point: If you have translation enabled, and it isn't linear You are making the assumption that you can turn off the translation. Most probably you can't. : : >However the IDE controller may allow software to read a recommended geometry, : >which may be different from the BIOS setting(in CMOS RAM). DOS still works : >because of the above reason. : : It does. This is the 386BSD problem: the translation is "soft". The reason : DOS still works is it only uses the BIOS to access the disk. Maybe not, but I cannot verify because I did not install the 386BSD there. : : >The problems come because of the mismatch between BIOS and disklabel : >geometries. : : Exactly right. The "disklabel" program runs under 386BSD, which uses the : "real" (potentially hardware translated but *not* software translated) : geometry, since it accesses the disk through a 386BSD device (/dev/wd0d). : : >However DOS and 386bsd can still co-exist in this circumstances. Just instruct : >the OS boot manager to load the appropriate partitions calculated using the : >BIOS informations, converted from the disklabel info. : : Now *I'm* confused; are you saying this will allow the second stage boot to : know where the physical 386BSD partition starts from the translated data in The 2nd stage boot only loads the first sector in a partition to the standard address. OS-boot duplicates the first stage boot of floppy disks. In hard-disks, the boot block(first stage) must load another boot-block for the 2nd stage bootstrap. Therefor the 1st sector in a hard-disk is not the boot-block, rather a boot-manager. OS-BS uses DOS conventions, i.e. using BIOS for its operations, so must translate information from DOS partition table. : the partition table? I would still think the second stage of booting would : fail on a soft-translated drive, since the partition table is recorded in : the soft geometry. DOS 1st partition is not located at sector 1, rather offset to the next cylinder. 386BSD 1st partition is located at the first sector. If you say to boot-manager to load 1st 386BSD partition, it will load itself or some other offset. My experience is that it will go into an endless loop. Just replace the normal boot block(wdboot) given by DOS and 386BSD disklabel program with 0S-BS so that we have a menu. The new disklabel can disklabel to partitions other than a. Just do the disklabelling to the 2nd 386BSD partition to store the boot-block. I'm not sure how 386BSD boot-block works. I presume it will load the next secto of the active partition, for a total of 6K. It has to skip the boot-block, which is located at the 1st sector of the boot-able(active) partition. This second stage boot program(wdboot) is copied by disklabel(?) to any partition which we do disklabel, not like previous version. You can do disklabel -w wd0h .... without the partition name, i.e. just wd0, it will use wd0d as default. I believe I have verified this. I recall vaguely error messages of "device busy", but it could be due to a mounted drive. So do the disklabel before mounting it. I've not tried this procedure. My main worry is that the 386bsd boot-block does not load from the next sector, and disklabel does not copy the boot-block to the other partitions, apart from wd0d. Anyone with empty disk to try this new procedure? Mine is full with source codes so dare not take risk. : : >I have worked with 200Mbyte Conner, 200Mbyte Maxtor, 120 Mbyte Maxtor. : > : >I have another 240mbyte quantum pro IDE, but I believe I can install the DOS : >as well, but I must have the OS-BS software. Otherwise, it will surely fail. : : I *really* question the assumption that loading the first half of the boot : code is sufficient here. You should actually be able to do this same thing : with the Julian's code, which reads the kernel in using BIOS routines; I : *still* think there would be a problem reconciling the physical location of : the 386BSD partition for the 386BSD kernel; so even with Julian's code, a : hard-coded location would be required for 386bsd to find and mount /. : : Once we get this hammered out, we should have a "the way things work" : document that will be useful to everyone. What I need is a 386bsd BOOT MANAGER, instead of DOS-based. 386BSD can read partition and geometry information from disk in the disklabel. DOS need to read it from CMOS ram so that I've to reprogram the CMOS ram EVERYTIME i change disks. If 512 byte is too small for the menu program, the bigger bootwd, can be used. What is the data-structure of the disklabel, and where it is? I have more knowledge of the DOS partition table. How do they co-exist? Does julain use bios for asboot only, not bootas? It is not a good idea to use bios but may be important if we want to conserve program size, but it should be restricted to wdboot only. Anyone want to write a DOS and disklabel editor acting on the wdboot, instead of on the disk itself. If will be easier to do. Failing that, what is a good binary editor for 386bsd. We may patch wdboot manually, before using dd to copy it to the disk. This technique is easier and safer than using program directly manipulating the disk sectors. At least harder to understand. I've not extracted the wdboot source code yet. Maybe someone can comment. : : : Terry Lambert : terry@icarus.weber.edu : terry_lambert@novell.com : --- : Any opinions in this posting are my own and not those of my present : or previous employers. : -- : ------------------------------------------------------------------------------- : "I have an 8 user poetic license" - me : Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial : ------------------------------------------------------------------------------- -- Othman bin Ahmad, School of EEE, Nanyang Technological University, Singapore 2263. Internet Email: eoahmad@ntuix.ntu.ac.sg Bitnet Email: eoahmad@ntuvax.bitnet