eylon-44/buzz-os

A small x86 32-bit operating system.

buzz-os's Issues

Kernel size can't be above 0x6c00 bytes/54 sectors

Problem

Currently, the kernel is being loaded as a flat binary by the bootsector at physcial address 0x1000.
The problem is that the kernel size is limited that way.

Because the BIOS loads the bootsector at 0x7c00, and the kernel is being loaded at physcial address 0x1000, we only have 0x7c00-0x1000 memory space for the kernel, i.e. 0x6c00 bytes i.e. 54 sectors.

Loading over 54 sectors will override the bootsector while it's still running, meaning the kernel won't start.

Fix

To fix, the kernel must be loaded above 0x7e00 (the end of the bootsector).
The prefered phyical address to load the kernel in is 0x100000 (1MB).

In order to do that we must load the kernel outside of Real-Mode, as it is limited to 1MB in memory.
The bootsector should switch to Protected-Mode and jump to a C script that loads the kernel at 1MB using ATA PIO.

Unable to use gdb's "ni" command in higher half kernel on call instructions

Problem

Note

This problem is debugger related only, as the program executes as intended on its own but only has issues with gdb.

After jumping to the higher half kernel (0xC0000000), when using gdb's ni (next instruction) command on a call instruction gdb seems to freeze.

This does not occur when

• I don't load the higher half kernel symbol table (add-symbol-table bin/symbols/kernel.elf 0xC0001000)
• using the n (next) on C code, or si (step instruction) commands.
• executed on a jmp instruction (not call)

Fix

Note

I am not sure exactly what is wrong with the symbol table, but even if I am lazy and won't fix this it should be fine as it does not affect the actuall kernel, only a small part of the debugging process that can be replaced with the si command.

Due to the fact that the problem won't occur when not loading the symbol table, and only happens when trying to skip a call instruction, meaning the debugger has to know where the called function starts and ends in order to be able to execute and skip it, the problem must be in the symbol table.

Assumptions

• I currently link the kernel twice, once for the kernel binary and once for the kernel ELF which I use as a symbol table. It's very possible that somewhere down that path something went wrong. I plan to load the kernel as an ELF and not binary in the future, it may solve it becuse there is really no reason for it to mess up if it uses the same ELF both for execute an debugging.