TEMARI%ECAMV1.dnet.ge.com@vm1.nodak.edu (10/23/90)
Hello Net: I was installing shoelace and everything worked fine when I booted my Minix partition, but when I tried to boot my DOS partition I got the message: Unformatted partition. So I disassembled the DOS boot sector to find out what would cause the Unformatted partition message. It would do this if when comparing the starting sector and total sectors from the partition table entry with the data in the start of the DOS boot sector. If the numbers didn't match you get the Unformatted partition message. So I figured that winiboot wasn't passing the partition entry correctly, but I though I would have seen some bug fixes from the Net. To make a long story short :-) according to bootlace what is passed to a boot sector is the drive in register dl and a pointer to the partition table entry in ES:SI. Here is the first few instructions from my Zenith DOS 3.3+ boot sector: mov bx,0x07c0 cli mov ss,bx mov sp,0x0263 sti push ds pop es <-------- the kicker mov ds,bx it then went on to do the comparison with the partition entry with ES:SI. According to this code it expects that the partition entry be passed to it in DS:SI not ES:SI. What is actually correct??? My own homebrew version of the partition selection at boot up time has ES and DS the same when the boot sector is loaded and run. What is the official parameters passed to the boot sector?????? Michael Temari temari@ecamv1.dnet.ge.com
cechew@bruce.cs.monash.OZ.AU (Earl Chew) (10/25/90)
In <34243@nigel.ee.udel.edu> TEMARI%ECAMV1.dnet.ge.com@vm1.nodak.edu writes: >According to this code it expects that the partition entry be passed to it >in DS:SI not ES:SI. What is actually correct??? My own homebrew version >of the partition selection at boot up time has ES and DS the same when the >boot sector is loaded and run. >What is the official parameters passed to the boot sector?????? When I wrote the code, I got the information for this part by disassembling the partition table code from a TI machine running Dos < 3.3. Does anyone know if the parameter passing protocol for the partition boot is written down somewhere? Earl -- Earl Chew, Dept of Computer Science, Monash University, Australia 3168 EMAIL: cechew@bruce.cs.monash.edu.au PHONE: 03 5655447 FAX: 03 5655146 ----------------------------------------------------------------------
gwr@linus.mitre.org (Gordon W. Ross) (10/26/90)
In article <3275@bruce.cs.monash.OZ.AU> of comp.os.minix, cechew@bruce.cs.monash.OZ.AU (Earl Chew) writes: > When I wrote the code, I got the information for this part by > disassembling the partition table code from a TI machine running > Dos < 3.3. Does anyone know if the parameter passing protocol for > the partition boot is written down somewhere? Yes. See the "IBM DOS 3.3 Technical Reference" manual, page 9-9. Among other details, it specifies: "When a partition's boot record is given control, it is passed its partition table entry address in the DS:SI registers." There is no mention of any other registers being initialized by the primary boot program. (In article <34243@nigel.ee.udel.edu>, Michael Temari <TEMARI%ECAMV1.dnet.ge.com@vm1.nodak.edu> mentioned that bootlace expected "the drive in register dl" to be passed too.) The partition table is laid out to make it easy to load the cx and dx registers for the BIOS call to read the secondary boot sector. Presumably the Minix assembler code should look like this: mov ax,#0x0201 | BIOS read 1 sector mov bx,#0x7c00 | transfer address mov cx,2(si) | cylinder/sector mov dx,(si) | drive/head int 0x13 By the way, neither MS-DOS nor UNIX (Sys.V/386) make any use of the address passed in DS:SI but use alternative, less friendly methods to find the active partition. For UNIX, this also means it will refuse to boot unless its partition is marked as active. Probably the author of that boot program couldn't find the above information either! -- Gordon W. Ross (M/S E095) internet: gwr@linus.mitre.org The MITRE Corporation uucp: {decvax|philabs}!linus!gwr Burlington Road office phone: 617-271-3205 Bedford, MA 01730 (U.S.A.)
cechew@bruce.cs.monash.OZ.AU (Earl Chew) (10/29/90)
In <124439@linus.mitre.org> gwr@linus.mitre.org (Gordon W. Ross) writes: >There is no mention of any other registers being initialized by >the primary boot program. (In article <34243@nigel.ee.udel.edu>, >Michael Temari <TEMARI%ECAMV1.dnet.ge.com@vm1.nodak.edu> mentioned >that bootlace expected "the drive in register dl" to be passed too.) Assuming that only DS:SI are passed, how does the boot code work out which drive is being bootstrapped? (This is why I passed the drive number in dl.) Earl -- Earl Chew, Dept of Computer Science, Monash University, Australia 3168 EMAIL: cechew@bruce.cs.monash.edu.au PHONE: 03 5655447 FAX: 03 5655146 ----------------------------------------------------------------------
L.Parkes@comp.vuw.ac.nz (Lloyd Parkes) (10/30/90)
In article <3284@bruce.cs.monash.OZ.AU> cechew@bruce.cs.monash.OZ.AU (Earl Chew) writes:
Assuming that only DS:SI are passed, how does the boot code work out which
drive is being bootstrapped? (This is why I passed the drive number in dl.)
The partition being booted from is the active partition. Quite some
time ago a program appeared on the net called MultiBoot. This program
allows you to choose your boot partition at boot time. (There was a
similar program posted a few months ago, but I haven't read its
source.) MultiBoot adjusted the partition table in RAM, so that the
only active partition was the one that was actually being booted.
Lloyd
--
------------------------------------------------------------------------
Lloyd Parkes | The stereotypical young adult male in New
lloyd@comp.vuw.ac.nz | Zealand is a good reason for being lesbian.
------------------------------------------------------------------------cechew@bruce.cs.monash.OZ.AU (Earl Chew) (10/30/90)
In <LLOYD.90Oct30092318@circa.comp.vuw.ac.nz> L.Parkes@comp.vuw.ac.nz (Lloyd Parkes) writes: >In article <3284@bruce.cs.monash.OZ.AU> cechew@bruce.cs.monash.OZ.AU (Earl Chew) writes: > Assuming that only DS:SI are passed, how does the boot code work out which > drive is being bootstrapped? (This is why I passed the drive number in dl.) >The partition being booted from is the active partition. Quite some Yes, what you say is true -- but you haven't answered the question. My question refers to the *drive* not the *partition*. How does the bootstrap determine that drive N is being bootstrapped? Or, put another way, how does a boot menu program indicate to the boot sector code which drive is being bootstrapped? One could always write a drive number specific bootstrap, but this is ugly since it requires N versions of the bootstrap for N drives. A generic bootstrap is preferred. In this case, the bootstrap must determine at run time which drive is being started. Earl -- Earl Chew, Dept of Computer Science, Monash University, Australia 3168 EMAIL: cechew@bruce.cs.monash.edu.au PHONE: 03 5655447 FAX: 03 5655146 ----------------------------------------------------------------------
TEMARI%ECAMV1.dnet.ge.com@vm1.nodak.edu (10/30/90)
The first byte of each partition entry contains the so called flag for active partition, which happens to be 80h (i.e. hard disk 0). According to Gordon W. Ross (gwr@linus.mitre.org) the code he gave loads dl (i.e. the drive to read the boot sector from) from the first byte of the partition table entry. The actual code was: mov dx,(si) where si points to the partition table entry to boot. So what you would do to boot a different drive instead of passing it in dl is to put it in the first byte of the partition table entry to boot. Although I have not look at any disassembled boot sectors to confirm this. Michael Temari temari@ecamv1.dnet.ge.com
cgs@umd5.umd.edu (Chris G. Sylvain) (11/01/90)
In article <34964@nigel.ee.udel.edu> TEMARI%ECAMV1.dnet.ge.com@vm1.nodak.edu writes: >The first byte of each partition entry contains the so called flag for active >partition, which happens to be 80h (i.e. hard disk 0). According to Gordon W. >Ross (gwr@linus.mitre.org) the code he gave loads dl (i.e. the drive to read >the boot sector from) from the first byte of the partition table entry. The partition status byte is the first byte in the partition table. A value of 0x80 indicates the referenced partition described in the following 15 bytes is an active and bootable partition. That is all the 0x80 value signifies. It has nothing to do with the drive number other than the coincidence that when the first fixed disk drive is referenced by number, the value 0x80 is used. Parition tables are used within the context of the currently accessed fixed disk drive. There is no value in the partition table indicating for which disk the table is valid. Since one disk must be selected to be able to read the partition tables, then the disk for which the table is valid is already known. Therefore, if the Gordon Ross' code does what is described above, then DL will always have the value 0x80 or 0x00, and never 0x81 nor 0x01. -- --==---==---==-- Mimsy: Flimsy and miserable; another portmanteau word -- ARPA: cgs@umd5.UMD.EDU BITNET: cgs%umd5@umd2 -- -- UUCP: ..!uunet!umd5.umd.edu!cgs --
TEMARI%ECAMV1.dnet.ge.com@vm1.nodak.edu (11/01/90)
Well I checked out my disassembled Zenith dos 3.3+ boot sector and it
used what every was passed in DL as the drive. So the documentation
that Gordon W. Ross (gwr@linus.mitre.org) must be incorrect. So I would
then think that the partition boot sector passes:
DL = drive to read boot sector from
DS:SI = pointer to partition table entry to boot
(I never believe documentation, the only true documentation is
the program itself.)
Michael Temari temari@ecamv1.dnet.ge.comcechew@bruce.cs.monash.OZ.AU (Earl Chew) (11/02/90)
In <35159@nigel.ee.udel.edu> TEMARI%ECAMV1.dnet.ge.com@vm1.nodak.edu writes: >that Gordon W. Ross (gwr@linus.mitre.org) must be incorrect. So I would >then think that the partition boot sector passes: > DL = drive to read boot sector from > DS:SI = pointer to partition table entry to boot >(I never believe documentation, the only true documentation is > the program itself.) This is getting confusing. 1. Currently winiboot passes: DL = drive to read boot sector from ES:SI = pointer to partition table entry to boot 2. Gordon W. Ross says that the Microsoft documentation says: DS:SI = pointer to partition table entry to boot 3. Michael Temari says that the Zenith 3.3+ systems uses: DL = drive to read boot sector from DS:SI = pointer to partition table entry to boot (1) is known to boot at least two versions of MSDOS (my old machine and my current machine). (3) boots Michael Temari's Zenith 3.3+ system. Michael, when you disassembled the bootstrap did you see whether DS:SI or ES:SI is used? Your posting didn't make it at all clear. I don't know if (2) will boot anything. I think that to remain compatible with the world, the following will be required: 1. DL contains the drive code 2. DS:SI pointer to partition table entry to boot 3. ES:SI pointer to partition table entry to boot 4. Partition table entry to boot has the drive code entered into its active field Earl -- Earl Chew, Dept of Computer Science, Monash University, Australia 3168 EMAIL: cechew@bruce.cs.monash.edu.au PHONE: 03 5655447 FAX: 03 5655146 ----------------------------------------------------------------------
TEMARI%ECAMV1.dnet.ge.com@vm1.nodak.edu (11/02/90)
Earl the boot sector for my Zenith DOS 3.3+ systems use DS:SI. I would also have to agree with your four requirements if everything that has gone by under this topic is true. Michael Temari temari@ecamv1.dnet.ge.com
al@escom.com (Al Donaldson) (11/03/90)
In article <3301@bruce.cs.monash.OZ.AU>, cechew@bruce.cs.monash.OZ.AU (Earl Chew) writes: > This is getting confusing. > 1. Currently winiboot passes: > DL = drive to read boot sector from > ES:SI = pointer to partition table entry to boot > 2. Gordon W. Ross says that the Microsoft documentation says: > DS:SI = pointer to partition table entry to boot > 3. Michael Temari says that the Zenith 3.3+ systems uses: > DL = drive to read boot sector from > DS:SI = pointer to partition table entry to boot Earl, excellent analysis. I've got one other data point but I'm not sure how useful it is. A while back I converted Dan Thureen and Glen Overby's loader program to asld and wrote a first stage boot sector for it, all in asld. I turned it over to Glen a couple weeks ago for his review and posting. These two items, bootsec.s (goes in sector 0 of first drive) and loader.x (goes in the boot block of the MINIX hard disk root), use a different convention than listed above. I've had it working for a month now, albeit in a limited configuration (DOS on partition 1 and MINIX root on partition 3), and it works fine. Anyway, the convention used by bootsec.s and loader.x is: | Before booting the 2nd stage loader: | --> set BX = starting cylinder number of partition | --> set SI = partition table entry (relative to 0) | --> directly set segment registers (DS, ES, SS) to zero | --> set up return so 2nd stage starts at CS:AX = 0:7C00 The reason I say I'm not sure of its usefulness is that all I did was to write a boot sector that worked with the original loader program and gave it the registers it needed. Whether these are "standard" or not is debatable, but it works with DOS and MINIX and I can "cd /usr/src/tools; make hdboot" and it goes. Al
cechew@bruce.cs.monash.OZ.AU (Earl Chew) (11/05/90)
In <609@escom.com> al@escom.com (Al Donaldson) writes: >Anyway, the convention used by bootsec.s and loader.x is: >| Before booting the 2nd stage loader: >| --> set BX = starting cylinder number of partition >| --> set SI = partition table entry (relative to 0) >| --> directly set segment registers (DS, ES, SS) to zero >| --> set up return so 2nd stage starts at CS:AX = 0:7C00 Setting DS=ES=SS:SI to point at the partition table seems like a good idea just to be on the safe side. CS:AX = 0:0x7c00 seems unnecessary to me. The code in the boot sector shouldn't be relying on how it got invoked (except for the parameter passing). Relying on BX = cylinder number seems strange. Besides, you don't gain much if the partition starts in the middle of a cylinder. Passing the parameter table pointer (and drive number) is sufficient. Earl -- Earl Chew, Dept of Computer Science, Monash University, Australia 3168 EMAIL: cechew@bruce.cs.monash.edu.au PHONE: 03 5655447 FAX: 03 5655146 ----------------------------------------------------------------------