Best hard disk driver approach

[Bietje]

The problem was, that I have to load something above 1MiB (or load it under it and memcpy it to 1Mib). This is not possible in real mode, and therefore I threw BIOS interrupt 0x13 overboard. After I did that I started to look at several ways to access disks manually. That doesn't seem to be an option either since I have to write something for everything (usb, scsi, sata, ide). Should be a problem normally but at the moment I have only a few dozen of sectors left before I am at the top of usable low memory.

That was the moment this topic started.. Now I am wondering, do I have to throw all BIOS things overboard and replace it with EFI, or can I go on with using the bios where I am using it now (loading in the first sector, displaying the first letters on screen, loading the bootloaders second stage) and use EFI to load the bootloaders' kernel which will be slightly bigger and therefore not fit in the memory range 0x8000 - 0x100000.

[Brendan]

Hi,

I have never looked at EFI before.. So, I'm not completely familiar with it. Does it replace the BIOS completely and do I boot with a special image written to boot with EFI? Or can I boot normally with the BIOS, do stuff and when I need the hard disk, I jump to a special image which can use EFI? That last sounds to nice to be true, actually..

For EFI, the firmware could be 32-bit EFI (running in protected mode without paging) or 64-bit EFI (running in long mode with "identity mapped" paging). The boot loader has to be a PE32+ executable, and has to be 32-bit for 32-bit EFI, and has to be 64-bit for 64-bit EFI. In either case if you're using EFI you can't use BIOS (it won't exist).


Cheers,

Brendan

[Love4Boobies]

The problem was, that I have to load something above 1MiB (or load it under it and memcpy it to 1Mib). This is not possible in real mode, and therefore I threw BIOS interrupt 0x13 overboard. After I did that I started to look at several ways to access disks manually. That doesn't seem to be an option either since I have to write something for everything (usb, scsi, sata, ide). Should be a problem normally but at the moment I have only a few dozen of sectors left before I am at the top of usable low memory.

The two solutions for BIOS machines are:

• Use unreal mode to access more memory (BIOS interrupts will function as normal).
• Switch to real mode each time you want to use INT 13h and to protected mode each time your buffer is full (or you are done) in order to move it over the 1 MiB barrier.

That was the moment this topic started.. Now I am wondering, do I have to throw all BIOS things overboard and replace it with EFI, or can I go on with using the bios where I am using it now (loading in the first sector, displaying the first letters on screen, loading the bootloaders second stage) and use EFI to load the bootloaders' kernel which will be slightly bigger and therefore not fit in the memory range 0x8000 - 0x100000.

I'm starting to think you don't understand what firmware is. Use (U)EFI for machines that have (U)EFI and use BIOS for machines that have BIOS. Note that (U)EFI systems don't drop you in real mode---it's either protected mode or long mode. Next thing you'll ask is whether you can write half of the boot sector in ARM assembly

[Brendan]

Hi,

The problem was, that I have to load something above 1MiB (or load it under it and memcpy it to 1Mib). This is not possible in real mode, and therefore I threw BIOS interrupt 0x13 overboard. After I did that I started to look at several ways to access disks manually. That doesn't seem to be an option either since I have to write something for everything (usb, scsi, sata, ide). Should be a problem normally but at the moment I have only a few dozen of sectors left before I am at the top of usable low memory.

The normal approach is to load sectors into a buffer below 1 MiB in real mode, then switch to either protected mode or unreal mode and copy the data from the buffer below 1 MiB to where-ever it needs to be above 1 MiB; and do that in a loop until everything is loaded.

That was the moment this topic started.. Now I am wondering, do I have to throw all BIOS things overboard and replace it with EFI, or can I go on with using the bios where I am using it now (loading in the first sector, displaying the first letters on screen, loading the bootloaders second stage) and use EFI to load the bootloaders' kernel which will be slightly bigger and therefore not fit in the memory range 0x8000 - 0x100000.

I wouldn't throw all BIOS things overboard, as they're still selling new computers that don't have EFI and you probably want your OS to support them.

I'd have some sort of "boot abstraction layer", where all boot loaders put the computer into the same specific state before later code (kernel?) is started, so that later code doesn't need to know/care if the firmware was EFI or BIOS or something else. That makes it easy for the OS to support both BIOS and EFI at the same time because the only difference is different boot loaders.

For a simple example, if all boot loader loads the kernel at 0x00100000, switches to protected mode and jumps to it; then the kernel wouldn't need to care how it got loaded.

Of course the simple example is too simple. For example, for EFI there's no guarantee that there's usable RAM at 0x00100000, so you might want to support loading the kernel at any physical address instead. Then there's things like passing information to the kernel - things like where the ACPI tables and SMBIOS tables are. You might want the boot loader to pass some sort of structure describing these things to the kernel, so the kernel can find them without using (firmware specific) methods. Finally there's video - you may want the boot loader to setup a video mode and tell the kernel what it is, so that the kernel doesn't need to know/care what firmware was used (or if VESA/VBE or EFI has to be used to setup a video mode).


Cheers,

Brendan