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. 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.
↫ Tilck GitHub page
Tilck implements about 100 Linux syscalls, and is not focused on replacing the Linux kernel or even becoming a generic desktop or server operating system. It supports both i686 and RISC-V, has support for FAT, and a whole slew of other features. It can run a number of console and even a few framebuffer applications, but don’t expect things like X11 to work, or to ever work.
I was really excited to see more RISC-V support, until I saw this:
Just like “Linux on ARM”, the architecture is locked out by SoC designers, and open source support is on a case by case basis.
This is why, to this day, that “archaic” x86 is still the king. Especially for open source projects (Linux, BSD*, Haiku, MenuetOS, FreeDOS, ReactOS, Android, …) primarily still support this platform.
@sukru
Yes and no. The situation on RISC-V is already far better than ARM.
The issue is more drivers than anything. Even on X86, hardware support does not appear by magic. The article that says the RISC-V version of Tilck does not even support keyboards. You cannot just boot Linux on any x86 hardware either if drivers for the hardware do not exist.
On RISC-V, there is OpenSBI which can be thought of as a lighter-weight UEFI–a minimal firmware if you will. OpenSBI simplifies the boot process and abstracts away many low-level hardware complexities. OpenSBI is Open Source and portable across RISC-V hardware so quite a bit better than the binary blob situation on ARM. You will see that Tilck uses OpenSBI already. For example, it uses OpenSBI to make the same UART calls to both the Sipheed and QEMU.
That said, the other thing that makes x86 work “universally” is ACPI. This is generally not used on RISC-V. Instead, RISC-V favours “device trees”. A device tree is a data structure that describes what hardware is available in a system. It is passed to the kernel at boot time so the kernel can load the right drivers. In the RISC-V world, device trees are seen as an advantage as they are much lighter and simpler than ACPI and there are only a handful of RISC-V devices. But device trees are static and have to be added for each device type (eg. SBC) before that hardware can be supported. You can think of ACPI as something that dynamically builds a device tree at boot time before the kernel takes over (not literally what it is doing but it is the right mental model).
It is not hard to add device trees for new hardware if drivers exist, so this is not much of a roadblock in practice. The real issue with any given RISC-V platform is going to be drivers.
Someday, when there are thousands of distinct RISC-V computer models that are all built from common components (like the X86 world today) RISC-V will need something like ACPI. I would expect it to come eventually (hopefully something much simpler). This will also be required for “hot plugging” hardware. But it is not really a huge issue for now and the RISC-V situation is already way better than ARM due to the adoption of OpenSBI.
Does OpenSBI have broad SBC RISC-V usage? Or is it an aspirational open like Coreboot project, where basically no board maker uses them for the official UEFI/BIOS, rather than using one of the commercial ones. Because if a lot of the SBC/future server platforms don’t use _something_ like UEFI/OpenSBI broadly, it’ll just end up back to the way ARM is these days.
@Dirzzt321
Yes, OpenSBI is widely adopted in the RISC-V world. It is used by SiFive, StarFive, ROMA, Beagle, Milk, Lichee, and (I guess) Sipheed.
I think you need OpenSBI to run the Fedora, Debian, Chimera, and Ubuntu RISC-V distros.
(Open)SBI is basically RISCV “ABI” and interface needed if you develop kernel (you need to for stuff like TLB flush or interprocessor interrupts), however it’s not even remotely BIOS, which provided disk access, keyboard or video. RISCV (or ARM) doesn’t even have concept of keyboard like PCs do. There is no keyboard, no display, no storage and nothing is supported by default. At most you can get serial debug console (via SBI) and that’s it. For anything more “advanced”, you need to implement full USB HID stack (if you need keyboard input), pretty much like Linux kernel or Windows do.
I doubt RISCV is any better that ARM. It only abstracts very basic stuff, which is far from anything like PC. RISCV is infested with the same nonsense as ARM (RISCV SoCs vendors just replace ARM core with RISC many times). Nothing is standarized anywhere and you need same amount of work to port kernel to hardware like on ARM.
@pikaczex
You are still going to need drivers for many things. I said that.
I agree, a PC BIOS does more than OpenSBI does (though also less in other ways). Does that mean that “both ARM and RISC-V suck equally for portability” is a good summary? Not in my view.
OpenSBI abstracts many hardware details, enabling operating systems to start up on different RISC-V platforms without modification (e.g., timer management, IPI handling, CSR access, UART drivers, IRQ controllers, PMP setup, etc). OpenSBI libraries abstract things like memory management and power management.
Tilck, for example, can use sbi_console_putchar and sbi_console_getchar to run identical input / output code that works on both the Sipheed board and in QEMU. OpenSBI includes drivers for common UART hardware, like emulated in QEMU or found in SiFive boards (different than what QEMU emulates). For more exotic hardware, you may have to provide drivers.
OpenSBI provides a standardized boot process including parsing of device trees and passing hardware details to the kernel (supervisor).
Does OpenSBI contain keyboard drivers? No. You do not need a keyboard to boot. In fact, most RISC-V device do not even have one.
Porting Fedora to a new RISC-V SoC is a lot less work than porting it to most new ARM platforms thanks to OpenSBI. There are similar standards in ARM but they are not widely adopted with every vendor doing things differently. The culture on RISC-V is to use OpenSBI. So the situation on RISC-V is better than on ARM. That is the only point I was trying to make originally.
Does that mean that I do not have to provide USB drivers for my RISC-V SoC? No, it does not mean that. That said, Linux does not rely on BIOS or UEFI to manage USB on PC either.
I cannot create an operating system like DOS that is widely portable across RISC-V hardware without drivers. That is true.
On x86, I can boot modern hardware and talk to it like it was an IBM PC from 1981. On x86, the (very complicated UEFI and ACPI) system dynamically discovers installed hardware and allows me to control much of it generically without HW specific drivers. That is not what OpenSBI does.
OpenSBI does include some drivers for some hardware (like the UART emulated in QEMU). OpenSBI is a set of standards to provide a common API that removes the need for the operating system to directly access many kinds of hardware. It provides a standardized boot process, a well-defined way of describing hardware and passing that information to the OS, and an API for many low-level hardware operations. That all makes it a lot easier to start a kernel that can then load the drivers I need.
Nobody said that OpenSBI or RISC-V provides all the capabilities found on x86. What I said is that the OS portability situation on RISC-V is quite a bit better than it is on ARM. And it is.
LeFantome,
I had written kernels for x86, and all you needed was to dump 512 bytes in a boot sector. For hardware support, you could start with legacy (0x60 for the keyboard controller port, 0xB800 for video RAM, VESA APIs for changing modes, INT0-INT10 for low level access) that would get you working.
As you said, the BIOS (and later EFI) handles most of the complexities of discovering devices, and booting the system. You are basically given a pretty standard environment.
(Today modern ones will even handle USB, PCIe, nvme and other devices making it run like 1980s!)
And when you needed to go fancy, you’d just discover how much RAM is out there, the mapping tables, and then set up protected memory descriptors (and “page tables” if you are fancy) and you’d have access to full 32 bit mode.
Anyway… too much nostalgia.
sukru,
Ralph brown interrupt list for the win 🙂
The IBM PC standard made it relatively easy to write your own bootloader and OS and have it work across nearly every x86 computer. You may not have all the drivers, but at least you should be able to boot into the kernel, perform basic IO including keyboard and graphics, and detect all the hardware via plug and play. I wish it were just as easy on ARM, instead everything’s gotten worse for DIY.
Assembly programing is obsolete, although I really enjoyed it. My most recent assembly project was about a decade ago writing a remote PC TSR for DOS for a company that didn’t want to rewrite their software but needed to be able to access it remotely.