Author: admin

This post is just a recap of the system’s main features and current progress.

Core Kernel Features

Scheduler, memory management, program loading and system calls are all working well for now but will need some improvements over time.

Some advanced features like multithreading, priorities and CPU affinity have been implemented but not yet thoroughly pressure tested.

Architecture Support

The kernel & tools are highly specialised for RISC-V platforms, this importantly means that not a lot of “bloat” is needed to support legacy architectures.

Testing has mostly been done on the latest Chinese hardware designs, especially SpacemiT chips.

Filesystem

The filesystem received a lot of work early on and the current codebase supports three filesystem versions:

• xv6 style filesystem (“version 0”)
• Improved version (“version 1”)
• Extensible 64-bit filesystem (“version 2”)

The system does not have any support for reading or writing Linux/Mac/Windows disks at this stage and this probably won’t be a high priority compared to improving the native filesystem.

A freshly rewritten mkfs program is included so systems can be easily built based on this code.

The filesystem layout supports additional metadata but this hasn’t been exposed in APIs yet.

Networking

The networking support is relatively new and still needs some work.

The network stack is based on microps (not based on an in-house design and not based on LWIP like many other small operating systems). I’m really happy with this codebase but my port isn’t the fastest (drivers are a bit laggy) and it will need some extensions or a replacement over time (e.g. only supports legacy protocols, no IPv6).

Performance improvements are underway including a kqueue implementation suitable for server programs (as well as driver improvements), these will be addressed in upcoming releases. IPv6 support, wireless protocols and other things will be left for a release some time further in the future.

Graphics & GUI

This support is only just starting to come online and isn’t fully functional yet, but simple graphical apps will be supported in an upcoming releases.

Userland Infrastructure

Most basic command line functionality is already there.

My libc implementation is working well enough, and my compiler backend mostly works (but GCC is used for most builds again for now, just to focus on getting other things working). Getting the compiler to run properly on the new OS will take a little more backend work (finishing the linker etc.).

Other tools like a package manager have been written but haven’t been fully integrated.

It looks like almost everything is working now, aside from some plumbing for GUI apps.

Expected showstopping problems in the short term will probably be limited to some driver performance issues and a lack of drivers for USB peripherals and other things .

There don’t seem to be major architectural issues remaining aside from lacking some internal infrastructure for timers & interrupts & more advanced drivers, this means most drivers will be running in a polling loop without any more advanced/efficient wakeups for now but this will improve as the features stabilise.

My initial 1.0.x releases were very minimal and progress has since pushed the versions past 1.1 (adding basic networking support) without having time to do a proper interim release.

As such my current aim is to prepare a 1.2 release which should have most features of a general purpose OS but with some limitations or design issues remaining. The 1.2 release should be like a preview of a 2.0 release (but without cleanups, optimisations, apps etc.).

This will probably involve settling the releases down into a few builds:

• Developer edition – boots from SBI, runs on RVVM (with desktop)
• Server edition – boots from xv6-based entry code, runs on QEMU or compatible (no desktop)
• Experimental edition – boots from uboot, runs on real hardware but with limited drivers

These builds will mostly be similar apart from different kernel configurations intended to make booting easier, so these builds may be interchangeable between different devices but that will just depend on how tolerant the hardware ends up being and on whether specific fixes are needed for some devices that will break others.

Timeframe for a 1.2 release will be around a month, give or take depending how smoothly the work goes.

NOTE: Desktop support will be very limited at first so don’t expect full apps at this stage. After all the basics are working I should be able to start porting X11 type desktop software, so eventually it should be a full featured system.

Basic screen & mouse support is working while other devices on RVVM targets should soon be more functional, meaning the kernel should be able to start running desktop style programs very soon (but APIs & ports will take a while).

Following some early success with the port to RVVM emulator target I kept going and now have nearly enough hardware working:

• Framebuffer & RTC are now configured at boot time from the device tree blob (when available)
• The network stack (previously ported to the kernel for reading on QEMU) now appears to start correctly on RVVM but without ethernet drivers at this stage
• The OpenCores interface for I2C is partly operational/partly configured
• First contact has been made with the (virtualised) input devices over I2C, but haven’t finished drivers for those yet

In summary this means a GUI demo will soon be feasible but I haven’t figured out a plan for one yet aside from finishing the graphics & input drivers.

