The Common RISC Platform: A PC-like platform for the post-PC world

TL;DR – I’m developing an Open Hardawre platform based around RISC-V to replace the Wintel PC and am going to document my trials and tribulations here. This is also a bit of a recruitment drive for systems engineers/enthusiasts/users to help out with the project, link to the Github repo is at

This is a long one, so go make yourself a tea or coffee and strap in.

It cannot have gone unnoticed by many that the PC as a platform is under siege. For the past few years, development on RISC-V and ARM based SoCs has continued at a blinding pace, while improvements in the x86 world have somewhat stagnated. It is also easy to see how vendors of such chips have been using this opportunity to either develop or reinforce existing closed-loop ecosystems. One need only look at Apple’s recent release of its M1-based Macs for an example of this.

Thus, I have come to the conclusion that the PC as we know will be gone by the end of the decade. Rather than simply lie down and let the likes of Apple push us into a hellish dystopia of closed platforms, planned obsolescence and soldered-on-board mass storage, I believe that it is in the industry’s best interests if a free, open and fair standard platform were to be developed.

It would surprise many younger folks to learn that there once was a time when users could replace their P5 Pentiums with an AMD K6 or Cyrix 6x86 without changing anything else about the system. These days of course are long gone, giving way to the mess of chipset and socket changes we’re more familiar with today.

While the PC itself may be heading into its sunset years, this does not mean that open computing is dead. Far from it, in fact. I have noticed an ever-increasing interest from both the general populace and industry players in open-source hardware and ISAs like Power and RISC-V. Unfortunately, development seems to be quite stagnant in terms of developing products the average consumer would actually want to use.

SiFive’s RISC-V boards for example are little more than glorified prototyping boards, with next to no extensibility or consumer-friendly features. On the other end of the spectrum we have RaptorCS and their line of open-source Power ISA machines. While these are definitely a step in the right direction, software support for Power ISA is still very limited, and despite being RISC in name, the ISA itself is extremely complex and not well suited for simple/efficient consumer devices. Not only this, but Raptor’s boards (as well as IBM’s POWER chips) are lacking in the kinds of I/O that consumers would be interested in, focusing instead on more server-like implementations.

In my opinion, this fragmentation of the industry is just as bad as the closed-loop ARM ecosystems of the mobile space. At the end of the day, development work is still divided and consumers are still forced into a platform catered to a niche.

In my mind, the only way forward for the client compute industry is for an open, flexible and extensible platform to be adopted industry-wide. A platform that closely emulates the PC philosophy, but simplifies and modernises the technical underpinnings to prepare for the future of computing post-PC. A platform that defines a common set of hardware and standards to allow both software and hardware vendors the freedom to develop products for a standard lowest common denominator, and to reach a broad market. A platform that gives the user total and utter freedom over their machine.

And since no one else seems to be bothered trying to solve the post-PC problem, I thought I’d take a stab at. And so I did. I didn’t get very far on my own, though.

I started work on the Common RISC Platform last year by myself, as many of these sorts of things often start, thinking it would be a cakewalk. And it is at this point that the experienced systems engineers and computer architects reading have started laughing. The more I worked on the project, the more reading I had to do, and with every piece of literature I read, I found my reading list would grow by about 10 pieces. I’m not an idiot, but I’m not Lieutenant Commander Data, either. It’s simply impossible for one man to learn and store the entire sum of human knowledge on computer systems design. But I’m not giving up on this little dream

I intend to use this blog not only as a soapbox where I journal my escapades trying to develop the platform, but also as a call to arms. An invitation for any like-minded hardware developers, enthusiasts or even users who think they would be interested in making something like this a reality to check out the Github repo where I’ve committed some of my initial thoughts and design goals.

We are at a crossroads in the industry, and I strongly believe that a user-led revolt against the status quo is what’s needed to demonstrate that the current trend towards proprietary ecosystems is not acceptable to users, nor will it be beneficial in the long-term to the vendors’ bottom lines.

Thanks for indulging.

Jim

5 Likes

Guaranteeing rights - the CRPL

Today, I whipped up a quick license to govern the use of the Common RISC Platform specifications.

I originally planned on leaving the entire project license-free, but I quickly realised that this would just allow some yahoo or company to appropriate our work. I am reminded of Microsoft’s Embrace, Extend, Extinguish tactics from the 90s, and how they almost destroyed the Web with garbage like ASP.NET. Should this be allowed to happen, we’d be right back where we started.

