Introducing a new RISC-V Mainboard from DeepComputing

Framework Team Blog
61

It’s very unlikely they would directly support OpenBSD themselves but from what I can see the chip itself is already supported by the OpenBSD riscv port. Just notes some firmware tweaking needed.

Worst case I expect one or two components to misbehave, like with the first Framework laptops (I think it was something in the monitor handling, but don’t remember for sure), but be a relatively easy fix (esp since FW engineers were helpful to the OpenBSD dev working on it).

In my case I almost hope there will be some, but small, issues. I need a gentle but interesting problem to solve if I am to learn. :stuck_out_tongue:

1 Like
62

That’s basically what I dream of for my next upgrade cycle (currently FW13 7840U): a RISC V board with CAMM RAM - the ultimate configuration <3

63

Okay point taken ARM is RISC but not RISC-V, it’s a moot point because the fracturing will happen anyway, if everyone follows the hype. That will be difficult for free and open source software, because it is sparse already. Under that light RISC-V seems like the “open source” of ISAs, but how is it going to look in reality, if microsoft and apple go with their vendor ARM, which manufacturer is going to supply RISC-V? Maybe framework, maybe it pans out. I’m just weary.

Also, re: tpm, when i wanted to install guix on my framework 16, secure boot was enabled by default on it. I had to disable it in order to have it boot my usb stick at all. At first i thought my usb stick was broken and flashed it a second time.

PS: bear in mind that i am talking about FOSS, not “Linux”/“open source”.

64

What is there to do other than develop faster silicon with more PCIE lanes? I feel like with modern development speed any 64-bit RISC-V chip that can compete on a hardware level would not take long to reach enthusiast level of acceptable compatibility.

65

As far as I’m aware, RISC-V doesn’t have nearly as much dedicated resources focused on it’s development.

1 Like
66

At least in the big desktop use-case, in embedded stuff they are popping up everywhere.

1 Like
67

Just FYI: Secure Boot does not require a TPM, and a TPM does not require Secure Boot. They are unrelated for your documented use case. The TPM does not make policy decisions about what can run on the machine.

2 Likes
68

Yes, thank you for clarifying for me.

1 Like
69

they are both two cheeks of the same butt. “Trust” in computing.

70

That’s what I’m thinking, I work on multiple different RISC-V based embedded boards. 32-bit only with no MMU so just running FreeRTOS with a bunch of features. I think if the silicon was promising there’d be a huge drive to get these supported, even if it was just a bunch of CE’s in their free time

71

Awesome to see a third party making a main board. Huge validation of Framework’s concept and ecosystem building.

RISC-V might be awesome, someday. Open source is great of course, and a competitor that challenges the issues with x86 and ARM is always welcome.

I’m struggling to see the value proposition of this particular board though. As a SBC like an overgrown Raspberry Pi, sure. But the performance is just too limited for me to want to daily drive this on my laptop.

So yeah, great idea, meh execution. But the door is open, so we’ll see who else walks through it…

Also, coverage for @junaruga 's list

3 Likes
72

Don’t think this is meant to be a value proposition for a regular consumer, this is definitely an enthusiasts/ development platform.

I do hope someone comes out with some higher end risc-v chips. Maybe the ones tenstorrent is cooking up translate well to laptops and kellers midas touch holds XD.

3 Likes
73

If the power draw is low, one of the main things I use my laptop for is writing my novel, which is nothing more than editing a text document and pushing it to git. This would likely excel at that use case… however, I already have a FW 16 so the need isn’t there atm. I see it more as a way of increasing exposure and encouraging development. I wouldn’t be surprised if fewer than 100 of these get made.

2 Likes
74

The first iteration is probably just meant to be mostly a development board, but in the future I could see it as a low-cost Linux/ChromeOS board with low power usage for web, office and watching videos. Kinda the same use case as for a Chromebook.

2 Likes
75

Kinda doubt it’s very efficient, it’s made on a way less efficient node and the drivers are likely even less power optimized than the current amd/intel ones.

77

100%. I spent a lot of time looking at building my own Raspi laptop, other similar projects, other risc-v and open source laptops… but in the middle of that research the Framework 16 announcement dropped. So now it’s all moot because I don’t want yet another computer doing little more than sitting around.

2 Likes
78

I use my Pi4 for web hosting and as a VPN so I can have access to my home network. Pi’s are good and they have many use cases but I find them best for small projects around the home.

1 Like
80

How is FOSS sparse? Besides Linux Firmware, my entire Linux system is only made up of FOSS.

Everything that is FOSS must be Open Source (FOSS → Free & Open Source Software) If open source profits (as many have explained) so does FOSS. How did you reach the conclusion that FOSS suffers anyway?

3 Likes
81

Not sparse in code or software, but people who actually do it. If you have to debug things when it comes to FOSS projects, it can be quite difficult to track down the correct info before having to reverse engineer it. They are sometimes hobby or side projects maintained by one person in their free time. Each with their own style of documentation.

With the aforementioned in mind, i see a problem arising when suddenly you have the same target platform with different hardware. Since the www x86 has been the main platform for Personal Computers, apple went with ppc and folded. Now, not only do the hobbyists have to decide which camps to go with, if you are looking for answers, chances are you get additional information that is not helpful. I see that the age of x86 yields an overdue change, but i question the motivation behind this particular move, more because of ARM admittedly. That is why i do not see the net benefit.

82

To my mind, the net benefit is simple and obvious: competition.

The x86 sphere is kept relatively honest by the fact that AMD needs to have a license from Intel for x86, and Intel needs a license from AMD for x86_64.

In desktop ARM (serving as the proxy for “Desktop RISC” since, today, there is no meaningful alternative), there is only the kinds of competition that ARM Holdings finds useful to their bottom line. And, besides, there’s plentiful fragmentation there too with a bazillion cores up for licensing (that may or may not have such simple things as division as part of the ISA implemented) and even whole ISA-only licenses where companies go full RISC-V style and implement from-scratch - doesn’t stop the Macbooks from being successful in the market. And looks like Qualcomm is making inroads via Microsoft.

RISC-V has the risk that specific implementations may differ dramatically in which instructions are implemented, making binary compatibility problematic. (Though less problematic where rebuilding is easy, eg FOSS.) But this is already an issue ARM is dealing with, and it is also an issue that x86 is dealing with. As an example, some projects, like simdutf, will be providing separate inline assembly depending on which exact x86 CPU you have - does it support AVX512 for example? And, after I found a bug caused by the fact that the OS (in this case OpenBSD/amd64) also needs to support AVX512 for it to function, it also has to check if the OS support AVX512 before selecting in that codepath. (Sans the fix, OpenBSD and a few other operating systems would flat-out crash any software using simdutf, for example nodejs, if executing on Intel 11th Gen or later.)

Due to this, Linux distributions (and proprietary OS vendors) already typically does things like flat-out ignore anything except the most common ISA extensions. It’s taking Arch years to reach a decision on whether to support x86_64_v3, because there’s a lot of stuff that can break if you default to ISA extensions that are as recent as 2013… (We’re soon going to have some Gentoo and/or FreeBSD poudriere fans in the room. :stuck_out_tongue: )

So as far as I see: all the problems RISC-V faces are actually the same as what both ARM and x86 is successfully navigating. There’s no reason to expect RISC-V to do worse (and also not better). So at the end, RISC-V can achieve one important thing: give ARM a competitor on the Desktop RISC ISA market.

And RISC-V doesn’t even have to be a huge player for this to be a benefit. You don’t have to use RISC-V chips to benefit from that.

7 Likes