# 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