Disk, audio etc. could present further problems for this port but RVVM appears to be a good platform for this stage of driver development.

I’ve had a few connectivity problems with my complicated hardware test setup from last year so I’m going back to basics now with more support for emulated devices, while also continuing with support for device trees and other things useful for “real hardware”.

Improved device tree support means graphics output for RVVM is now configured dynamically at boot allowing support for different screen resolutions. Some other devices like RTC seem to be easy to work with as well (I think that will work like the one in QEMU).

I expect that full support for other devices – input, disks, networking, audio – will still take a while inbetween other updates, but this work should start becoming easier once I’ve developed a bit more infrastructure for drivers (e.g. proper interrupt management).

Update: work on other drivers for RVVM is progressing quickly, RTC seems to work and I may be able to get input working soon…

Back to work now on some features which I had already prototyped earlier but left unfinished & broken.

Booting In RVVM

RVVM is probably the fastest or most convenient RISC-V emulator for general purpose operating system work but hasn’t been a major focus of my porting efforts so far.

Booting on RVVM with just the OpenSBI firmware seems to require a slightly different setup than when using uboot on real hardware so the current build has been tailored for that setup, which allows easy testing of new kernel updates.

A fix to DTB support was required and the system is now recognised & operational to some extent.

Graphics Support

This means graphics is now working, since RVVM has an easy to use framebuffer device, but further work will be required on APIs, input drivers etc. to get a full GUI up & running.

Current graphics output is limited to some pixel tests so screenshots will come later after some font or GUI work.

Other Updates Needed

A little infrastructure like support for “hub” type devices (USB etc.) will probably be needed for more serious driver work whether in RVVM or on real hardware but there could be some easy options at least when working with emulators, I’ll see…

I’m currently having some minor “it’s not working” problems with my very complicated computer setup and am also trying to prioritise getting to a doctor and getting a better chair. I don’t think I’ve lost any recent work between malfunctions though and I aim to be back to work within a month or so.

I’ll be dropping the DOS reference in REFDOS (RD) for reasons but haven’t finalised a new name. There will also be some changes in direction along with or after the rebrand:

• Maybe looking at incorporating a custom processor architecture & using FPGAs as the main target (this could lessen the need for excessive driver work and also help spread the RISC, so to speak)
• Will do some more work on marketing & finding a niche (maybe education or maybe robotics etc.)
• Will decide what to do about a graphics subystem
• May look at open-sourcing some components (maybe the whole OS, we’ll see)

There will be more to come too in time like maybe an online package repository and easily installable versions of compilers etc.

Network Stack Appears Stable

Basic TCP/IP network functions appear to work correctly, although these functions haven’t been expanded to a full suite yet (missing DHCP etc.). Using an academic IP stack instead of a commercial one seems to have resulted in very solid foundations and I remain very happy with this codebase.

As this appears mostly stable, debugging output has now been disabled so the stack now works silently in the background instead of printing a lot of junk on every event.

HTTP Server In Progress

I ported a HTTP server early on for testing the network stack, this was originally a little problematic (in retrospect I should’ve tested with an echo server or something) but now that it’s working it seems like the HTTP server can easily be expanded for dynamic content etc.

SecureLang® RD Online Launch

This smooth but uninspiring progress means that the platform can probably be put into production early serving sections of my own website/s. This would probably involve using a mainstream (e.g. Linux/Apache) frontend and relaying requests internally to VMs running SecureLang® RD and the custom HTTP server, which would serve information like API documentation for the OS.

This will mark a significant change from the early 1.0.1 & 1.0.2 releases, going from downloadable demos which don’t do much to an interactive system people can gain some familiarity with online. It should be possible to also provide shell accounts and online SDK services eventually.

Due to rapid increases in AI capabilities, my main compiler product could be pushed before it’s “ready” just to differentiate it from what I’m sure will be a lot of vibe coded programming tools just around the corner.

This product was mostly developed a couple of years ago and was a result of a great deal of raw effort coming up with something directly comparable to other modern programming tools but also with some unique features. So for the most part it’s well designed and already works well enough, but it quite simply isn’t finished yet it’s very rough around the edges and hasn’t been optimised.

The original plan was to build up more of an ecosystem so that this product could be launched more smoothly, but because of a likely explosion in competition about to happen this year I think I will probably just package & drop it early, but probably not for a little while yet – I will still have to clean up a few things and make sure it builds reliably!