OSDev.org

Hello. I have a small OS that boots from my own boot loader. I can directly boot it from in a virtual machine. I also can boot it from a usb device using a chain loader, but I have to change the arguments of BIOS disk read functions to read from the appropriate location manually. Can I automate this process somehow, by detecting the location of the boot sector which the BIOS or the chain loader loaded? Without loading the partition table and checking each and every partition?

I need to get the location of last BIOS read in LBA or even better, in CHS. How to do it?

You could hard-code/embed the location(s) in the boot sector (and possibly the sectors loaded from there on) when you create the disk image.

alexfru wrote:You could hard-code/embed the location(s) in the boot sector (and possibly the sectors loaded from there on) when you create the disk image.

I think that's a good idea. I have experience with Lilo (the Linux Loader), which essentially did this for physical disks. It took the kernel filename in its config file, looked up the files blocks, and wrote the blocks into the bootloader. It did the same to write the location of its own second stage into the first stage. I thought it quite good; it was certainly reliable by the time I started using it. If I'd scripted it into a sort of "make install" process, I would have nothing bad to say about it. (Without that scripting, it got a little tiresome when I changed my kernel frequently.) It was also very much simpler than Grub.

Just for completeness, I'm mentioning a problem I never had: Lilo's documentation hinted that it could have trouble determining the BIOS's view of the disks because it ran within Linux. I'm sure it won't be a problem if you're making a disk image. I never had the problem in years of running it on a wide variety of machines.

eekee wrote:Just for completeness, I'm mentioning a problem I never had: Lilo's documentation hinted that it could have trouble determining the BIOS's view of the disks because it ran within Linux. I'm sure it won't be a problem if you're making a disk image. I never had the problem in years of running it on a wide variety of machines.

When you use the LBA disk read interrupt, you don't have that problem, even on a real hardware disk.

If you use CHS, you need to determine the disk geometry (sectors per track, number of heads) on your host OS.

Thanks PeterX. I think there was a little bit of pre-LBA hardware around when I started using Linux. That's a bit of a long time ago, now!

pranavappu007 wrote:I need to get the location of last BIOS read in LBA or even better, in CHS. How to do it?

Forget CHS, use LBA. Most modern storage devices does not support CHS anyway, and there's no guarantee that all BIOSes emulate CHS correctly or at all. However you can always access USB sticks and CDROMs using LBA.

Otherwise what eekee said. This is what my loader does, but I also mandate that the 2nd stage loader must be contiguous, therefore only the first sector needs to be saved in the boot sector. My image creator tool (which stores the 2nd stage in a SYSTEM file on the FAT formatted ESP) does this automatically, but here's a small tool that updates the boot sector on an existing device. It locates the 2nd stage by magic bytes (line 86), therefore it can work with any file system you want (or 2nd stage could be in BPB hidden sectors or entirely outside of any partition). Then the LBA address is updated in the boot sector at 1B0 (line 100).

You could do something similar with your loader.

Cheers,
bzt

Several of Microsoft's filesystems reserve space in the boot sector to store the LBA of the first sector in the partition. Formatting tools usually populate that field with the correct value automatically. If you're not using one of those filesystems, you can still do something similar, but you'll have to figure out some way to write the correct LBA.

PeterX wrote:

eekee wrote:Just for completeness, I'm mentioning a problem I never had: Lilo's documentation hinted that it could have trouble determining the BIOS's view of the disks because it ran within Linux. I'm sure it won't be a problem if you're making a disk image. I never had the problem in years of running it on a wide variety of machines.

When you use the LBA disk read interrupt, you don't have that problem, even on a real hardware disk.

I think the LILO documentation is actually talking about the drive number you have to put into DL to use INT 0x13 to read the disk. On ancient hardware without BIOS PnP support, the BIOS might pass garbage in DL instead of the correct drive number.

PeterX wrote:If you use CHS, you need to determine the disk geometry (sectors per track, number of heads) on your host OS.

That really only works for floppy disks, since the geometry of a floppy disk is a physical property of the disk. For other media, the BIOS might perform translation, so you need to use INT 0x13 AH=0x08 to figure out what geometry the BIOS wants you to use. You can't use values presented by your host OS since host might not know what translation the BIOS will use, and even if it does the translation will be different on different computers. For USB flash drives, the translation might change even on the same computer, since some BIOSes will choose different translations depending on the content of the drive!

alexfru wrote:You could hard-code/embed the location(s) in the boot sector (and possibly the sectors loaded from there on) when you create the disk image.

I actually do that. I boot my system using Volume Boot Record of the active partition in a USB drive. Currently, it is the first partition(I created a small 8MB partition for this so that I can use the USB drive for other purposes.) My bootloader and kernel and all is linked together for easiness, and I load the kernel from bootloader by loading subsequent sectors. For simplicity, I hard coded the location of the rest by finding it in fdisk(I use CHS). But doing that will not allow me to place OS in any other location except here.

