Open rain-1 opened 6 years ago
Turns out the "random advice" on IRC wasn't completely random, although I hadn't seen this issue then. But, yes, I think the bootloader should put the CPU in 64-bit mode before starting the kernel. For 32-bit CPUs, the bootloader should still enable paging.
This makes the kernel less messy (which is especially useful in a microkernel), while it allows greater flexibility as far as allocating physical addresses in the bootloader is concerned. https://wiki.osdev.org/Bare_Bones suggests loading the kernel at physical 1MiB, which usually does work (unless there isn't any usable memory there, where you have no choice but to abort booting). Furthermore, enabling paging in the bootloader allows the bootloader to already map the kernel in higher half without being concerned about the physical addresses (although it will need to mark them as allocated so the kernel's physical memory manager doesn't use them).
But I suggest starting from supporting a narrow range of configurations, then expand it. For example, starting with just a 32-bit BIOS CD bootloader may be more manageable and probably sufficient initially, there is no OS installer yet so booting from hard drives is not needed or even useful at this point. Then, we can expand to 64-bit, then UEFI (we will need to support it for newer machines), but only after we get some initial kernel running. Then, when preparing to write an OS installer, doing a hard drive bootloader will be in order.
So, to sum up: let's start from a bootloader for a single configuration that just prepares the execution environment appropriately for the kernel and executes it. Then, whatever the kernel needs from the bootloader can be added later.
EDIT: Is there something I could work on?
thanks for the great comment. I think this a good plan, what would be useful now is either porting the nasm code to gnu assembly or adding a piece at a time to the gist, for example GDT.
could the bootloader put us into 64 bit mode?