Rewrite

[katietheqt-old]

Bootloader Rewrite

This is the tracking issue for the bootloader rewrite. We're tracking our progress under the "Rewrite" milsestone. Our progress is as follows

• Successfully execute Rust in real mode
• Enter protected mode
• Use virtual 8086 mode to read the kernel in chunks, copying to protected mode
• Set up paging
• Enter long mode
• Jump to the kernel

Our eventual roadmap is to include UEFI support (@phil-opp is working on that) and multiboot client support, so we can load our kernel from GRUB (and other complaint loaders)

[katietheqt-old]

On the other hand, 16-bit Rust might be a whole other project.

[phil-opp]

Thanks for opening this issue! I absolutely want to replace as much assembly as possible with Rust, I just didn't have the time to look into this yet.

I think LLVM even has explicit support for real mode x86, so it should be possible to rewrite the 16 bit assembly in Rust.

[katietheqt-old]

Sorry for the late reply but I'll try and look into this, and I'll make a PR. I'm away from my development machine right now, but I can still research and write some code when I get back next week.

LLVM has support for 16-bit, sort of. From a section in the LLVM User Guide:

For the X86 target, clang supports the -m16 command line argument which enables 16-bit code output. This is broadly similar to using asm(".code16gcc") with the GNU toolchain. The generated code and the ABI remains 32-bit but the assembler emits instructions appropriate for a CPU running in 16-bit mode, with address-size and operand-size prefixes to enable 32-bit addressing and operations.

[phil-opp]

It was a very fast reply!

LLVM has support for 16-bit, sort of. From the a section in the LLVM User Guide:

Awesome!

I'll try and look into this, and I'll make a PR. I'm away from my development machine right now, but I can still research and write some code when I get back next week.

Thanks a lot for tackling this! Don't hurry, I'm on vacation until the end of september anyway, so I won't be able to review PRs until then.

[phil-opp]

Triage: I'm still interested in this. There was a recent [reddit post](https://www.reddit.com/r/rust/comments/ask2v5/dos_the_final_frontier/] where someone got Rust working in a 16-bit DOS environment, which sounds exactly like what we want to do. The corresponding code is available on GitHub I assume that especially the target JSON is useful for us.

[lashtear]

Keep in mind that the 16bit x86 output of llvm (and gcc/gas for that matter) often still assumes it's a higher-word processor, and may emit 32bit and 64bit prefixes for dealing with data of that size. For example, that target JSON will work for 80386+, but probably not be operational on an 80286 or below. Side note-- yes the 286 can do protected-mode 16bit.

But yes-- worth looking at! It's entertaining that ARM et al get so much credit for having the Thumb ISA when other architectures more or less fell into that feature-set by accident.

[katietheqt-old]

@phil-opp That target spec needs GCC, and I thought we were aiming to avoid additional software

[phil-opp]

@rybot666 We definitely want to keep using LLD, but maybe LLD has support for these (or similar) arguments too.

[katietheqt-old]

@phil-opp Working on modifying that DOS target to rust-lld. Seems like it doesn't support the options we need (-m16, -ffreestanding). I don't know what we could do to fix this... (Although -m16 isn't needed, because we use the target i386-unknown-none-code16 that does exactly what -m16 does). Do you have something like Discord for live chat?

[phil-opp]

I'm not sure if we need -ffreestanding with LLD, we don't use it for our freestanding kernel/bootloader either. Maybe it's a GCC related flag.

Although -m16 isn't needed, because we use the target i386-unknown-none-code16 that does exactly what -m16 does

That's good to know!

Do you have something like Discord for live chat?

Yes, I'm phil-opp#1436 on discord.

[katietheqt-old]

@phil-opp I don't know if you're free, but I'm working on this now - I sent you a friend request on Discord

[michalfita]

Do you really need to support pre-EFI machines?

[phil-opp]

@michalfita We currently only support non-EFI booting (nobody has had the time to add EFI support yet).

And yes, I think that it's worth keeping support for pre-EFI machines, since these machines are often used for testing. For example, I use my old machine for booting my kernel so that I can continue working on my main machine in parallel.

[katietheqt-old]

So, I got Rust running in bare metal 16-bit mode. I had to use a bit of assembly to set up stack and load rust from disk. The issue I'm thinking we may have is that booting needs a lot of assembly anyway so I don't know how much can be ported to pure Rust. Also unsure as to how to get cargo to build me multiple targets and then link them together (so we can swap from our 16-bit target to a 32-bit one). I think that disk loading logic will be much easier to understand with Rust though.

cc @phil-opp

[katietheqt-old]

It's a project to get it into as much Rust as possible, to prove that it's possible and to make it easier to explain (I'd say Rust traits and structs are easier to understand than raw mov's and int's). Anyway UEFI would be easier with rust bindings