5 ms·

Practically speaking, what am I going to be able to do w/ a risc v board? I imagine a ton of software will have problems with it, at least for now.

antonly 2y ago
I think part of the point is to find that problematic software, and contribute patches to make it work (or whatever you do for closed source software). In my mind this is a board to legitimise early adopters' requests, so that they can say "hey, this doesn't run on this very real laptop from a brand that you may have heard of". I think this is a crucial step on the way to getting an actually good experience on RISC-V based platforms.
chrisldgk 2y ago
It’s not super practical yet, a lot of software won’t run on it and they even write in the article that processing power wise it will probably be worse than their x86 counterparts. As they write in the article, the point is to make developing for RISC-V more accessible so that it can find wider adoption and get over those hurdles at some point to become more mainstream.
nrp 2y ago
We’re being deliberate on positioning this as a Mainboard for enabling developers and tinkerers, not a consumer-ready product. As other commenters noted, the idea is to help accelerate the maturity of the RISC-V ecosystem to prepare it for consumer access in the future.
- jimbobthrowawy 2y ago
  How much involvement did framework have in this becoming a thing? I'm asking because I want to get a feel for how long a decent (probably third-party) ARM mainboard might take.
freedomben 2y ago
TFA does say they've been working with Red Hat and Canonical to ensure a good base experience. I'm planning to buy one to run Fedora, knowing that a lot of packages may not be available, but hopefully enough so that I can build my own software on it and ship RISC-V binaries/packages. Currently I'm using qemu for that, but for someone who doesn't live and breath qemu it's an uphill battle.
sprinkly-dust 2y ago
Well, it's not the only option so no one's being forced to buy it. The same thing could've been said about ARM laptops just 5 years ago, before the launch of M1. Now, with Windows embracing ARM for real this time, it's properly established across all major platforms. The neat thing about this specific implementation is that it can be dropped right into an existing Framework laptop — a very viable hardware platform. Thus, it will allow developers (presumably mainly on Linux) to test and iron out issues in their software, the only way to fix those software problems you speak of. It represents a strong leap forward for RISC-V and open ISAs in general.
mejutoco 2y ago
It could be educational to learn assembly, for example. (I know you can use a virtual machine for that)
WhyNotHugo 2y ago
Proprietary software mostly will require emulation or other similar techniques and WILL be problematic. Anything else can generally be re-compiled. Several distributions support RISC-V already. Alpine has a total of 11378 aports, of which 850 are marked explicitly as "doesn't build for riscv64".
Muromec 2y ago
All the stuff you were able to do with ARM boards before mainstream adoption, which is mainly: become involved in driver development.
- snvzz 2y ago
  >become involved in driver development. Ironically, with JH7110, there isn't much driver development left to do. Most of it is already upstreamed[0]. 0. https://rvspace.org/en/project/JH7110_Upstream_Plan https://rvspace.org/en/project/JH7110_Upstream_Plan
rbanffy 2y ago
> what am I going to be able to do w/ a risc v board? Be the coolest kid in the block. Now, seriously, people buy RISC-V boards in order to use RISC-V boards. If it were to do something else, you'd probably be better off with an x86 or ARM design.
shrubble 2y ago
I am assuming (hope I am right!) that the RISC-V board doesn't have the equivalent of the IME on it and thus will be open-source "librebootable" from the start, with no binary blobs.
- cesarb 2y ago
  > I am assuming (hope I am right!) that the RISC-V board doesn't have the equivalent of the IME on it Actually, it does! Check the block diagram on the first PDF linked to by this article, it has two RISC-V "monitor cores", a 32-bit one and a 64-bit one, besides the four 64-bit main cores. > and thus will be open-source "librebootable" from the start, with no binary blobs. There's always going to be a small bootstrap ROM, to configure everything to the point where code can be loaded from the external flash; but other than that, I agree with you: I also hope that the bootstrap code, and the code which runs on these "monitor cores", will be open-source from the start.
