Category: Uncategorized

It’s a bit of a blur but I don’t recall doing anything else between 7PM Tuesday and 7PM Wednesday except making coffees.

Bit of a headache. But it’s done.

The kernel rewrite I mean, not a whole release plan. Legacy code is now only used when booting on QEMU it can be omitted entirely when building for real hardware.

This should greatly help in the next stages of development as I won’t have to balance other goals with cleaning up old code. On the other hand it created more testing work for me as now just about anything could’ve been broken and for now it’s no longer compatible with the test suite.

So bringing up some userland programs is the next goal, I’ve already written a new init program.

The audit tool becomes a bit ineffective towards the end as I’ve mostly got headers & drivers left, so it’s showing 85% new code but the remaining ~14% “old” code will mostly be cut out into an optional driver package for running on QEMU.

I haven’t done a complete build without any old code yet but I’m fairly close to that stage, maybe a day or so more work. References to old headers have mostly been replaced but still remain in a few places, and some parts of the old drivers are still needed (most is only needed for testing on QEMU without SBI boot).

So the first version will only be “totally new” when running in the simplest configuration booting a demo shell from SBI, but very soon I should be able to start producing kernel builds that are only my own code!

Only about 500 lines of legacy example code to replace and I’ll have me an all new OS kernel, at least for simple builds. This is excluding a little clutter that needs to be cleaned up before release.

Some of the remaining “legacy” code may be spun into a new driver package covering QEMU functionality, and more work remains to be done getting demo programs packaged for use on the kernel.

Hopefully the next post will be about a successful build with no legacy code!

Fast Kernel Releases

My previous plan was to stage 1.x releases towards a fully new kernel design in 2.0 but it looks like the replacement code will be more-or-less finished any day now so for real releases I now mostly just have to worry about adding more features!

So it’s likely that a 1.0 kernel will be released with only basic features and some limited modularity. This kernel will be mostly stable but not fully tuned or perfected, so API/ABI stability will still be work in progress for the 1.x branch.

1.0 Will Be Limited

I’ll probably release a plain 1.0 version once the example code is fully or almost fully replaced. Although I’m inclined to call it something like 0.9 and finish drivers etc. it’s unlikely that I’ll find a better target for when to call it 1.0 than basing it on the replacement of legacy code.

This means graphics, advanced drivers etc. won’t be finished by 1.0 it will only be a “general purpose OS” in so far as implementing core features like multitasking. It won’t have full end-user features like a desktop and it won’t have an easy IDE for programmers yet, it will just be a tech preview running some programs on a new stack.

This probably won’t come with full public source code but there will be some code with the release, and this applies only to the kernel (the “userland” stuff is still just a demo).

The Rest Will Move Slower

I previously planned to tie other software versions to the kernel version but this may be unnecessary if the kernel is mostly finished.

Compiler backend & libc are already mostly working as well as some simple programs. These will probably initially be released in a simple demo package with the kernel but will eventually be versioned as well, particularly after the system becomes fully self-hosting.

The kernel audit tool is now reporting 81% new code and this number is even further ahead if only .c files are counted. Only around 1,500 lines of example code remains in .c files, with only a little more important stuff in headers & assembly files.

This means almost all code adapted from example code has been rewritten already which will make ~1.0 versioning simpler (previous plan was to do a release in stages as I finalised the rest of the kernel code).

More updates will follow as the final changes are made!

The writing of new kernel code is now back on schedule. After thinking I’d have to do a release in several stages I ended up replacing a lot of old code.

Kernel audit now reports 75% new code. Inspection of the remaining legacy code shows that the rest should be particularly easy to replace. More updates on this progress and final release plans will follow in the coming days.

A uname command & system call has been added together with an empty man command.

Additional userland programs are being ported now based on some early successes. This should allow replacing of most of the old userland programs with more portable versions that can also be tested on Linux or elsewhere.

RISC-V at it’s heart is a very simple core standard for new general-purpose processors, making it very simple in theory, but CPUs usually need some extensions for real world use cases. So as well as the core standards the RISC-V organisation also promotes some profiles allowing people to select CPUs with some reasonable compatibility expectations.

Most boards I’m developing on are designed to match the (older) RVA22 profile with (newer) RVA23 being very similar but adding more extensions, which hardware manufacturers are only just now starting to finalise implementations of. So testing my platform with RVA23 will begin some time after those devices become available, with the UR-DP1000 possibly being one of the last major CPU release before everyone standardises on RVA23 (it should already have some of the RVA23 features but not all). The hypervisor/virtualisation extensions which are very rare on current devices should be standard as of RVA23.

Thanks to very heavy standardisation process between the RISC-V organisation and manufacturers, any software designed for RVA22 devices should be almost seamlessly compatible with RVA23 devices (aside from different peripherals on different devices), while for embedded developers some of those RVA22/RVA23 features will be overkill for many products (and my software should work without most of them).

So my current strategy is to support these new features where I can – especially I plan to look into any features relevant for HPC & server use cases – but my software will remain targeted towards cheaper/older CPU models and dev boards. Focusing on new models can also lead to problems like features just not working as expected or not being clearly documented, and earlier versions pre-RVA23 will probably still be much cheaper and more accessible for developers living in tight economic situations, so rest assured I’m very aware of these challenges and will be targeting my software at the most accessible and reliable dev boards. But I will always have both eyes on what’s ahead!

Other CPU Families

Thanks to C and my other development tools being very portable it should be relatively easy to port my whole stack to other CPUs as well, and some legacy AMD64/x86-64 support still exists in the C compiler (mostly based on the LICE code generator from before I extended it with my new backend). I also have a bit of other legacy code from my old OS projects that I could probably draw on for legacy CPU support (and xv6 also provides a version for legacy PCs).

So supporting architectures other than current RISC-V hardware won’t be a priority for my business in the short term but in the longer term support for other CPU families can be added, either by myself or by third-party/open-source distributors.

I’m very aware that most developers in Egypt, West Africa and other parts of the world don’t have such easy access to the latest Chinese & American tech as we do around Australia, so although the local government often choose to forego those advantages by not promoting innovation on new platforms I’m hoping to maximise those advantages by pre-ordering what I can when I can.

The Milk-V Titan should be quite a beast compared to earlier boards, with beefed up performance that will help drive all aspects of my software development, but the real feature I’m looking out for (and which there has been a bit of speculation about whether it will ship) is the virtualisation extensions. So at time of writing it looks like they are shipping with the virtualisation features fully working, and that should be a bit of a game changer for OS developers as it means we should have a fully stable stack where VMs will work quickly & reliably. On the other hand some features like this might still be a bit experimental so I’m trying not to rely on it.

My main development machine at the moment (not the main test board) is a top-specced Milk-V Jupiter and it’s running great so I’m very confident with that manufacturer and I’ve been watching for this new board since getting ahold of the Jupiter model. SpacemiT & Ky chips have been giving me pretty flawless performance so far (though a little slow for Firefox) so I’m sure I’ll be impressed by anything a bit faster than that – although the SpacemiT range is what I’d recommend for current projects and will probably remain a main target.

Some information about the UltraRISC UR-DP1000 chip and the Milk-V Titan board can be found here:

https://ultrarisc.github.io/ultrarisc-devblog/2025/06/18/dp1000-spec/

https://milkv.io/titan

(UPDATE) It looks like someone working on Linux has already found a hardware bug in this range of chips:

https://lwn.net/Articles/1042232/