So, the Common RISC Platform License is now in effect for the project. It is a very simple, 8-clause license that protects the rights of users, and prevents anyone from EEEing the specification.

The long and short of it is that one can use and reproduce any part of the specification for whatever purpose they want, but they cannot modify or change any part of it and still call it the Common RISC Platform. The license is also viral, meaning that anything anyone produces based on the CRP will also be bound by its terms.

I encourage you to read it and propose any changes or additions that may better guarantee the CRP’s freedom. It’s in the root directory of the GitHub repo, under ‘license.txt’.

James

Interesting. I haven’t had a chance to browse the full repo yet, but have a question nonetheless: Would there be any value in aligning with the work done by RMS / the FSF / GNU or similar? Specifically, Apple routinely demonstrates the advantages of vertical integration (making the OS and the hardware it runs on), so could similar advantages be gained by ‘closely’ aligning a free and open hardware platform with an existing free and open operating system / software platform?

One of the key design goals for me is the ability to be able to cleanly boot a vanilla Linux kernel with no injection of firmware blobs or proprietary kernel modules.

I think the vertical integration argument sort of falls apart in the context of an open platform. Consider that the benefit of vertical integration is borne from full and unfettered access to both the hardware and software designs. This allows designers of both to collaborate and sort of “custom make” their solutions to augment their counterparts. If both the software and the hardware are totally open source, then you remove the need for any particular ‘alignment’ since software developers have access to the full hardware spec and vise versa.

Another consideration is that software is targeted at a platform, but optimised for a machine. I envision the Common RISC Platform as a ‘reference’ standard that hardware vendors design their own machines for. While I do at some point want to produce a proof-of-concept prototype CRP machine, I fully expect and welcome custom machines to be created. Part of the reason why I conceived this project is to facilitate fair and open competition between chip designers, after all.

So while there obviously is merit to vertical integration between hardware designers/vendors and software engineers, I don’t think it’s the place of the platform to dictate those alignments. The platform should be as transparent and agnostic as is humanly possible in my opinion, as to do otherwise would be to acquiesce to the status quo I’m trying to tear apart.

This is to say nothing of the user’s right to install whatever software they choose to run. I feel it far from my place to tell users that they should install this OS or that OS simply because it runs better by design. That’s a choice for the user.

That all being said, if the FSF/GNU/whoever wish to contribute to the project then I don’t think anyone sane would ask them to not do so. However, contributions should, in true open source fashion, be borne from a genuine belief in the project and a self-determined desire to participate in its development, not because of some strategic alliance that obliges them to donate their time and labour.

1 Like

Fair point. I parted ways with Microsoft and Apple years ago in pursuit of an open and transparent desktop compute platform, so the idea of even bothering to (further) support closed/proprietary operating systems didn’t cross my mind. Others, no doubt, have different (yet equally-valid) opinions.

1 Like

Exactly my point. I personally haven’t used Windows or macOS on my personal devices in quite a long time, however part of the beauty of having a freedom-respecting platform is having the freedom to run any software you want. You or I may not like it, but if someone wants or needs to run a freedom-disrespecting OS on their machine then so be it.

Also consider that just because we “support” the execution of non-free software doesn’t mean we have to cater for it or bend over backwards to get it working. The beauty of an open and fair platform is that all software and hardware is treated equally and no one gets preferential treatment. Vendors are responsible for making sure their stuff works properly, not us.

On the hardware side, once again I stress that the platform is strictly vendor agnostic by design, and that the key design goals are freedom and flexibility. We do not prescribe machine architecture constraints other than those necessary to guarantee interoperability and universal binary compatibility. I know SiFive already produce Linux-optimised RV64GC cores, so I don’t see why other vendors wouldn’t do the same. Likewise, if someone wanted to produce a CRP machine optimised for Windows or Solaris or HP-UX, then that’s fine too. We won’t stop them, but we won’t celebrate it either.

Eventually, the market will decide what it wants to support. Consider that the PC is basically the only market in which Linux hasn’t completely taken over. Consider also that the Linux RV64GC ecosystem is quite healthy, whereas Windows has barely even gotten a proper ARMv8 port. I’m pretty confident that every year on the CRP will be the year of the Linux Desktop, even without our interference.

NB: I use the term “machine” in the traditional sense.

1 Like