- snvzz 2y ago
  >open-source "librebootable" from the start Already is. There's a default flow with u-boot SPL, opensbi and u-boot. There's an alternative flow which includes TianoCore (UEFI). There's another alternative flow, oreboot. All the tiny ROM inside the SoC does is fetch the next stage from elsewhere, as per the state of some GPIOs. One of the options is XMODEM on the UART. DRAM setup and such happen in the next stage, which is e.g. u-boot SPL mentioned above. >doesn't have the equivalent of the IME There are some extra tiny cores in the SoC. They are available for you to use; you can implement an IME if you wanna. But by default they're doing nothing.
G3rn0ti 2y ago
There is already a Debian port available for RISC-V platforms including 99% of its packages: https://wiki.debian.org/RISC-V https://wiki.debian.org/RISC-V IIRC even a port of Fedora Linux. So you could use it as a daily driver already — unless you need a bit more computing power. A YouTuber made a nice video on how he edited a full episode on a RISC-V SoC using Kdenlive on Debian some time ago: https://youtu.be/7ke7d0iO_-0?si=-rjXdTxfYd_jLQuU https://youtu.be/7ke7d0iO_-0?si=-rjXdTxfYd_jLQuU
- snvzz 2y ago
  >There is already a Debian port available for RISC-V platforms including 99% of its packages: https://wiki.debian.org/RISC-V https://wiki.debian.org/RISC-V The official RISC-V port of Debian is around 97%[0] to be exact. This is already above "armel", an architecture that's been officially supported for much longer. Current build process status is available[1]. >IIRC even a port of Fedora Linux. Arch, too. I run Arch on my VisionFive 2. 0. https://buildd.debian.org/stats/ https://buildd.debian.org/stats/ 1. https://buildd.debian.org/status/architecture.php?a=riscv64&suite=sid https://buildd.debian.org/status/architecture.php?a=riscv64&...
topspin 2y ago
If you're worried that it won't just slot into your electronics ecosystem with zero friction then it's not for you. It's for a small cadre of early adopters that will suffer the papercuts and then cajole, shame and badger an even more minute group of firmware and kernel developers into making everything work. After enough of this has gone on you'll be able to safely get aboard. It's not pretty, or fair, but that's how it all actually works.

antonly 2y ago

I think part of the point is to find that problematic software, and contribute patches to make it work (or whatever you do for closed source software). In my mind this is a board to legitimise early adopters' requests, so that they can say "hey, this doesn't run on this very real laptop from a brand that you may have heard of". I think this is a crucial step on the way to getting an actually good experience on RISC-V based platforms.

chrisldgk 2y ago

It’s not super practical yet, a lot of software won’t run on it and they even write in the article that processing power wise it will probably be worse than their x86 counterparts. As they write in the article, the point is to make developing for RISC-V more accessible so that it can find wider adoption and get over those hurdles at some point to become more mainstream.

nrp 2y ago

We’re being deliberate on positioning this as a Mainboard for enabling developers and tinkerers, not a consumer-ready product. As other commenters noted, the idea is to help accelerate the maturity of the RISC-V ecosystem to prepare it for consumer access in the future.

jimbobthrowawy 2y ago
How much involvement did framework have in this becoming a thing? I'm asking because I want to get a feel for how long a decent (probably third-party) ARM mainboard might take.

freedomben 2y ago

TFA does say they've been working with Red Hat and Canonical to ensure a good base experience. I'm planning to buy one to run Fedora, knowing that a lot of packages may not be available, but hopefully enough so that I can build my own software on it and ship RISC-V binaries/packages. Currently I'm using qemu for that, but for someone who doesn't live and breath qemu it's an uphill battle.

sprinkly-dust 2y ago

Well, it's not the only option so no one's being forced to buy it. The same thing could've been said about ARM laptops just 5 years ago, before the launch of M1. Now, with Windows embracing ARM for real this time, it's properly established across all major platforms. The neat thing about this specific implementation is that it can be dropped right into an existing Framework laptop — a very viable hardware platform. Thus, it will allow developers (presumably mainly on Linux) to test and iron out issues in their software, the only way to fix those software problems you speak of. It represents a strong leap forward for RISC-V and open ISAs in general.

