From owner-freebsd-hackers Tue May 21 16:04:42 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA08289 for hackers-outgoing; Tue, 21 May 1996 16:04:42 -0700 (PDT) Received: from uruk.org (uruk.org [198.145.95.253]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id QAA08283 for ; Tue, 21 May 1996 16:04:38 -0700 (PDT) From: erich@uruk.org Received: from loopback (loopback [127.0.0.1]) by uruk.org (8.7.4/8.7.3) with SMTP id QAA14261; Tue, 21 May 1996 16:04:48 -0700 (PDT) Message-Id: <199605212304.QAA14261@uruk.org> X-Authentication-Warning: uruk.org: Host loopback [127.0.0.1] didn't use HELO protocol To: Terry Lambert cc: dutchman@spase.nl, freebsd-hackers@freebsd.org Subject: Re: Glitch in install procedure. In-reply-to: Your message of "Tue, 21 May 1996 15:37:06 PDT." <199605212237.PAA02321@phaeton.artisoft.com> Date: Tue, 21 May 1996 16:04:47 -0700 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Terry Lambert writes: > > Maybe I'm missing something, but: > > > > 1) FreeBSD already gets the BIOS geometry of hard disks from it's > > normal bootloader. > > You are missing the ability to map BIOS drive ID's to BSD physical > devices. > > BSD controllers are found in probe order. > > DOS INT 13 BIOS drive ID's are found in POST initialization order. Whoops! You're right. I keep forgetting that I'm dealing with BIOS device ID's (at least, it's easy to forget... :-/. > > 2) Can't you just make a "BIOS query" hunk of patch code, copy it > > down into the first 1MB of RAM, and run it to produce your > > BIOS geometry ? > > You would also have to run BIOS INT 13 base reads to run MD5 checksums > on blocks of the device, in order, until you uniquely identified the > device (or if you don't pre-run them, then you could compare a sector > read from the protected mode driver wit one read using INT 13. > > This will let you map the 0x8x ID's to BSD devices, and therefore > map the geometries, known by ID's, to the BSD devices. > > This solves all the problems. INT 13 reads might not work, since even the probe might ruin the BIOS setup with the controller. > Unfortunately, there is no '"BIOS query" hunk of patch code', since > it is effectively, exactly what would be necessary for VM86() > support (desirable, but not implemented). You don't need "VM86" code, really. It just depend on when you run your probe in the boot sequence. Well, we do know: 1) The order of IDE controller initialization. 2) Each SCSI adapter driver knows it's BIOS translation, right? (or what it's capable of... the newer BusLogic controllers, for example, adapt to the BIOS translation it finds in the MBR of each hard drive if you have it set up right) > Have you looked at the VFAT32 code? They change both the partition > table data and the msdos.dos/io.dos (the replacements for io.sys and > msdos.sys for DOS 7.x). The add additional INT 13 entry points for > doing all this, and they make the system recognize them. Well, the "standard" BIOS LBA calls might just work if I use them, though there are still a few issues to resolve. -- Erich Stefan Boleyn \_ E-mail (preferred): Mad Genius wanna-be, CyberMuffin \__ (finger me for other stats) Web: http://www.uruk.org/~erich/ Motto: "I'll live forever or die trying" This is my home system, so I'm speaking only for myself, not for Intel.