Greetings everyone!
The migration to the bootboot protocol is almost complete! Over this winter break, I established my goals to be able to run my operating system on real hardware and study the next steps for this Fellows project. While most of the time in December was dedicated to college applications, I had a great amount of time to rework the project architecture (again) and to configure the development pipeline to allow for bootboot! Achievement 1: 64bit The operating system is officially 64 bit! A 64bit system means that memory addresses and data stores at each memory address takes up 64 bits of data rather than 32 bits. This is what every modern operating system is at. A lot of the internal functionality like setting up the GDT and IDT had to be changed. This is because the processor handles the setup of these very low level structure differently between setting up a new one (previous) and rewriting it (current). More work will have to be done in order to correct these procedures. Achievement 2: Bootboot support Makefile This is where I get to talk about what bootboot actually is. When a processor starts up, it traditionally hands it off directly to the bootloader, stored at the first memory location of the disk. The bootloader performs sanity checks and makes sure the hardware and software environment is ready to be passed off to the kernel. This is where the GDT is 32 bit protected mode is set up, as well as small things like checking cpuid and setting the A20 line which we won't get into. Modern technologies prefer to use a system called UEFI (Unified Extensible Firmware Interface). Intel even declared all their processors released 2020 and beyond would only support UEFI rather than the legacy protocol. UEFI is a standardized way of booting* and provides an API to use so that kernels can be more agnostic to their system. It's also more secure and guarantees a GPT Partitioning system as opposed to the old MBR system. This leads to certain benefits we won't get into. Anyways, setting up UEFI manually is hard. An there's too many datasheets and documentation I'm reading already to try to learn this. This is why I'm using bootboot. It will setup UEFI for me and serve as a wrapper that jumps immediately to my kernel, handing off control in a very similar way to my old bootloader. With this, I can run on real hardware. Currently it's working but I need to sort out an issue with how the kernel decodes screen addressing before I can post an image of the kernel before the migration. It was very simple to make the switch. Due to my forward-thinking and modular approach to my refactored Makefile I referenced in an earlier blogpost, I just had to change the final stages of kernel preparation, shipping it off to the bootboot toolchain to prep it. After configurating my emulation software to resemble exactly the state of a real drive, it blitted the test frame. Soon, we will see this in all its glory. A windowing system was added so when I get this on a real USB drive and boot it on the Severn Cyber Club PC, I will show an image and elaborate more on future goals. *kind of Stay tuned!
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. Archives
November 2022
Categories |