OSDev.org

Currently my bootloader uses the disk number in DL and the partition info pointed to by DS:SI to load the second stage loader using BIOS interrupts. So I don't use any BPB info in the bootloader. I'm using my own file system. My questions are:
1) Is there *any* point in including a BPB in the boot sector?
2) Once my own HDD drivers are loaded, how do I tell which drive I was booted from?

Hi,

madanra wrote:Currently my bootloader uses the disk number in DL and the partition info pointed to by DS:SI to load the second stage loader using BIOS interrupts. So I don't use any BPB info in the bootloader. I'm using my own file system. My questions are:
1) Is there *any* point in including a BPB in the boot sector?
2) Once my own HDD drivers are loaded, how do I tell which drive I was booted from?

1) The BPB is only really used for floppy drives, where it's difficult to determine the number of heads, sectors per track, etc without it. It's also a "DOS thing" rather than something that I'd consider an accepted standard that's intended for all OS's (like the partition table), and some OSs are happy to go without it (for "non-FAT" floppies).

2) How do you know which HDD drivers to load if you don't know which drive you were booted from? It's possible to have SCSI, ATA, SATA, SAS and USB hard drives; and that's not including USB flash and USB/ATAPI/SATA/SCSI CD-ROMs emulating a hard drive.

The BIOS gives you a (mostly meaningless) "device number" in DL. You can use this with
"IBM/MS INT 13 Extensions - GET DRIVE PARAMETERS" to determine what sort of device and where it's connected, and if that fails you can fall back to "Int 0x13, AH = 0x08" (although you'd want to make sure it's not an emulated device first).

Once you've done this you should be able to figure out which driver to load (and you should also know which device to use the driver on). Much easier to just use the BIOS though (it'd save you the hassle writing lots of "temporary drivers" that are useless once the kernel is running anyway)...


Cheers,

Brendan

Ah no, I wasn't meaning which drivers to load/temporary drivers, I was meaning the 'real' drivers & the kernel - eg. once I transfer control to the kernel, how does it know which drive it was booted from?
Anyway, int 0x13/ah=0x48 looks like it'll provide all the info I need, thanks!

One problem you will have is you will not beable to boot usb under floppy emulation.
Normaly the MBR or boot sector is just load into memory at a set address and jump to.
But in the case of USB boot, it checks for BPB, if it users hdd emulation it will boot with or without BPB, if it users floppy emulation and you do not have a BPB, it will NOT boot.

madanra wrote:Ah no, I wasn't meaning which drivers to load/temporary drivers, I was meaning the 'real' drivers & the kernel - eg. once I transfer control to the kernel, how does it know which drive it was booted from?
Anyway, int 0x13/ah=0x48 looks like it'll provide all the info I need, thanks!

If I am wrong someone please jump to the reply button to correct me or provide additional information!

The reason I am posting is because it looks like the information provided by BIOS may not be 100% standard, and you might end up with a large headache when using it on machines that do not conform. It is funner if you find a more portable method to do the work. You do not have to use GRUB. You could instead write something very similar but simpler. It might not be as portable as GRUB, but it may be more portable than trying to boot directly into the kernel from 512 bytes. Rather, to a second stage where you can still access the BIOS functions until you have everything loaded including the kernel, or what every your imagination can think of. You could tag a stub onto the kernel which is written in assembly, seperate file,.. the possibilities are endless really.

I could be wrong, but I thought it might be helpful to you and others. That the kernel does not have to boot from the device that it was loaded from. A good example is how GRUB actually works. GRUB starts from the boot sector. The details I can no go into because of lack of knowledge, but the point it that it becomes loaded just like your custom boot program.

Then it loads some second stage files which allow to to communicate understand file systems (lacking knowledge). Since all of this would not fit into 512 bytes or what ever size the boot block might be for whatever device. Once it does this then it can load an arbitrary file from a disk and a filesystem. This is normally going to be the kernel.

From this point either an identifier like (/dev/hda1, /dev/sda1, /dev/blahfoo) is passed to the kernel to tell it where it should continue to boot from. I am not sure, maybe some more people can help, you find out if GRUB passes this information to the kernel in it's information structure so it could be like a default fall back. You should read the GRUB documentation if you want to be 100% sure since that will be easier than asking, unless it is difficult for you to understand.

I'm not trying to boot directly into the kernel from the 512-byte bootsector - my bootsector loads a second stage loader which (once I've written it...) will load the kernel. As I don't want my OS to be MBR-specific, all my bootsector assumes is that it is loaded to 0x007c0 and DL=drive number, DS:SI points to partition info, which (I believe) all MBRs do.