Alternative loading technique

[0b00000000]

Hi,

so it seems that most boot loading techniques out there are using INT 13 variants to load code beyond the first sector (assumed to be automatically loaded by the BIOS is certain conventions have been adhered to).

But what if we aren't happy with the assumption that the BIOS can perform those INT 13 variants for us? Or simply would just rather not rely on the BIOS to do this for us and want complete independence from the BIOS immediately?

Is there any way to load sectors into memory without using INT 13 but using direct methods that do not rely on any of the BIOS functions?

[Octocontrabass]

Is there any way to load sectors into memory without using INT 13 but using direct methods that do not rely on any of the BIOS functions?

Yes.

However, all of those methods take up way more space than using int 0x13, and you need separate code for each type of device. Good luck fitting that in under 512 bytes.

[alexfru]

Is there any way to load sectors into memory without using INT 13 but using direct methods that do not rely on any of the BIOS functions?

Yes.

However, all of those methods take up way more space than using int 0x13, and you need separate code for each type of device. Good luck fitting that in under 512 bytes.

Or one could build their own hardware, not PC-compatible, w/o the traditional BIOS and maybe with a simplified chipset...

[0b00000000]

Is there any way to load sectors into memory without using INT 13 but using direct methods that do not rely on any of the BIOS functions?

Yes.

However, all of those methods take up way more space than using int 0x13, and you need separate code for each type of device. Good luck fitting that in under 512 bytes.

Would it be feasible to fit the code for a single known device into the 512 bytes?

[Antti]

However, all of those methods take up way more space than using int 0x13, and you need separate code for each type of device. Good luck fitting that in under 512 bytes.

That is one problem but I think it is not the main reason for this being a bad idea. Please note that the INT 13h services are not necessarily "what they look like", i.e. there might be an intermediate layer that provides that abstraction. It is (or should be) a de facto standard that boot loaders use those services for accessing their boot storage media.

[Combuster]

Would it be feasible to fit the code for a single known device into the 512 bytes?

In your case, no.

[0b00000000]

Would it be feasible to fit the code for a single known device into the 512 bytes?

In your case, no.

In your case yes?

[Techel]

It might be possible in really simple cases, but when adding support for a filesystem (fat e.g. requires it's parameter block in the first sector, the available bytes for the boot code shrink to ~440 bytes minus the code for finding the kernel file) int 13h is the only thing to use.

[0b00000000]

It might be possible in really simple cases, but when adding support for a filesystem (fat e.g. requires it's parameter block in the first sector, the available bytes for the boot code shrink to ~440 bytes minus the code for finding the kernel file) int 13h is the only thing to use.

So, in the scenario with no file system just reading raw binary from the media could this be done?

[intx13]

Think about what your code needs to do to read a sector from a SATA drive, and then decide if you think it can be done in 446 bytes:

• Initialize PCI controllers and, if not already done by BIOS, assign BARs.
  • Assigning BARs requires knowing the system memory map. You'll need to use INT15H to get that.
  • If you don't want to use INT15H either, you'll need a chipset driver to query the memory controller for DRAM configuration and an ACPI driver to parse the DSDT and build a memory map from that.
• Search for AHCI HBAs and initialize them.
• Initialize active ports and query the attached devices.
• Select one of the devices and send it a read.

Additionally you'll want OHCI, UHCI, and EHCI drivers for booting from USB drives, plus the mass storage class drivers.

[onlyonemac]

You could probably write a floppy disk driver in under 512 bytes, which would allow you to read arbitrary sectors from a floppy disk. Forget about filesystem parsing though; you'll have to just blindly load specific sectors as there probably won't be enough space in the boot sector for a floppy disk driver *and* a filesystem parser. Of course, once you can read sectors, you can load a filesystem parser for whatever filesystem you want from elsewhere on the disk, but that's only *after* you've already blindly loaded the filesystem parser. It might be better to use one floppy disk of known layout to store the rest of the bootloader (which includes the filesystem parser and/or drivers for other storage devices), load that, then prompt the user to insert another disk containing the actual operating system, which can then be parsed and loaded with the filesystem parser and executable loader which were read by the bootsector from the first disk.

In short, yes you can probably write a bootloader to load *one* format of kernel from *one* kind of device without using any BIOS interrupts. If that's what you call a bootloader, then fine. From an experimental point of view it's an interesting exercise, but in reality it's clumsy and doesn't offer any real advantage.

P.S. I gather from some of your posts around here that you have a fear of low-level espionage against your computer? You seem to be intent on avoiding the BIOS as much as possible, and the virtual machines thread was kind of creepy...

[azblue]

I seem to recall estimating that PIO reading legacy harddrives could be done in about 150 bytes.