Makefile Woes
One of the beauties of writing code is that for every one hour spent coding, two are spent debugging and refactoring. Most of this week was spent refactoring and learning the tricks of Makefile, a tool that lets you automate large build projects with a declarative language style. It took me a lot of time figuring out how my project architecture was going to be shaped and how I should manage the compilation for each core part of my OS. Initially there was one Makefile in the top level of my project directory that managed everything. I saw eventually that when adding global constructors I will have to migrate my kernel code to its own directory. This will house the terminal driver, basic VGA graphics driver, and other includes. I also started building out my standard library, creating a folder called libc. This housed the basic functionality like string manipulation, math, and font handling. Fonts Speaking of font handling, I had recently transitioned to using VGA 320x200 256 color graphics. Contrasted from the previous video mode, I can modify individual pixels and their colors, rather than using the builtin text mode. This only required switching my BIOS interrupt call in my bootloader, but I had to make many changes in order to get back to where I was before. I now had to create my own font and write a driver that could display pixels and draw characters. Since I haven’t made much development in my math.h library, I decided to use 8x8 bitmap fonts rather than vector fonts that I’ll have to write a rasterizer for. I implemented the capital letters A, B, C, D, E and I have a working bitmap font renderer. This will definitely need to be altered and refactored as time goes on since I’m still in the very early stages of development and writing a complete graphics driver will span the entire year. I’m working to implement the rest of the letters and hopefully set out on the next steps. One problem I did encounter, however, was mapping. I couldn’t assign a const variable to every ascii character for a variety of reasons
Circling back to Makefile, after I made a Makefile for each core component of my OS, I changed my mind. Now I have a central (more organized) Makefile for my project and the toolchain development timeline is more clear. Moving Forward These will likely be my immediate next steps
I’ll also need to figure out what LICENSE file to use when I inevitable upload this as a git repository to GitHub. I’ll need to talk to my mentors more about that. I’m also still working on gathering all my mentors. I also soon plan to start researching the EE side for parts to include in my device.
0 Comments
The Website After the Fellows Leadership Lab, I finished my Fellows Weebly website and included the necessary pages and elements. Working with the website posed a few challenges since I wasn’t used to the user interface and had to fiddle around with the settings to format the website correctly. I will make plans to revamp my website’s appearance and structure once I have more content to add. I also decided on a name for my OS, Lambda OS. This might change in the future, but the reason I chose lambda is because it represents the lambda calculus, and I'll be using the functional programming paradigm in my shell scripting language. The Operating System I immediately began work on my operating system. Before I submitted my proposal, I had already started researching what goes into an operating system and what specifications I wanted. Using the code I wrote when I was following some tutorials I started a clean new project in my GitHub folder. I made the choice not to initialize my repository yet, meaning I didn’t run git init or set my origin remote to GitHub. My examples and testing repository are on a private repository, however, to consult or to create code stubs. I already had my basic developer environment with vscode, qemu, nasm, so it was time to start programming. Vscode is my text editor in which I’ll write my code. I installed many extensions that improve my workflow and make testing much easier. Because I don’t have access to real hardware yet, and it would be a pain to have to constantly upload my code whenever I want to test, I’m using QEMU, a virtual machine that can emulate an x86 system. Nasm is the assembly processor that can take my assembly code and spit out a binary executable. I reused my BIOS Legacy Boot Code to start the program in 16 Bit Real Mode. I initialized the basic tasks.
The next step was to create my cross-compiler. Here is an article that goes more in-depth behind why I need a cross-compiler, but in short this allows me to write c code that can target my OS’s system architecture. After building my cross compiler (which took a few hours of processing), I was able to write my actual kernel code in C. After setting up my kernel_entry and linker scripts, I was able to interface between C and ASM. My final advancement I made before this post was implementing a simple puts function to print my string, since I had no standard library. UEFI vs Legacy Boot This may or may not become a problem down the line, but I chose to roll my own custom bootloader, stucking with the legacy BIOS boot method. This is an older method that dates back when computers weren’t as standardized, and allows me to take control of the computer right right after it POSTs (Power-On Self Test). Although this grants me more control, it also forces me to implement nearly everything myself, which I think will be an important learning process. This is in contrast to UEFI (Unified Extensible Firmware Interface), which is a standardized boot protocol that is included in every modern computer. This is a really powerful tool, especially when I use POSIX-UEFI which automatically sets me up to have a POSIX-compliant operating system down the line. The reason I forwent this is because giving away control of the implementation would defeat the purpose of my Fellows Project: to examine exactly what goes into an operating system with the layers of abstraction. This could pose a problem, however. Intel, the biggest supplier of x86 processors, stated that they would remove legacy boot support from their CPUs that launch after 2020 and only support UEFI 3. This could interfere with my plans to put my operating system on real hardware, since I want to avoid UEFI as much as possible. This will require more research into whether I should continue rolling my own bootloader or switch to a bootloader like GRUB-multiboot, BOOTBOOT, or Limine. Mentors and Going Forward This project is a huge undertaking, not even mentioning the EE (electrical engineering) side of the project. I am currently working with Ms. Campion, the Alumni Director to find mentors that have experience in Embedded Systems, Computer Science, and EE. I have a small list and I’m working on writing emails to all of them. Moving forward, I plan to start talking with Mr. Baraty, my on-campus mentor, to figure out the hardware specifications and blueprints of my device. I also plan to do more research into the BIOS vs UEFI problem. For the kernel, this is the list of tasks I’m going to start chipping away at.
|
AuthorWrite something about yourself. No need to be fancy, just an overview. Archives
November 2022
Categories |