Skip to content

RISC-V support #36748

Open
Open
RISC-V support#36748
Labels
arch-riscvRelated to the RISC-V architecturearea-VM-meta-monohelp wanted[up-for-grabs] Good issue for external contributors
Milestone
Future

Description

@mattgenious
mattgenious
opened on May 20, 2020

Posting because I cannot find mention anywhere

I have seen that mono supports the RISC-V architecture but cannot find anything relating to .NET 5 support for RISC-V.
Are there any plans to support said architecture on future releases of .NET like ARM64 has been added?

Activity

  1. Dotnet-GitSync-Bot
    added
    area-Meta
    untriagedNew issue has not been triaged by the area owner
    on May 20, 2020
  2. joperezr
    added
    questionAnswer questions and provide assistance, not an issue with source code or documentation.
    and removed
    untriagedNew issue has not been triaged by the area owner
    on Jul 7, 2020

  3. joperezr commented on Jul 7, 2020

    @joperezr
    joperezr
    on Jul 7, 2020
    Member

    cc: @marek-safar

  4. joperezr
    added this to the Future milestone on Jul 7, 2020

  5. DavidBurela commented on Nov 11, 2020

    @DavidBurela
    DavidBurela
    on Nov 11, 2020

    SiFive just announced a new powerful RISC-V development board coming out this year. Will be a number of new developers using the hardware. Might be worth looking at RISC-V support again, especially in IoT scenarios.

    https://www.sifive.com/blog/the-heart-of-risc-v-development-is-unmatched
    https://www.sifive.com/boards/hifive-unmatched

  7. broudy3 commented on Jan 16, 2021

    @broudy3
    broudy3
    on Jan 16, 2021
    Contributor

    I assume that libunwind needs to be ported first to RISC-V, as coreclr depends on this library. Is this statement true? There is a closed port request libunwind/libunwind#99

  8. 0xStuart commented on Mar 24, 2021

    @0xStuart
    0xStuart
    on Mar 24, 2021

    The BL602 is gaining popularity. It's an alternative to the hugely popular ESP32 which is everywhere.
    RISC-V with Wifi and Bluetooth

  9. ghost added
    needs-further-triageIssue has been initially triaged, but needs deeper consideration or reconsideration
    on Mar 24, 2021
  10. joperezr
    removed
    needs-further-triageIssue has been initially triaged, but needs deeper consideration or reconsideration
    on Mar 31, 2021

  11. archanox commented on Jul 7, 2021

    @archanox
    archanox
    on Jul 7, 2021

    I assume that libunwind needs to be ported first to RISC-V, as coreclr depends on this library. Is this statement true? There is a closed port request libunwind/libunwind#99

    It looks like the support has been merged in upstream now.

  12. ghost added
    needs-further-triageIssue has been initially triaged, but needs deeper consideration or reconsideration
    on Jul 7, 2021

  13. alexrp commented on Jul 7, 2021

    @alexrp
    alexrp
    on Jul 7, 2021
    Contributor

    Just noticed this issue and wanted to clarify something:

    I have seen that mono supports the RISC-V architecture

    For the record, "supports" is an overstatement here. IIRC, you can just barely run 'hello world' with the interpreter, and not much more. The JIT backend for RISC-V is like 10% done at most. There's a lot of work to be done for Mono's RISC-V support to actually be usable.

  14. 92 remaining items

  15. archanox commented on Nov 11, 2025

    @archanox
    archanox
    on Nov 11, 2025

    Are there any plans to raise that requirement to RV64GCV in the near future?

    I think it won't happen in a short term. Vectorization is not implemented yet in JIT. Once it is implemented, and e.g. the Ubuntu LTS baselines to RVA23, then it would make sense to raise the requirement. Since the current Ubuntu 24.04 LTS' lowest profile support is RVA20, we can align with that. riscv64gc is only a subset of RVA20 https://github.com/riscv/riscv-profiles/blob/5879c13/src/profiles.adoc#512-rva20u64-mandatory-extensions.

    I think it would be more preferable to have vector extensions sit in the intrinsics namespace, no? And I guess by extension c# Vector type.

  16. am11 commented on Nov 12, 2025

    @am11
    am11
    on Nov 12, 2025
    Member

    I believe there's some unofficial builds lurking around GitHub, but nothing one would consider stable.

    https://github.com/filipnavara/dotnet-riscv/releases/tag/10.0.100-rtm.25561.199

    From what I understand, the .NET team recognizes @dotnet/samsung as the designated community maintainer for the linux-riscv64 platform. Filip’s workflow leverages the same VMR repo tags (https://github.com/dotnet/dotnet/tags) used by Microsoft’s official releases to produce a compatible linux-riscv64 SDK. I’ve been running these builds on my device without any issues, they’ve been solid so far. See https://github.com/filipnavara/dotnet-riscv/blob/9cdf2e7aeddaff077e31c0455e1cc02277ef2406/.github/workflows/build.yml#L43

    @filipnavara, we could also add linux-musl-riscv64 (for these: https://wiki.musl-libc.org/projects-using-musl) to the release artifacts to round things out. Happy to prep the change if that sounds good. 🙂

  17. tannergooding commented on Nov 12, 2025

    @tannergooding
    tannergooding
    on Nov 12, 2025
    Member

    I think it would be more preferable to have vector extensions sit in the intrinsics namespace, no? And I guess by extension c# Vector type.

    @archanox, what was being said has nothing to do with how or where vector support will be exposed. The question was around whether the baseline could be raised and the response was what the limiting factors preventing that are.

    When RISC-V eventually gets vectorization support, it will likely be by providing xplat acceleration for the Vector<T> and Vector128<T> types first and foremost. Platform specific intrinsics may then be exposed after if there is enough benefit in doing so. There is likely still significant work in the JIT before such support could be enabled. Additionally, the core distros need to provide such support as well; and while parts of the vectorization ABI are "finalized", other parts and extensions are still in discussion and flux so the landscape isn't entirely stable and clear on direction yet.

  18. filipnavara commented on Nov 12, 2025

    @filipnavara
    filipnavara
    on Nov 12, 2025
    Member

    we could also add linux-musl-riscv64 (for these: https://wiki.musl-libc.org/projects-using-musl) to the release artifacts to round things out. Happy to prep the change if that sounds good. 🙂

    I don't have a way to test it but happy to accept a PR. Also, thanks for triggering the .NET 10 RTM build.

  19. Xeonacid commented on Nov 12, 2025

    @Xeonacid
    Xeonacid
    on Nov 12, 2025

    All of the riscv64 builds seems to be crossed on x86_64. Just wondering if it can be compiled natively on riscv64?

  20. am11 commented on Nov 12, 2025

    @am11
    am11
    on Nov 12, 2025
    Member

    I don't have a way to test it but happy to accept a PR.

    Shall do. 👍

    BTW, for K1 CPU based machines, the patch upstream is in progress (https://github.com/spacemit-com/linux/wiki#upstream-status). Once done, we will be able to use any riscv64 distro on those machines baremetal.

    For now, I'm using Alpine Linux userland on Bianbu OS 3.0.1 sharing the host kernel. Single command setup:

    curl -sSL https://raw.githubusercontent.com/alpinelinux/alpine-chroot-install/v0.14.0/alpine-chroot-install | \
  sudo APK_TOOLS_URI=https://gitlab.alpinelinux.org/api/v4/projects/5/packages/generic/v2.14.10/riscv64/apk.static \
  APK_TOOLS_SHA256=a6e2b71e49dbd828641bff0eb71c7377cd98a734f77ec68531dbe0d22f13eace \
  sh -s -- -d ~/alpine -a riscv64

    To enter chroot, ~/alpine/enter-chroot

  21. filipnavara commented on Nov 12, 2025

    @filipnavara
    filipnavara
    on Nov 12, 2025
    Member

    All of the riscv64 builds seems to be crossed on x86_64. Just wondering if it can be compiled natively on riscv64?

    Yes, it can be compiled natively but you need a bootstrap compiler. The bootstrap compiler can either come from cross-compilation or by using earlier native build. Due to continually shifting requirements for the bootstrap compiler version it is impractical to do purely native builds. That said, I build natively when debugging or testing changes.

  22. am11 commented on Nov 12, 2025

    @am11
    am11
    on Nov 12, 2025
    Member

    For the purely native build, we need this version of SDK https://github.com/dotnet/runtime/blob/main/global.json#L3, for that you can run that gh workflow and get the exact version available. I tried it once, YMMV. :)

    BTW, even x64 builds are cross-compiled in official releases because that process is quite streamlined; all we need from host is a working compiler toolchain and a few deps provided by eng/common/native/install-dependencies.sh.

  23. am11 commented on Nov 17, 2025

    @am11
    am11
    on Nov 17, 2025
    Member

    New 10.0 release https://github.com/filipnavara/dotnet-riscv/releases/tag/10.0.100

  24. Polaris-911 commented on Aug 17, 2026

    @Polaris-911
    Polaris-911
    on Aug 17, 2026

    Hi, I’d like to understand the current .NET upstream position on official linux/riscv64 binaries.

    What is the main blocker today, and what kind of community contribution would be most useful?

    Thanks.

  25. Polaris-911 commented on Aug 31, 2026

    @Polaris-911
    Polaris-911
    on Aug 31, 2026

    @marek-safar Hi, I’m following up on this issue to better understand the current position on official linux/riscv64 binaries.

    If this question belongs to another team or thread, I’d appreciate being pointed to the right place. Thank you.

  26. liberodark commented on Aug 31, 2026

    @liberodark
    liberodark
    on Aug 31, 2026

    Hi,

    For users want other version of dotnet have created :
    https://github.com/liberodark/dotnet_riscv
    For help support of some packages.
    PS : I would like to clarify that the versions are intended for nixpkgs support.

    Best Regards

  27. jkotas commented on Aug 31, 2026

    @jkotas
    jkotas
    on Aug 31, 2026
    Member

    .NET upstream position on official linux/riscv64 binaries.

    If by "official" you mean Linux/riscv64 binaries built and supported by the Microsoft .NET team, we have no current plans to produce such binaries.

  28. am11 commented on Sep 1, 2026

    @am11
    am11
    on Sep 1, 2026
    Member

    What is the main blocker today, and what kind of community contribution would be most useful?

    I don't know of any blocker. If you want to help, you can run various test suites in the repo and report the issues. e.g. #130562. And if you have time, feel free to debug and fix. The next bigger work item will be SIMD support #131926.

  29. raffaeler commented on Sep 1, 2026

    @raffaeler
    raffaeler
    on Sep 1, 2026

    ESP32-S31 (RISC-V) is getting official Linux support from Espressif

    https://blog.adafruit.com/2026/08/25/espressif-posts-a-linux-bsp-for-the-esp32-s31/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    arch-riscvRelated to the RISC-V architecturearea-VM-meta-monohelp wanted[up-for-grabs] Good issue for external contributors

    Type

    No type

    Projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions