tilck

What \ Arch | i386 | riscv64 | x86_64 (build) --------------------|----------------------|--------------|------------------ Tests | [](https://github.com/vvaltchev/tilck/actions/workflows/ci-i386.yml) | [](https://github.com/vvaltchev/tilck/actions/workflows/ci-riscv64.yml) | [](https://github.com/vvaltchev/tilck/actions/workflows/ci-x86_64.yml) Toolchain debian | [](https://github.com/vvaltchev/tilck/actions/workflows/ci-tc-debian-i386.yml) | [](https://github.com/vvaltchev/tilck/actions/workflows/ci-tc-debian-riscv64.yml) | N/A Toolchain fedora | [](https://github.com/vvaltchev/tilck/actions/workflows/ci-tc-fedora-i386.yml) | [](https://github.com/vvaltchev/tilck/actions/workflows/ci-tc-fedora-riscv64.yml) | N/A Toolchain archlinux | [](https://github.com/vvaltchev/tilck/actions/workflows/ci-tc-arch-i386.yml) | [](https://github.com/vvaltchev/tilck/actions/workflows/ci-tc-arch-riscv64.yml) | N/A [](https://opensource.org/licenses/BSD-2-Clause) Contents ---------------------------------------- * [Overview](#overview) - [What is Tilck?](#what-is-tilck) * [Future plans](#future-plans) - [What Tilck is NOT ?](#what-tilck-is-not-) * [Tilck vs Linux](#tilck-vs-linux) * [Features](#features) - [i686 support](#i686-support) - [riscv64 support](#riscv64-support) - [File systems](#file-systems) - [Processes and signals](#processes-and-signals) - [I/O](#io) - [Console](#console) - [Userspace applications](#userspace-applications) * [Booting Tilck](#booting-tilck) - [Tilck's bootloader](#tilcks-bootloader) - [3rd-party bootloaders](#3rd-party-bootloaders) * [Grub support](#grub-support) * [Documentation and HOWTOs](#documentation-and-howtos) - [Building Tilck](#building-tilck) - [Testing Tilck](#testing-tilck) - [Debugging Tilck](#debugging-tilck) * [Tilck's debug panel](#tilcks-debug-panel) * [A comment about user experience](#a-comment-about-user-experience) * [FAQ](#faq) Overview ----------------------------------------

### What is Tilck? `Tilck` is an educational *monolithic* kernel designed to be Linux-compatible at binary level. It runs on i686 and RISCV64 at the moment. Project's small-scale and simple design makes it the **perfect playground** for playing in kernel mode while retaining the ability to compare how the *very same* *usermode bits* run on the Linux kernel as well. That's a **rare feature** in the realm of educational kernels. Because of that, building a program for Tilck requires just a `gcc-musl` toolchain from [bootlin.com](https://toolchains.bootlin.com). Tilck has **no need** to have its own set of custom written applications, like most educational kernels do. It just runs mainstream Linux programs like the **BusyBox** suite. While the Linux-compatibility and the monolithic design might seem a limitation from the OS research point of view, on the other side, such design bring the whole project much closer to *real-world* applications in the future, compared to the case where some serious (or huge) effort is required to port pre-existing software on it. Also, nothing stops Tilck from implementing custom non-Linux syscalls that aware apps might take advantage of. #### Future plans In the long term, `Tilck` might become widespread for **embedded systems** on which a fully deterministic and ultra low-latency system is required. With a fair amount of luck, `Tilck` might be able to fill the gap between *Embedded Linux* and typical real-time operating systems like *FreeRTOS* or *Zephyr*. The kernel already runs on RISCV64 and at some point it will be ported to the `ARM` family. It might be adapted to run on MMU-less CPUs as well. Tilck would be a perfect fit for such use cases because consuming a tiny amount of RAM has always been a key point in Tilck's design. Indeed, the kernel can boot and run on a QEMU machine with just 3 MB of memory *today*. In addition to that, adding a basic support for networking and storage is part of the plans even if details have not been defined yet. Networking support might be limited to UDP + IP (at least at the beginning) and usable on a limited set of network cards. The same applies for storage: not all kinds of block devices will be supported, and a few filesystems (maybe just fat32 and ext2) will implemented in the kernel. The support for FUSE filesystems will be considered. One major milestone for the project will be to support both networking and storage for a specific SoC like Raspberry Pi 3 (or 4) but that could possibly happen only after Tilck has been ported to ARM64. ### What Tilck is NOT ? * An attempt to re-write and/or replace the Linux kernel. Tilck is a completely different kernel that has a *partial* compatibility with Linux just in order to take advantage of its programs and toolchains. Also, that helps a lot to validate its correctness: if a program works correctly on Linux, it must work the same way on Tilck as well (minus not-implemented features). **But**, having a fair amount of Linux programs working on it, is just a *starting point*: with time, Tilck will evolve in a different way and it will have its own unique set of features as well. * A kernel suitable for a *desktop* operating system. No X server works on Tilck, not only because a considerable amount of extra features will be required for that, but because working in that direction is *completely outside* of project's goals. See also: https://github.com/vvaltchev/tilck/discussions/81 #### Tilck vs Linux Tilck is fundamentally different from Linux as it **does not** aim to target multi-user server nor desktop machines, at all because that would be pointless: Linux is **not** big & complex because of a *poor* implementation, but because of the incredible amount of features it offers and the *intrinsic* complexity they require. In other words, **Linux is great** given the problem it solves. Tilck will offer *fewer* features in exchange for: - simpler code (by far) - smaller binary size - extremely deterministic behavior - ultra low-latency - easier development & testing - extra robustness In conclusion, while this is still an *educational* project at the moment, it has been written keeping in mind those goals and it has a test infrastructure that ambitiously tries to be almost *enterprise-level* (see [Testing](#testing-tilck)). Features ---------------------------------------- Tilck is a preemptable monolithic *NIX kernel, implementing about ~100 Linux syscalls. At its core, the kernel is not x86-centric even if that was its first target architecture. Almost everything arch-specific is isolated. Because of that, most of kernel's code is not arch-specific and can be already compiled for any architecture to run as part of the unit tests. #### i686 support While the kernel uses a fair amount of **legacy hardware** like the 8259 PICs for IRQs, the legacy 8254 PIT for the system timer, the legacy 16550 UART for serial communication, the 8042 kb controller, the 8237 ISA DMA, and the Sound Blaster 16 sound card (QEMU only), it has also support for some **recent hardware** features like SSE, AVX and AVX2 fpu instructions, PAT, i686 sysenter, enumeration of PCI Express devices (via ECAM) and, above all, **ACPI** support via ACPICA. ACPI is currently used to receive power-button events, to reboot or power-off the machine, and to read the current parameters of machine's batteries (when implemented via ACPI control methods). ##### Running on physical x86 hardware The operating system has been regularly tested on physical hardware from its inception by booting it with an USB stick (see the notes below). Test machines include actual i686 machines, older x86_64 machines with BIOS-only firmware, newer x86_64 machines with UEFI+CSM and finally super-recent pure-UEFI machines. For a long time, Tilck's development strictly complied with the following rule: *if you cannot test it on real hardware, do not implement it in Tilck*. Only recently, that rule has been relaxed a little in order to play with SB16. It is possible that, in the future, there might be a few other drivers that would be tested only on virtual machines: their development is justified by the educational value it will bring to the operating system and the infrastructure built for them will be reused for other drivers of the same kind. **But** that will *never* become a common practice. Tilck is designed to work on real hardware, where any kind of weird things happen. Being reliable there is *critical* for Tilck's success. #### riscv64 support Tilck's support for the riscv64 architecture mainly focuses on embedded applications. Tilck runs in RV64 supervisor mode (Smode), uses SV39 three-level page table virtual memory, and supports user space floating point. ##### riscv64 hardware peripheral support The riscv64 architecture adopts a device tree-based driver model and in Tilck and all hardware information is obtained from the device tree transmitted by the bootloader. Therefore, Tilck's riscv kernel code does not have any board-level description code. The system timer (for ticks) invokes the SBI monitor program (openSBI) through RISCV SBI interface instead of implementing a driver in the kernel. The system RTC clock is implemented using a very simple goldfish virtual RTC driver, which works only on the QEMU virtual platform. Tilck on RISCV does *not* implement typical PC peripherals such as keyboards: for both input and output serial ports have to be used (which is enough for most embedded applications). The most common `ns16550` UART driver has been implemented. To better manage the multi-level nested interrupt architecture common in embedded chips, Tilck on RISCV implements a simplified framework similar to the idea of Linux IRQ domains. The most common INTC and PLIC interrupt controller drivers are supported. ##### board support Tilck on RISCV64 implements a very simple BSP framework, which can be managed by setting environment variable `BOARD` to build a image of the corresponding board. Currently, Tilck supports only the [Sipeed licheerv-nano] board and the qemu-virt virtual board (set by default). QEMU-virt has the framebuffer mode enabled by default, while having FB support on `licheerv-nano` requires patching the original bootloader provided by Sipeed. [Sipeed licheerv-nano]: https://wiki.sipeed.com/hardware/en/lichee/RV_Nano/1_intro.html #### File systems Tilck has a simple but full-featured (both soft and hard links, file holes, memory mapping, etc.) **ramfs** implementation, a minimalistic **devfs** implementation, read-only support for FAT16 and **FAT32** (used for initrd) allowing memory-mapping of files, and a **sysfs** implementation used to provide a full view of **ACPI's** **namespace**, the list of all PCI(e) devices and Tilck's compile-time configuration. Clearly, in order to work with multiple file systems at once, Tilck has a simple **VFS** implementation as well. **Note**: there is no support for block devices in Tilck yet, so everything is in-memory. #### Processes and signals While Tilck uses internally the concept of thread, multi-threading is not currently exposed to userspace (kernel threads exist, of course). Both `fork()` and `vfork()` are properly implemented and copy-on-write is used for fork-ed processes. The `waitpid()` syscall is fully implemented (which implies process groups etc.). The support for POSIX signals is partial: custom signal handlers are supported using the `rt_sigaction()` interface, but most of the SA_* flags are not supported and handlers cannot interrupt each other, yet. `rt_sigprocmask()`, `sys_rt_sigpending()`, `sys_rt_sigsuspend()` work as expected, as well as special signals like SIGSTOP, SIGCONT and SIGCHLD. For more details, see the [syscalls] document. One interesting feature in this area deserves a special mentio