OSDev.org

Hi,

the Multiboot information provides the field "boot_device". The specification says:

multiboot wrote:The first byte contains the bios drive number as understood by the bios INT 0x13 low-level disk interface: e.g. 0x00 for the first floppy disk or 0x80 for the first hard disk.

After a short research I found that it's 0x00 for first floppy drive, 0x01 for second, 0x80 for first hard drive and 0x81 for the second one. But grub gives me other values, too. For example on my notebook I get 0x9F when booting from the DVD-drive. When doing that with VMware I get the same value. Bochs, qemu and VirtualBox give me 0xE0 in this case. It seems also that it doesn't play a role wether the disk is on the primary or secondary bus.
My question is: Does anybody know a source for the possible values? Does it even exist or is there no rule/standard?

Perhaps some background for the case that I'm going in the wrong direction
My filesystem needs of course to know on which device the root-fs should be. So that it uses the CD if booting from CD and so on. Currently I simply pass the name for the device (for example cda1 or hdb1) via multiboot-module-parameter. But thats of course not very good because for example the CD-drive may hang on different buses on different machines.
Therefore I'm searching for a way to automatically determine the drive from which my OS booted. I've already read that it should be possible by using BIOS interrupts. But my OS runs in protected mode only ATM and it would be nice to be able to keep that So, is there another way to figure that out?

Thanks!
hrniels

I think the numbers used by the BIOS INT 13 calls are BIOS-specific and not standardized (though if I am wrong here, I'd appreciate if someone pointed out which standard defines these numbers).

Forgive me if I'm a little naive about grub, I haven't really used it (at least not with OS development), but does it enter protected mode for your kernel?

If not, and supposing EDD v3.0+, INT 0x13/AH=0x48 - Get Drive Parameters can provide useful information for the OS to immediately at least know where to start looking for the booting drive. This would of course need to be executed before entering protected mode, the results can be examined from protected mode if you wish.

If grub enters protected mode for you, then I suppose there is either probably some information that grub passes that you could use (someone else would have to help here?), or you'll just have to do all your hardware detection and figure out, based on something else specific to your OS (e.g, you could check for the presence of grub on each disk), from which drive the BIOS has booted.

Or you could design your OS so that the installation sets GRUB up to pass a certain parameter to the kernel which identifies the path to a specific drive. These last few options may not be forgiving of hardware changes, though... you may also need to consider the possibility of dual booting two copies of your OS.

madeofstaples wrote:Forgive me if I'm a little naive about grub, I haven't really used it (at least not with OS development), but does it enter protected mode for your kernel?

Yes, it sets up protected mode before starting my kernel.

madeofstaples wrote:or you'll just have to do all your hardware detection and figure out, based on something else specific to your OS (e.g, you could check for the presence of grub on each disk), from which drive the BIOS has booted.

Yes, that would be a workaround, similar to my idea. I thought that I could check via boot_device wether my OS was booted from disk (0x80 or 0x81). If so, just use the given device-name from the module-parameter. If not, look if there are multiple ATAPI-drives. If just one, simply use it. If multiple ones, check for the presence of grub and perhaps my kernel-name. Although there's still no garantee that I use the correct drive, at least it should work in most cases.

madeofstaples wrote:Or you could design your OS so that the installation sets GRUB up to pass a certain parameter to the kernel which identifies the path to a specific drive. These last few options may not be forgiving of hardware changes, though... you may also need to consider the possibility of dual booting two copies of your OS.

Of course, but that doesn't help when booting from CD.

hrniels wrote:Of course, but that doesn't help when booting from CD.

You could consider a CD a special case and write a modified kernel/bootstraper specifically for the case when you are booting from a CD.

WRT to the odd drive numbers for CDs, I'm pretty sure there's a field you can set (probably via a mkisofs argument) which tells the BIOS to use a specific device number for no-emulation booting (default is 0, meaning "whatever you want, as long as it's obviously not a hard disk number").

You can also drop back to real mode (if you're careful not to trash any multiboot information when copying your code to below 1Meg) or enter V86 mode (probably safer, but same concerns as real mode and is a bit more complicated) and make BIOS calls

It seems that the Multiboot spec / Grub has a bad design.

The multiboot spec only provides the INT13h drive number, which is only good for INT13h and nothing else (eg identifying disks).

Look up Master Boot Record on Wikipedia. You can see there is an "Optional Disk Signature", which is supported by Microsoft and Linux. This uniquely identifies each disk.

The Multiboot spec should provide the disk signature as well. Apparently the disk signature is missing from multiboot, so that is a serious flaw.

You may be better of writing your own bootloader!

Doesn't the multiboot structure have a field for listing info about all of the installed drives, including BIOS number? So then wouldn't you be able to figure out which drive you're on based on that?

Or am I misremembering something I saw a while back, and completely wrong?

Firestryke31 wrote:Doesn't the multiboot structure have a field for listing info about all of the installed drives, including BIOS number? So then wouldn't you be able to figure out which drive you're on based on that?

Or am I misremembering something I saw a while back, and completely wrong?

Yes, but unfortunatly just hard disks (and probably floppy disks) as it seems.

Why do you think Microsoft designed a disk signature??

The BIOS / INT13h number is useless in protected mode.

Ok, now I've implemented it in the following way:
If the string "cdrom" is passed via multiboot-module-parameter instead of a concrete driver-name, all ATAPI-drives are tried. If a drive is present, it checks for the presence of my kernel in the boot-directory. If found, it uses the drive.

As I said, there's of course no garantee that I'll find the correct drive, but I think I can live with it
Thanks for your help!

Of course, if somebody has more information about this, it would be nice if he could post it here

Hi,

The only thing that is standardised is that if the 7th bit is set in the drive number that it is a hard disk. So any numbers greater than or equal to 0x80 are considered hard disks, although this is not true anymore as BIOSes allow booting up various other devices. The only way to get actual information about the drive number is, as said before, via INT 0x13/AH=0x48. This is one of the bad sides of the BIOS, as you might have noticed, but you can use several tricks to identify the drives such as comparing the disk size reported by the BIOS and/or the contents of a few sectors (using hashes or something similar).


Regards,
Stephan J.R. van Schaik.