Page 1 of 1
INT 13 Drive Type
Posted: Tue Aug 31, 2010 6:25 am
by iocoder
Hello All!
I would like to know something about the usage of DL Register in INT 13. I know that when the computer boots, BIOS saves the boot Drive ID to DL, and the boot sector should read DL to know the boot Drive. but how to know the type of that drive?
I know well that if bit 7 is set, the drive is a hard-disk. if bit 7 is not set, the drive is a floppy disk, but when i boot from a CD, GRUB sets the ID of the boot drive as 0x9F [on VMWare], and as 0xE0 [on Bochs].
so is there a function in INT 13 that returns the drive type?? or any way else to know if the drive type is a floppy, fixed disk, ATAPI CD-ROM, ATAPI Zip Drive, ATAPI Tape Drive, USB Mass Storage Drive, or USB CD-ROM?
Regards,
Mostafa
Re: INT 13 Drive Type
Posted: Tue Aug 31, 2010 7:09 am
by bewing
Answer 1) BIOSes are buggy, and you can never really quite trust that they will tell you what the spec says they should tell you.
Answer 2) Even according to the specification, it is likely that it is not possible to always distinguish a booted CD from a USB stick.
Answer 3) Look at the INT0x13 BIOS Extension functions AH=0x4b and AH=0x48. You need to add a lot of logic -- it doesn't just tell you the answer.
Answer 4) If your bootsector ignores the boot device value in DL, and goes into Pmode, and uses Pmode drivers to detect all the boot devices without using any BIOS functions at all, and makes a list of the boot devices that are detected in a nice format, and boots from one of them, and tells your kernel which one it booted from -- then yes, you can tell exactly what was booted.
Re: INT 13 Drive Type
Posted: Wed Sep 01, 2010 7:05 am
by egos
0,1: floppy drives (if no emulation). 2-7Fh: unused (I think). 80h-0FFh: miscellaneous destination. EDD service v2(DPTE pointer)/v3(host bus type-path/device interface type-path) function 48h gives some info. If you could get device path (bus/controller/device) and interface type you could detect device type. But it's difficult problem.
Re: INT 13 Drive Type
Posted: Wed Sep 01, 2010 3:28 pm
by iocoder
Answer 4) If your bootsector ignores the boot device value in DL, and goes into Pmode, and uses Pmode drivers to detect all the boot devices without using any BIOS functions at all, and makes a list of the boot devices that are detected in a nice format, and boots from one of them, and tells your kernel which one it booted from -- then yes, you can tell exactly what was booted.
I cannot switch to PMode before loading some files from the boot device. My kernel needs to load device drivers and file-system drivers from the boot partition first, using INT 0x13. then goes into PMode and initialize these drivers in memmory.
after that, the kernel should determine the boot volume/partition using the kernel's Device Manager & the kernel's Volume Manager.
Here, do you mean that i should search for partitions and volumes which contains my OS, and display them in a list on screen allowing the user to choose between them?
Whould it be right if i read the serial ID of the boot partition using INT 0x13, and use that to determine the boot volume later?
Thanks both for your replies and best regards.
Re: INT 13 Drive Type
Posted: Thu Sep 02, 2010 12:12 am
by bewing
Not exactly. I meant that one way of booting is to completely forget about the BIOS and INT0x13, and not use any of that in your kernel to load anything. To use only pmode drivers, and have your kernel load more drivers with pmode drivers. It is a harder way to do it, but it works much better.
And there are many tricks that you can use to guess which drive is the boot drive, if you use the BIOS. They usually work, but some people would consider it very kludgy. It is a matter of taste.
Re: INT 13 Drive Type
Posted: Thu Sep 02, 2010 3:05 am
by egos
mostafazizo wrote:I cannot switch to PMode before loading some files from the boot device. My kernel needs to load device drivers and file-system drivers from the boot partition first, using INT 0x13. then goes into PMode and initialize these drivers in memmory.
after that, the kernel should determine the boot volume/partition using the kernel's Device Manager & the kernel's Volume Manager. Here, do you mean that i should search for partitions and volumes which contains my OS, and display them in a list on screen allowing the user to choose between them?
Whould it be right if i read the serial ID of the boot partition using INT 0x13, and use that to determine the boot volume later?
In this case you don't need device type. You need device path. I have a same situation. My kernel is loaded with boot device and file system driver in RM (both modules are loaded by boot loader). It creates the special structure to identify boot device from BIOS boot device number in RM. After PM driver will be started kernel will get the structure with same format from the driver for every storage virtual device and compare it with original structure of boot device created in RM to find boot virtual device. The structure has size 32 bytes and it is like fragment of DPT in many aspects as is host bus type and path, device interface type and path. Also it contains volume number of physical device for non-whole devices. This number is 8-bit and it identifies one of 255 volumes (in this structure 0 specifies on whole devices). Volume number (in this case 0 specifies on whole devices or devices with marked boot volume) is transferred to kernel (or stage 2 boot loader) from boot loader as high byte value of 16-bit boot device identifier (BDI); low byte value of BDI is a BIOS boot device number. It even can be transferred to stage 1 boot loader from mbr boot loader that supports our boot specification (now are available mbr boot loaders that support "Secondary Loader Boot Specification Rev.3"; Alter 2 is one of them). The last revision of this specification (3) describes following interface between mbr boot loader and "primary loader" (stage 1):
ds:si - boot partition descriptor pointer (if extended boot signature presents).
dl - low byte of BDI.
dh - high byte of BDI (if extended boot signature presents).
Extended boot signature is byte value 0x88 that replaces in memory high byte value of standard boot signature (0xAA) for "primary loader" after it has been loaded.