A small operating system kernel, written from scratch, that runs several programs at once on an ARM processor.
It boots on a real BeagleBone Black board or in the QEMU emulator, takes turns between programs on a timer, keeps them out of each other's memory, and survives when one of them crashes.

_{A real boot in QEMU. Blue lines come from the OS process, green from the user programs, grey lines are the kernel logging every switch, and orange is a program crashing on purpose while the rest keep running.}

• Several programs, one processor. A timer interrupts the running program at a fixed interval and the kernel hands the processor to the next one in line (round-robin scheduling). A program can also give up its turn early.
• Programs can't touch each other. Each one lives in its own 1 MB slice of memory, and the processor's memory-protection unit blocks any access outside it.
• A controlled way in. Programs ask the kernel for things (write text, give up the CPU, exit) through system calls, and the kernel checks every request: a bad file number or a pointer outside the program's memory is refused, not obeyed.
• Crashes stay contained. If a program faults, for example by reading memory at a misaligned address, the kernel records why, ends that program, and keeps running the others.
• Two targets. The same code builds for a VersatilePB board emulated by QEMU and for the real BeagleBone Black board (ARM Cortex-A8).
• Everything is logged. Every switch between a program and the kernel is printed with the reason, so you can watch the scheduler work.

1. Boot. The kernel starts in privileged mode, sets up the memory protection, turns off the board's watchdog, starts a hardware timer and enables interrupts.
2. Launch. It loads the OS process and the two user programs, each into its own memory slice, and switches to the first one in unprivileged user mode.
3. Take turns. Every timer tick drops back into the kernel, which saves the running program's registers, picks the next ready program, restores its registers and jumps back. To each program it looks like it never stopped.
4. Serve requests. When a program makes a system call, the kernel checks the arguments, does the work and returns a result code.
5. Handle crashes. When the processor reports a fault, the kernel identifies the kind of fault, marks that program as terminated, and moves on to the next one.

You need Linux, make, the ARM cross-compiler gcc-arm-none-eabi (13.2.1 tested) and qemu-system-arm. Tested on Ubuntu and Fedora.

make qemu         # build and boot in QEMU (VersatilePB)
make qemu-debug   # same, waiting for a debugger on port 3333
make bbb          # build for the BeagleBone Black
make clean

Connect to the board's serial console at 115200 baud (with CoolTerm, minicom or similar), then in U-Boot:

loady 0x82000000

Send build/bin/os.bin over YMODEM, then start it with go 0x82000000.

After make qemu-debug, in another terminal:

gdb-multiarch build/bin/os.elf
(gdb) target remote localhost:3333

Useful commands: layout regs, break <function>, continue.

Made by Carlos Alvarez (@23004004) and Gabriel Garcia (@GabGP). This is a fork of 23004004/001Multiprogramming.

The scheduler enforces a Round-Robin scheduling policy. It manages CPU time allocation by monitoring a quantum and handling process transitions based on three main triggers:

1. Quantum Expiry: When the quantum reaches zero, the current process is preempted to allow another process to run.
2. Process Termination: If the current process enters the PROCESS_TERMINATED state, a new process is immediately scheduled.
3. Voluntary Yield: A process can choose to give up its remaining time via the SYS_YIELD system call.

If any of these conditions are met, the scheduler moves to the next process in the ready queue and resets the quantum. When idling, the OS process will continue running.

Each process is allocated a dedicated memory region starting at a base address determined by the platform and its PID. The entry point for each process is at the beginning of its allocated 1MB region.

The PCB stores the context and metadata for each process, ensuring that the system can save and restore its state during context switches.

The kernel manages the lifecycle of each task through a set of defined states stored in the PCB.

The system uses registers R0-R3 for system call interfacing. R0 is used to pass the Syscall ID and also stores the return code upon completion.

If a process requests an unknown Syscall ID, the kernel will immediately transition the process to the PROCESS_TERMINATED state, set the return register to RC_INVALID_SYSCALL, and trigger the scheduler to pick the next available task.

If a process triggers a syscall while on kernel mode, then the same procedure as unknown system behavior follows, except that the return code is set to RC_INVALID_ORIGIN. This is because syscalls are meant to be triggered while on user mode, and if someone with kernel privileges triggers it, then it means something went wrong.

When a hardware exception or processor fault occurs, the fault_dispatcher categorizes the error and enforces a system safety policy.

Recovery Strategy

The current kernel policy is Fail-Stop for individual processes. If any fault is detected:

1. The current process is marked as PROCESS_TERMINATED.
2. The fault_type and termination_reason are recorded in the process's PCB.
3. The scheduler swaps out the current process and selects the next PROCESS_READY process.
4. The system continues running other processes.

Notes:

• Test on BeagleBone Black, otherwise the exceptions might not trigger on qemu.
• MMU faults require the MMU to be enabled and set up.