I had a work around using the partition table, but that also assumes that I don't have any other OS installed and MBR exist. Rather than writing special case codes, I want a general way to know he location of the currently loaded location, so that I can load the subsequent locations.

pranavappu007 wrote:For simplicity, I hard coded the location of the rest by finding it in fdisk(I use CHS). But doing that will not allow me to place OS in any other location except here.

Why not? You could update those locations with your partitioning tool for example when you write the boot sector.

pranavappu007 wrote:I had a work around using the partition table, but that also assumes that I don't have any other OS installed and MBR exist. Rather than writing special case codes, I want a general way to know he location of the currently loaded location, so that I can load the subsequent locations.

Take a look at the link I've provided in the previous post. It does exactly that: locates the 2nd stage (in your case that would be the kernel) and saves the position in the boot sector code. Simple, no partitioning table assumed (neither by the mkboot tool nor by the boot sector code).

Cheers,
bzt

I actually do use the MBR. I formatted the device using Windows, so I do have a MBR and a chain loader. My OS consists of a VBR-kernel bundle. My VBR is loaded by Windows chain loader, and I load the rest. But as the kernel can be written to any partition, located anywhere, I can't make any assumption about the actual physical location of my VBR. Without that, I can't find the kernel.

I currently implemented to load the MBR(Windows) and get the co-ordinates of VBR from the partition table, assuming there is no other Installed OS. But I don't like it. One issue is with if other OS is installed. As it is not a commercial OS, dual booting is unlikely so it's ok.
The more problematic issue is if the device doesn't contain a partition table at all. If the MBR itself is my boot sector, my partition table detection code will break and will crash. So I at least need a method to detect the presence of a partition table. More helpful if I could find out the the currently loaded sector in CHS or LBA.

I read on wiki that a chain loader loads the currently loaded sector DS:SI but my attempt to retrieve it failed.

pranavappu007 wrote:I read on wiki that a chain loader loads the currently loaded sector DS:SI but my attempt to retrieve it failed.

The MBR used by Windows Vista and newer doesn't set DS:SI.

I don't think there's any good way to find the boot partition, especially when dual-booting. Your best bet is storing the VBR's LBA in the VBR somewhere.

Octocontrabass wrote: Your best bet is storing the VBR's LBA in the VBR somewhere.

So other OS like Windows and linux create a dynamic VBR with it's location embedded at install time? I thought They just copy the VBR like other files..

Also I wonder how Boot Managers like GRUB detects other OS using scripts. Does it checks the VBR of all partitions? Or does it directly checks for Windows files(or other linux)?!

pranavappu007 wrote:So other OS like Windows and linux create a dynamic VBR with it's location embedded at install time?

Windows embeds the VBR's location into the VBR. (It's actually part of the filesystem, in the BPB.)

GRUB and LILO don't embed the VBR's location, but they do embed a list of sectors so the VBR code can load the next stage of the bootloader.

pranavappu007 wrote:My VBR is loaded by Windows chain loader, and I load the rest. But as the kernel can be written to any partition, located anywhere, I can't make any assumption about the actual physical location of my VBR.

You haven't checked the link I provided. My boot sector works as VBR, and the tool I've linked can install it in a VBR of a partition. I've carefully written my boot sector code to work as MBR as well as VBR and even as a CDROM boot sector too.

pranavappu007 wrote:Without that, I can't find the kernel.
...
The more problematic issue is if the device doesn't contain a partition table at all.

How so? The BIOS read sector function uses absolute sector addresses, and knows nothing about partitions. You simply use the LBA address stored in the VBR (again, check my tool!).

pranavappu007 wrote:I read on wiki that a chain loader loads the currently loaded sector DS:SI but my attempt to retrieve it failed.

Nope, DS:SI should point to the partition table record used to load the VBR, and not to the loaded sector. But as others have pointed out, you should not rely on this. The only thing you can be sure of is that DL contains the drive code.

Cheers,
bzt

bzt wrote:How so? The BIOS read sector function uses absolute sector addresses, and knows nothing about partitions. You simply use the LBA address stored in the VBR (again, check my tool!).
Cheers,
bzt

The problem with me is I can't have a separate VBR as my VBR actually contains some "driver" code(actually more than that). More than that, I don't have any kind of installer to dynamically change the VBR code. I want the VBR to put in any active partition manually(tools like dd) and just work, at least if no other OS is there(like a USB drive partition). That does work with my partition detection code.(my crazy file system implementation can break, but still) But it doesn't work if I had a IMG image to use in VM. (No partition table)
I might write a C program to modify the CHS/LBA location embedded in VBR to install to a partition, but not now.

Even though I say "Boot loader" or "kernel", it is all linked(not concatenated but actually linked by linker) and is one giant Binary file which contains everything to boot up and give prompt.

So that's why I wanted some method that does what I requested.My VBR is completely in nasm lintel assembly but is linked with the kernel through GCC linker.