bootloader
bootloader copied to clipboard
rust-osdev
32-bit support (with Multiboot2)
cc https://github.com/phil-opp/blog_os/issues/403#issuecomment-516832927.
@Mendess2526 let's continue the discussion here.
This will need src/stage_3.s to be adapted to stay in protected mode and to setup non-PAE page tables. It will then need at least changes to the rust part to handle non-PAE page tables.
I hope this is togglable with a feature flag. Just saying, I'm personally not in favor of this idea.
On 7/31/19, bjorn3 [email protected] wrote:
cc https://github.com/phil-opp/blog_os/issues/403#issuecomment-516832927.
@Mendess2526 let's continue the discussion here.
This will need src/stage_3.s to be adapted to stay in protected mode and to setup non-PAE page tables. It will then need at least changes to the rust part to handle non-PAE page tables.
-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rust-osdev/bootloader/issues/70
-- Signed, Ethin D. Probst
Yeah it would need to be a toggleable feature. We should support the multiboot2 protocol for this
I hope this is togglable with a feature flag.
Shouldnt it just work when it is compiled for i686 instead of x86_64?
Yeah that’s a good point. I think in the mean time it might be good to add some check in the build script that it’s being built for x86_64 (if that is even possible), otherwise error out and point to this issue
I think in the mean time it might be good to add some check in the build script that it’s being built for x86_64 (if that is even possible), otherwise error out and point to this issue
This should be possible through the CARGO_CFG_TARGET_ARCH environment variable, but only when the crate is used as a library. The binary compilation currently occurs for a fixed target specified in the Cargo.toml, but this could be easily changed by updating bootimage (e.g. by making the package.metadata.bootloader.target a (target_arch, target file name) map).
Personally I don't think we should support 32-bit at all. The only reason I can see this being required is running this on old hardware, and you have VMs for that. Now that you can chainload the bootloader (via grub, for example), you can (technically) run the system on "real" (virtual, but technically real) hardware. Its not physically real, but virtualized hardware, with a few changes here and there, is based off of at least a model of old hardware (i.e. the VMware BIOS implementation uses Phoenix BIOS, I think). 32-bit support overcomplicates a lot of things and would just bloat the code to unreasonable proportions.