Boot: Fix Relocation Problem + custom OS EFI loader + keep APs in Mind

[phip1611]

I have to solve the following problems all at once I think, at least keep them in mind. In the end, all of this is more or less linked together.

TL;DR: TODOs:

• When and how to start the Application Processors (APs)?
• Fix relocation problem / make Kernel fully relocatable
  • kernel should live in a high memory area, i.e. 0xffff..................)
• Framebuffer abstraction
  • glue together with a logger
  • UEFI GOP Framebuffer
  • cool font rasterization with fontdue - currently blocked by Doesn't compile with "+soft-float": Compiler LLVM Error: "Do not know how to split the result of this operator" mooman219/fontdue#98

1. The Relocation Problem

A UEFI implementation may use arbitrary memory addresses. Hence, if the kernel ELF relies on fixed virtual addresses, they may clash with the kernel and everything is broken. Therefore my proposed idea is:

1. we package the Rust kernel actually as a shared object with fully relocation support
2. instead of using GRUB + multiboot2, we provide our own OS-specific bootloader. This bootloader is an EFI application.

The EFI application can load the ELF file from disk using UEFIs functionality, allocate some memory from UEFI and load the kernel into memory at a given address. The unpacking of the LOAD is relatively easy. The relocation part probably requires that I read the GOT table from the ELF and patch some addresses inside the program code. Not sure yet, but this should be easier than one thinks.

The EFI OS loader will create a frame buffer for our OS and exit the UEFI boot services before it handoffs control to the kernel.

2. Multiple Cores, 16 bit real mode --> 32 bit protected mode --> 64 bit long mode

Once jumped into the kernel, we are in 64-bit mode with paging enabled but only for the BSP (boot strap processor). In the next step I'd like to wake up all other cores (APs - application processors). Each needs to experience a transition from 16-bit mode to 32-bit mode to 64-bit protected mode. I can't use 64-bit virtual addresses there.. Before I start implementing, I need a clear plan or some kind of prove, that my work doesn't has to be discarded in the end.

[github-actions]

This issue has become stale because it has been open for 20 days without activity.
This issue will be closed in 10 days automatically unless:

• a maintainer removes the meta/stale label or adds the stale-bot/ignore label
• new activity occurs, such as a new comment

[phip1611]

I've got new information on that: This should be the responsibility of the kernel instead of the bootloader if you want to support ACPI sleep/resume. If the CPU resumes from sleep, all APs need to be initialized again from 16 bit to 64-bit long mode.

I don't see the reason for a custom EFI loader here too. Multiboot2 should be fine and the Multiboot2 kernel can bootstrap everything.

[georglauterbach]

I've got new information on that: This should be the responsibility of the kernel instead of the bootloader if you want to support ACPI sleep/resume. If the CPU resumes from sleep, all APs need to be initialized again from 16 bit to 64-bit long mode.

I don't see the reason for a custom EFI loader here too. Multiboot2 should be fine and the Multiboot2 kernel can bootstrap everything.

The kernel code does not bother with multiboot2 anymore - this is part of the bootloader :D The kernel EFI loader is therefore solved as well. I don't want to bother with low-level boot code anymore to be honest, as this is mix of concerns (bootloader and kernel code). This should ultimately not be a problem though as the kernel should be capable of handling APs, etc. nevertheless, right?

[phip1611]

This should ultimately not be a problem though as the kernel should be capable of handling APs, etc. nevertheless, right?

Yes, correct. The ultimate solution would be to have a bootable kernel that boots as an EFI application or via Multiboot2 or via legacy boot to support every possible x86_64 machine :D

However, this is complicated. I still have only few time left to work on this. However, once I have a working example that starts all APs, I think this is more or less easily portable... independent from the bootloader.

[phip1611]

I have some ideas and hopefully I can work on this issue soon in my own OS project. If I have anything that works, I write down the relevant pointers here. Until then, I unassigned me for now to clean up what's important in the next weeks.

[georglauterbach]

I am currently working on a re-implementation, for RISC-V only at the moment. Hence, I will close this as x86 is not a priority anymore. Feel free to fork the current state; it will take some time before I can merge my current work into master :)