Giters

rust-osdev / bootloader

An experimental pure-Rust x86 bootloader

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Enable support for executing arbitrary functions in real mode

a-usr opened this issue · comments

commented

Sometimes it is necessary to be able to execute code in real mode, especially if you want / need to use a BIOS function that is only available in real mode. (e.g. the APM Installation check function (God why did I even decide that I needed to support this piece of legacy junk)).

Thats why I propose to add a new field to the BootloaderConfig struct in the bootloader-api, wich takes a FnOnce, which in return is executed some time before the switch to protected mode happens.

commented

Real mode is 16bit, but the kernel is compiled as 64bit executable. As such trying to run your closure in real mode will crash. You need to separately compile the code you want to run in real mode for 16bit x86 and link it such that it expects to run at an address within the first 1MB of ram. Also instead of using the bootloader to run it, would using virtual8086 mode work? That provides a kind of VM to run BIOS functions in.

commented

Real mode is 16bit, but the kernel is compiled as 64bit executable. As such trying to run your closure in real mode will crash. You need to separately compile the code you want to run in real mode for 16bit x86 and link it such that it expects to run at an address within the first 1MB of ram.

Fair point, I didnt know that about real mode.

Also instead of using the bootloader to run it, would using virtual8086 mode work?

This Post in osdev claims that V86 mode is nonexisted when in 64 bit mode (which i think is long mode?)

commented

This Post in osdev claims that V86 mode is nonexisted when in 64 bit mode (which i think is long mode?)

Right. By the way why are you using an APM function with x86_64? Don't all x86_64 systems support ACPI? And if you can't interact with APM after booting anyway, why do you need to interact with it during booting?

commented

By the way why are you using an APM function with x86_64?

I really just wanted a way to shutdown the system even if there was no acpi table present or there was any other reason why i couldnt interact with the acpi

Don't all x86_64 systems support ACPI?

I really hope this is true, but i cant find anything that prooves or disprooves this statement

And if you can't interact with APM after booting anyway, why do you need to interact with it during booting?

Well, I CAN interact with the apm after booting, since it has a protected mode 32 bit interface (of which im just noticing that it mignt not exactly be available when compiling for x86_64). The installation check however is required since

  1. Newer hardware doesnt support the APM anymore, and
  2. the Installation check is the only way to find out the version and flags of the installed APM

And of course, the Installation check is only available when in real mode

commented

Hmmmm
Considering acpi is a thing since 1996 I think its rather safe to assume that the table is existent in ram and usable...

commented

I'll close this for now. Thank you a lot for your help!