mejutoco 2y ago

It could be educational to learn assembly, for example. (I know you can use a virtual machine for that)

WhyNotHugo 2y ago

Proprietary software mostly will require emulation or other similar techniques and WILL be problematic. Anything else can generally be re-compiled. Several distributions support RISC-V already. Alpine has a total of 11378 aports, of which 850 are marked explicitly as "doesn't build for riscv64".

Muromec 2y ago

All the stuff you were able to do with ARM boards before mainstream adoption, which is mainly: become involved in driver development.

snvzz 2y ago
>become involved in driver development. Ironically, with JH7110, there isn't much driver development left to do. Most of it is already upstreamed[0]. 0. https://rvspace.org/en/project/JH7110_Upstream_Plan https://rvspace.org/en/project/JH7110_Upstream_Plan

rbanffy 2y ago

> what am I going to be able to do w/ a risc v board? Be the coolest kid in the block. Now, seriously, people buy RISC-V boards in order to use RISC-V boards. If it were to do something else, you'd probably be better off with an x86 or ARM design.

shrubble 2y ago

I am assuming (hope I am right!) that the RISC-V board doesn't have the equivalent of the IME on it and thus will be open-source "librebootable" from the start, with no binary blobs.

cesarb 2y ago
> I am assuming (hope I am right!) that the RISC-V board doesn't have the equivalent of the IME on it Actually, it does! Check the block diagram on the first PDF linked to by this article, it has two RISC-V "monitor cores", a 32-bit one and a 64-bit one, besides the four 64-bit main cores. > and thus will be open-source "librebootable" from the start, with no binary blobs. There's always going to be a small bootstrap ROM, to configure everything to the point where code can be loaded from the external flash; but other than that, I agree with you: I also hope that the bootstrap code, and the code which runs on these "monitor cores", will be open-source from the start.
snvzz 2y ago
>open-source "librebootable" from the start Already is. There's a default flow with u-boot SPL, opensbi and u-boot. There's an alternative flow which includes TianoCore (UEFI). There's another alternative flow, oreboot. All the tiny ROM inside the SoC does is fetch the next stage from elsewhere, as per the state of some GPIOs. One of the options is XMODEM on the UART. DRAM setup and such happen in the next stage, which is e.g. u-boot SPL mentioned above. >doesn't have the equivalent of the IME There are some extra tiny cores in the SoC. They are available for you to use; you can implement an IME if you wanna. But by default they're doing nothing.

G3rn0ti 2y ago

There is already a Debian port available for RISC-V platforms including 99% of its packages: https://wiki.debian.org/RISC-V https://wiki.debian.org/RISC-V IIRC even a port of Fedora Linux. So you could use it as a daily driver already — unless you need a bit more computing power. A YouTuber made a nice video on how he edited a full episode on a RISC-V SoC using Kdenlive on Debian some time ago: https://youtu.be/7ke7d0iO_-0?si=-rjXdTxfYd_jLQuU https://youtu.be/7ke7d0iO_-0?si=-rjXdTxfYd_jLQuU

snvzz 2y ago
>There is already a Debian port available for RISC-V platforms including 99% of its packages: https://wiki.debian.org/RISC-V https://wiki.debian.org/RISC-V The official RISC-V port of Debian is around 97%[0] to be exact. This is already above "armel", an architecture that's been officially supported for much longer. Current build process status is available[1]. >IIRC even a port of Fedora Linux. Arch, too. I run Arch on my VisionFive 2. 0. https://buildd.debian.org/stats/ https://buildd.debian.org/stats/ 1. https://buildd.debian.org/status/architecture.php?a=riscv64&suite=sid https://buildd.debian.org/status/architecture.php?a=riscv64&...

topspin 2y ago

If you're worried that it won't just slot into your electronics ecosystem with zero friction then it's not for you. It's for a small cadre of early adopters that will suffer the papercuts and then cajole, shame and badger an even more minute group of firmware and kernel developers into making everything work. After enough of this has gone on you'll be able to safely get aboard. It's not pretty, or fair, but that's how it all actually works.