PLCT Lab intends to collaborate on RISC-V support

I am dram, currently working at PLCT Lab at ISCAS (Institute of Software, Chinese Academy of Sciences). We’ve been working with various RISC-V software and hardware communities to improve the ecosystem.

As part of Project Jiachen, also known as RISC-V Prosperity 2036, PLCT Lab intends to collaborate with the NixOS community. The goal of this collaboration is to improve Nixpkgs/NixOS support of the RISC-V architecture, thereby promoting the growth and prosperity of the RISC-V ecosystem.

To achieve this, we plan to provide access to RISC-V development boards to the NixOS community for use as CI and manual testing platforms. Additionally, we will offer internship opportunities (currently limited to Chinese students) to work on maintaining the CI infrastructure and fixing build failures.

We have already sponsored @NickCao with a build server that powers https://hydra.nichi.co, which builds Nixpkgs cross compiled to RISC-V from x86_64, and has been able to assist the community by catching and fixing cross problems and providing a RISC-V binary cache.

We look forward to working together with the NixOS community to drive innovation and progress in the RISC-V landscape.

Currently we would like to discuss the following questions with other community members:

  1. What are your current views on RISC-V support? Is this a project worth pursuing?
  2. What level of extra burden will this place on maintainers and infrastructure (edited to clarify) to gradually raise RISC-V platforms to better tiers of support? What can we do to better support for collaborators?
  3. What approach should we go for? Should we prioritize cross-compilation or native compilation for RISC-V?
  4. What are some difficulties and hurdles expected?

If you have any thoughts or opinions, just write them here as a reply. You can also contact me on Matrix in Exotic Nix Targets (#exotic:nixos.org) or NixOS RISC-V (#riscv:nixos.org) (I’m @dramforever:matrix.org). Thanks for your attention and support.

22 Likes

Great to hear of the collaboration effort :slight_smile:
Would like to see support of RiscV64 as official supported architecture in nixpkgs so no external binary cache would be required.

Already wrote a wiki page for NixOS on RISCV/VisionFive 2 - NixOS Wiki and looking forward mainline Linux kernel support for that device

2 Likes

The idea of cross compiling Nixpkgs to other embedded-like architectures is pretty cool, but from my experience with embedded Linux boards, armv7l is a much more common architecture. I have a personal project that uses the Balena ecosystem, and I deeply wish that some day I’d be able to fully build and deploy my project using Nix and Nixpkgs’ cross compilation support. I talked with the Balena folks once about supplying Nix support, but it is really a totally different product that I was proposing them, so I don’t think they’ll put any efforts in to this direction.

Unfortunately now, such a build and deployment flow would require me to cross compile packages like xorg and chromium, and I can’t afford to do that. If there was a hydra instance that would cross compile cache for armv7, and I could have known what is the Nixpkgs revision that this hydra instance has last evaluated, it would have been amazing. Such a cache would have also motivated me to help you in the mission of making Nixpkgs more cross compile-able.

Are you talking about Nixpkgs’ packages’ maintainers? If from time to time you’d send PRs to Nixpkgs that would fix cross compilation support for packages, no maintainer would object.

Also what infrastructure burden are you talking about? I think I didn’t understand the question.

In my experience, if you fix a cross compilation issue to 1 platform, you fix it for all of them. So, yes! I support prioritize cross compilation!

I anticipate that you’d experience difficulty with the scopes in Nixpkgs, and with packages that need to mix packages from different scopes such as python3Packages and qt6Packages. For example picard, has this in it’s arguments (roughly quoting):

{ lib,
# ...
, python311Packages
, qt5
, gst_all_1
}:

Similarly, a common issue / mistake is packages that use the darwin scope in their arguments.

The classic way to support cross compilation of such packages is to callPackage them with inherit (<scope>) p1 p2 p3;

Thinking about this common issue broadly, makes me think that a significant improvement to the pkgsCross overlays would be to support packages files that use such scope arguments. This would also allow to reduce all-packages.nix even further beyond what pkgs/by-name allows.

Another common issue / mistake related to scopes I suspect you’d encounter is with packages that are defined in all-packages.nix using <scope>.callPackage (e.g python3Packages.callPackage). I don’t know exactly how to explain why these will fail to cross compile, but I’m pretty sure they will.

I just wanted to chime in and say this is very exciting. I think RISC-V and it’s underlying licensing model is vastly superior to what is going on with ARM at the moment. Here’s to hoping we see more hardware soon.

I keep looking in the pine64 store to see if their tablet is available for purchase.

but it seems to not be available yet. And is the rvphone ever going to come out? Are there any devices out there in the wild with risc-v on it yet?

minor edit: just adding a link to the dev boards that are available out there in the wild. Hope to see more consumer devices soon.

Hi, thanks for your answer. I’m glad that you’re supportive of improving support for cross and exotic.

As for infrastructure, I meant to refer to the burden adding and maintaining RISC-V CI in a more official way, and eventually getting riscv{32,64}-* to climb the (RFC64) support tiers. This would require more commitment.

Oh I see. Well, I don’t have a strong opinion about this since I’m not involved in the Hydra maintenance:), but in principal I support adding more packages to release-cross.nix. See also discussion here:

I see Pinetab-V here PineTab Archives - PINE STORE

There’s also Muse Book, and DC ROMA laptops. And as you mentioned, loads of dev boards.

ya but the links only say ‘read more’ I can’t find a buy button for the risc-v tablets, only the arm tablets appear to be available at this time.

Thanks for pointing out the muse book, which looks to be available here.

1 Like