4 ms·

I'm with you on this. It's similar to how every x86_64 OS guide goes through the ancient ritual of working your way up to long mode. Why not just use UEFI?

by davemp 8y ago

steveklabnik 8y ago
This one starts you in long mode, at least. :) UEFI just isn’t as well documented in a way that hobbyists can find, it seems. I know I’ve stuck to multiboot because there are so many examples and resources, and it’s one of the least interesting parts of the process, so I go with what’s simple. (Which is no longer multiboot and is now phil’s bootloader used in this tutorial.)
ajross 8y ago
Well... the hardware gets in your way there. Long mode properly requires paging to be enabled, which means that you have the choice between a complicated hardware bootstrapping proceedure to enable it, or a complicated bootloader environment which has already grabbed and used chunks of memory for page tables you need to not step on. Also, use of real mode (still required for BIOS calls like e820) requires the ability to get back out of real mode, so you need the bootstrapping stuff in a real OS even if it's not in the tutorial. But the register poking in the PIC/PIT is just silly. Turn that stuff off and use the correct hardware, even in a tutorial. Unless it's a tutorial on PC architecture history, I guess.
- davemp 8y ago
  > ...use of real mode (still required for BIOS calls like e820) requires the ability to get back out of real mode, so you need the bootstrapping stuff in a real OS even if it's not in the tutorial. I'm not particularly well versed in UEFI/BIOS features, but shouldn't BIOS calls like e820 be avoided in favor of equivalent UEFI functions? > the hardware gets in your way there. Long mode properly requires paging to be enabled, which means that you have the choice between a complicated hardware bootstrapping proceedure to enable it, or a complicated bootloader environment which has already grabbed and used chunks of memory for page tables you need to not step on. Just figuring out the UEFI's page-table structure seems much less burdensome to me. You'd have to set the tables up yourself regardless. Is the documentation/environment really so poor as to make just doing it yourself easier? In theory you should just be able to include a header or use a crate (a cousin comment linked one) and not have to write any assembly.
  - ajross 8y ago
    > shouldn't BIOS calls like e820 be avoided in favor of equivalent UEFI functions? Should, but can't, because they don't work in general. Windows and Linux get their memory map from e820, so that's all the system vendors test.
- zaarn 8y ago
  >which has already grabbed and used chunks of memory for page tables you need to not step on. UEFI supplies you with a memory map that allows you to see what memory is untouchable and large chunks of it can be remapped away into memory regions you don't touch.
a-priori 8y ago
If you're interested in this there's a Rust crate for creating UEFI-bootable images and accessing the runtime and boot services. https://github.com/GabrielMajeri/uefi-rs https://github.com/GabrielMajeri/uefi-rs https://github.com/GabrielMajeri/uefi-rs/blob/master/BUILDING.md https://github.com/GabrielMajeri/uefi-rs/blob/master/BUILDIN... I'm using it for my kernel development tinkering and it works fine except for being a bit incomplete as far as implementing all the services.

I'm with you on this. It's similar to how every x86_64 OS guide goes through the ancient ritual of working your way up to long mode. Why not just use UEFI?

by davemp 8y ago

I'm with you on this. It's similar to how every x86_64 OS guide goes through the ancient ritual of working your way up to long mode. Why not just use UEFI?

steveklabnik 8y ago

This one starts you in long mode, at least. :) UEFI just isn’t as well documented in a way that hobbyists can find, it seems. I know I’ve stuck to multiboot because there are so many examples and resources, and it’s one of the least interesting parts of the process, so I go with what’s simple. (Which is no longer multiboot and is now phil’s bootloader used in this tutorial.)

ajross 8y ago

Well... the hardware gets in your way there. Long mode properly requires paging to be enabled, which means that you have the choice between a complicated hardware bootstrapping proceedure to enable it, or a complicated bootloader environment which has already grabbed and used chunks of memory for page tables you need to not step on. Also, use of real mode (still required for BIOS calls like e820) requires the ability to get back out of real mode, so you need the bootstrapping stuff in a real OS even if it's not in the tutorial. But the register poking in the PIC/PIT is just silly. Turn that stuff off and use the correct hardware, even in a tutorial. Unless it's a tutorial on PC architecture history, I guess.

davemp 8y ago
> ...use of real mode (still required for BIOS calls like e820) requires the ability to get back out of real mode, so you need the bootstrapping stuff in a real OS even if it's not in the tutorial. I'm not particularly well versed in UEFI/BIOS features, but shouldn't BIOS calls like e820 be avoided in favor of equivalent UEFI functions? > the hardware gets in your way there. Long mode properly requires paging to be enabled, which means that you have the choice between a complicated hardware bootstrapping proceedure to enable it, or a complicated bootloader environment which has already grabbed and used chunks of memory for page tables you need to not step on. Just figuring out the UEFI's page-table structure seems much less burdensome to me. You'd have to set the tables up yourself regardless. Is the documentation/environment really so poor as to make just doing it yourself easier? In theory you should just be able to include a header or use a crate (a cousin comment linked one) and not have to write any assembly.
- ajross 8y ago
  > shouldn't BIOS calls like e820 be avoided in favor of equivalent UEFI functions? Should, but can't, because they don't work in general. Windows and Linux get their memory map from e820, so that's all the system vendors test.
zaarn 8y ago
>which has already grabbed and used chunks of memory for page tables you need to not step on. UEFI supplies you with a memory map that allows you to see what memory is untouchable and large chunks of it can be remapped away into memory regions you don't touch.

a-priori 8y ago

If you're interested in this there's a Rust crate for creating UEFI-bootable images and accessing the runtime and boot services. https://github.com/GabrielMajeri/uefi-rs https://github.com/GabrielMajeri/uefi-rs https://github.com/GabrielMajeri/uefi-rs/blob/master/BUILDING.md https://github.com/GabrielMajeri/uefi-rs/blob/master/BUILDIN... I'm using it for my kernel development tinkering and it works fine except for being a bit incomplete as far as implementing all the services.