From owner-freebsd-hackers Tue May 21 15:42:21 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA06232 for hackers-outgoing; Tue, 21 May 1996 15:42:21 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA06227 for ; Tue, 21 May 1996 15:42:19 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA02321; Tue, 21 May 1996 15:37:06 -0700 From: Terry Lambert Message-Id: <199605212237.PAA02321@phaeton.artisoft.com> Subject: Re: Glitch in install procedure. To: erich@uruk.org Date: Tue, 21 May 1996 15:37:06 -0700 (MST) Cc: terry@lambert.org, dutchman@spase.nl, freebsd-hackers@freebsd.org In-Reply-To: <199605212211.PAA14120@uruk.org> from "erich@uruk.org" at May 21, 96 03:11:22 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > 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. > 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. 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). If you could address this one (say by doing a VM86() call), then we can probably take up a collection and buy you lunch for some time to come. 8-). > BTW: I'm looking for ways to safely add LBA (much greater than 8GB > limit) support to my bootloader. It currently is not dependent > on particular BIOS geometries, just the limit of the maximum > addressable area. 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. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.