I am designing a multi-architecture bootloader to use in future OS projects.
Currently working on the bootstrap process for aarch64 and x86_64-UEFI.
For now, this section is very brief, but I plan to expand it so that it can be really easy to build the bootloader and test it out.
Note: Don't use the -j
argument when running make. As cargo handles most of the build process, allowing make to use multiple threads does not improve the build speed.
To quickly test out the boot loader's aarch64 implementation, run the following:
make qemu
If you just want to build and not run in qemu, remove 'qemu' from the arguments:
make
It may be difficult to run for x86_64-unknown-uefi
because the build system currently assumes that OVMF will be used from one of the default Linux paths (/usr/share/**/OVMF.fd
).
If it's not found, then it will be compiled from scratch. This may fail if you don't have all the OVMF build dependencies, listed here. I will soon change this so that it will instead be automatically downloaded, but I haven't found a reliable source yet.
If you want to run a different architecture, export its target triple under the variable RUST_TARGET
:
export RUST_TARGET=x86_64-unknown-uefi
make qemu
If you only want to change the architecture for a single run, use the following command:
RUST_TARGET=x86_64-unknown-uefi make qemu
Tests (currently including integration and documentation tests) should be easy to run:
make test
The only target triples currently supported are:
aarch64-unknown-none
x86_64-unknown-uefi
Here's a checklist of some goals for this bootloader. Each goal is for both x86_64 and aarch64 and will only be checked off when implemented for both platforms:
- Entry point
- Panic handler
- Default text output device (uart for aarch64,
efi_text_output
for x86_64) - Default logger
- Global allocator
- Slab allocator
- Intrusive linked list
- Linked list allocator
- Out of memory handler
- Initial method of loading kernel image (embedded ELF section for aarch64 and simple file system for x86_64 UEFI)
- Elf loader
- Address mapping
- Pass data to kernel (EFI table, DTB, ACPI table, etc.)
- Construct memory map
- Start running kernel
Further goals:
- RAM disk driver
- Block device drivers
- File system drivers
Some current parts of the x86_64 bootloader utilize the uefi_services crate to accomplish the previous goals.
I plan to wean off the features of this crate by slowly re-implementing them myself. This includes the following:
- Entry point
- Panic handler
- Default text output device
- Default logger
- Global allocator
- Out of memory handler