Phase 9 - GCC-Built BIOS / Serial Monitor

Context

This phase turns the GCC bring-up work into a persistent interactive firmware. The CPU boots into a small monitor instead of a one-off test program.

Goals

Build a freestanding C/assembly BIOS with its own linker script and startup code.
Provide a UART command prompt.
Add simple commands for memory inspection, loading, and jumping to test payloads.

New Concepts

Monitor: small firmware that lets you inspect and control a machine interactively.
Command parser: text interface that maps typed commands to firmware functions.
Firmware ABI: the calling convention and data contract between loaded code and BIOS.
Executable RAM window: memory that software can write and the fetch path can execute.

How To Think About It

The BIOS is both a milestone and a tool. Keep it boring and reliable: UART in, UART out, explicit commands, clear error messages, and no hidden dependencies on host tooling.

Learning Tasks

Decide where UART-loaded code can live and how the I-bus fetches it.
Define a tiny BIOS call table for console I/O and returning to the monitor.
Write down the exact register state expected by run <addr>.
Add commands one at a time and test each on hardware.

Pitfalls

Loading code into data memory that the instruction fetch path cannot see.
Letting a failed command corrupt the monitor's own stack or globals.
Building a clever shell before the load/run/debug basics work.

Tooling And Testing

Test the monitor in simulation with scripted UART input where practical.
Use a terminal program that can send raw files without changing line endings.
Keep a known-good tiny payload that prints one line and returns to the monitor.

References

RISC-V ELF psABI: https://github.com/riscv-non-isa/riscv-elf-psabi-doc
GNU linker scripts: https://sourceware.org/binutils/docs/ld/Scripts.html
OSDev bare bones background: https://wiki.osdev.org/Bare_Bones

1.9 KiB Raw Blame History