- Improved the run bash script to exit when an error occurs in one of the sub tasks
- Wrote basic FAT16 functions that should give enough information to properly implement the rest of the driver
- FAT structure namings are now in accordence with the microsoft spec of March 2005
- Added boot device info parsing to the kernel
- Added a pointer in the kernel to our pre-kernel BootInfo structure
- Created a layout for the FAT driver
- Created a layout for the virtual filesystem
- Separated IDE driver from the basic atapio driver.
This will ensure we are not using one or the other
- The create_harddrive shell script will now actually build a harddrive image of
the kernel
- The virtual filesystem initializes and creates a filesystem structure
for every FAT16 partition in the master boot record
Problem:
As our kernel grows we need more complex datastructures and functions these would come from
the standard C/C++ library with normal programs.
The kernel is a freestanding programme and has no access to standard libraries.
Solution:
We build a mini version of the standard C/C++ library which will contain the
datastructures and functions we want. This library can then be statically linked
into our kernel binary.
Making it a statically linked library also gives more structure to the project.
Keeping these random functions and datastructures in the kernel just clutters the
kernel source code with less relevant source code.
- The algorithm will work once I am of better mind to deal with
raw C strings
- The resolution should look at each entry divided by '/'.
if the entry is not there then we can quit early, however for
now I am mostly concerned with getting the names of directory entries
we would need to look for.
- The FAT command is no longer available
- At Startup the FileSystem initialise funciton
is called, it should execute the same code as the FAT command did.
- ACPI::initialise is commented out because it causes a Exception
- Updated gdt assembly
- Updated Interrupt service request handlers
- Improved virtual memory manager
- NOTE: we're dependent on identity mappings for the heap to work
- Created a scripts folder
- Written instructions on how to create the disk image
- Working on a python build script that executes all other scripts
The scripts folder should contain scripts to build a full installation of
our operating system. Scripts like creating a filesystem should be found here
Folders now are alll lower case
Started working on the implementation of the Virtual memory manager. Implemented allocate and free page funtionality for as far as I can atm.
Implemented the
Keyboard.h: remove the incorrect use of typedef
PhysicalMemoryManager.cpp:
Map the Bios region as used. This prevents us from allocation the area used by the bios
The first stage after GRUB will be Pre-Kernel. This stage will organize the
information we receive from the bootloader. (in our case that will be grub)
The second stage is for now called early_main. The program will at this
point already be running in virtual higher-half / higher-quarter address space.
The goal of the second stage is to set up the kernel in such a way that we are
ready to jump in to usermode.
The third stage is for now called kernel_main. This stage will jump us into
usermode and load the startup programs.
- Added a GRUB entry for tests
- Started writing the pre-kernel stage
- Removed knowledge of multiboot from early_main
- Edited the linkerscript to link variables in pre-kernel to
lower address space. ( from 1MB and up)
* Added symbol files to .gitignore
* Improved text in #PG and #GP handlers
* Added the printing of the multiboot structure address and the magic value
* Added page fault screenshot to readme
We now can launch the kernel at 0xC0000000 (or 3 GiB mark) with paging enabled.
A lot of early main is currently not executed to keep debugging as simple as possible
during the initial testing of higher half kernel loading.
A lot of the implementation is straight from wiki.osdev.org/Higher_Half_x86_Bare_Bones. Thanks to all the folks
who keep that wiki updated, its really resourceful.
- Made a special assembly file to put CPU check function in. E.G. functions to get the state of
specific registers
In this case I have created a simple assembly function to get the contents of the CR0 register.
With the help of the c++ preprocessor the value can then be used to check if certains bits are set.
For example to check if the PG (paging) bit is set, indicating that paging is enabled for the
processor.
