Update the "Hardware" section.
|Deletions are marked like this.||Additions are marked like this.|
|Line 74:||Line 74:|
|* qemu: not upstreamed yet (for information about the current state of qemu support please refer to the [[#Qemu|qemu]] section below)||* qemu: upstreaming in progress, targets the 2.12 release. For more information about qemu please refer to the [[#Qemu|qemu]] section below.|
|Line 85:||Line 85:|
:: A first version of the qemu upstreaming patchset has been [[https://lists.nongnu.org/archive/html/qemu-devel/2018-01/msg00175.html|posted]] to the qemu-devel mailinglist.
|Line 211:||Line 215:|
|Qemu support for RISC-V isn't upstream yet, but there is a fork with RISC-V support at https://github.com/riscv/riscv-qemu/. In 2017-12 several major enhancements have been implemented, the most important being support for version 1.10 of the RISC-V privileged ISA specification, which allows running upstream kernels in qemu. The first supported system-emulation target was a spike-compatible board, which unfortunately doesn't support any block devices besides the initrd and doesn't have any networking support. There is now also a "virt" target that supports virtio block and network devices as well as a serial console. User-mode emulation is largely working, but certain syscalls aren't translated properly due to changes in the Linux syscall interface during the kernel upstreaming process for which corresponding changes in qemu still have to be done.||Upstreaming of qemu support for RISC-V is currently work-in-progress; the code is available in the "qemu-upstream" branches at https://github.com/riscv/riscv-qemu/. In 2017-12 several major enhancements to qemu have been implemented, the most important being support for version 1.10 of the RISC-V privileged ISA specification, which allows running upstream kernels in qemu. The first supported system-emulation target was a spike-compatible board, which unfortunately doesn't support any block devices besides the initrd and doesn't have any networking support. There is now also a "virt" target that supports virtio block and network devices as well as a serial console.|
|Line 280:||Line 284:|
|* https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=riscv64;firstname.lastname@example.org|| * Usertags for user [[https://email@example.comfirstname.lastname@example.org]] ([[https://email@example.com|UDD]]):
* riscv64: all bugs related to the Debian riscv64 port
This page contains details about the port of Debian for the RISC-V architecture (riscv64).
- In a nutshell
- Upstream project / Architecture / Hardware
- Debian port information
In a nutshell
What is RISC-V?
From the Wikipedia entry for RISC-V:
RISC-V (pronounced "risk-five") is an open source instruction set architecture (ISA) based on established reduced instruction set computing (RISC) principles.
There are different versions of the instruction set for 32, 64 and 128 bits; operating as little-endian by default.
What is a Debian port?
In short, a port in Debian terminology means to provide the software normally available in the Debian archive (over 20,000 source packages) ready to install and run on systems based in a given computer architecture with the Linux kernel, or kernel-architecture combinations, with other kernels including GNU Mach (from GNU/Hurd) and kFreeBSD (from GNU/kFreeBSD).
What are the goals of this project in particular?
In this project the goal is to have Debian ready to install and run in systems implementing variants of the RISC-V ISA:
Software-wise, this port will target the Linux kernel
Hardware-wise, the port will target the 64-bit variant, little-endian
The ISA variant is the "default flavour" recommended by the designers, and the one that seems to attract more interest for planned implementations that might become available in the next few years (development boards, possible consumer hardware or servers).
While 32-bit and 128-bit implementations are possible, there are problems with this:
- In the context of RISC-V design, they have not been explored as deeply, and tools and resources (e.g. simulators, research cores) as not as well studied and adapted;
- For general purpose computers, the focus shifted to 64-bit for many years already, and there isn't a lot of interest in 32-bit architectures except for specific purposes;
- 32-bit ports in Debian already struggle to compile some large packages of the archive in the last few months/years, a problem that will become worse with time;
- and 128 is simply not realistic at this time.
Upstream project / Architecture / Hardware
Upstream project / Community
Main website: https://riscv.org
Mailing lists (see below for Debian-specific): https://riscv.org/mailing-lists/
IRC (see below for Debian-specific): #riscv at freenode
ASIC implementations, i.e. "real" CPU chips
There is currently no Linux-capable RISC-V silicon available for purchase by the general public, but this will probably change in the future. As of 2017-10, possible candidates include:
The lowRISC project, which has described itself as follows:
"lowRISC is a not-for-profit organisation working closely with the University of Cambridge and the open-source community.
A commercial offering from SiFive. According to an article on hackaday.com, SiFive has on 2017-10-04 announced a Linux-capable 64Bit RISC-V quad-core SoC to be available on a development board "in early 2018". A more detailed technical description of the SoC and the development board has been made available in a presentation (PDF) at the 7th RISC-V workshop.
Toolchain upstreaming status
- binutils: upstreamed (2.28 is the first release with RISC-V support)
- gcc: upstreamed (7.1 is the first release with RISC-V support)
- glibc: upstreaming in progress, targets the 2.27 release
- linux kernel: upstreaming in progress (the architecture core code has been accepted upstream and will be part of the kernel 4.15 release; for full system support additional driver code is necessary which is planned to go into kernel 4.16)
- gdb: not upstreamed yet
qemu: upstreaming in progress, targets the 2.12 release. For more information about qemu please refer to the qemu section below.
Debian port information
Hardware baseline and ABI choice
The Debian port uses RV64GC as the hardware baseline and the lp64d ABI (the default ABI for RV64G systems).
Making the C extension a part of the default hardware baseline for general-purpose binary Linux distributions has been agreed upon between Fedora porters, Debian porters and members of the RISC-V foundation. According to the chairman of the board of the RISC-V foundation, the foundation will provide "a profile for standard RISC-V Unix platforms that will include C as mandatory".
A first version of the qemu upstreaming patchset has been posted to the qemu-devel mailinglist.
A new version of the glibc upstreaming patchset which matches the kernel code in Linux 4.15rc3 has been posted to the libc-alpha list.
The pull request for the kernel has been accepted and the architecture-core patchset has been merged into the upstream kernel repository.
A pull request for inclusion of the RISC-V architecture-core patchset into kernel 4.15 has been sent to Linus Torvalds.
The RISC-V Linux kernel upstreaming patchset has been included into linux-next.
Version 9 of the kernel upstreaming patchset has been posted to LKML on 2017-09-26. As planned after v8, it has been split into an architecture-core and a driver patchset. The RISC-V architecture maintainer has a kernel.org account now, which is a prerequisite for getting the patches into linux-next, but the actual inclusion into linux-next is still pending as the linux-next maintainer has announced that updating the linux-next tree will be on hold during the whole of October 2017.
The kernel upstreaming patchset hasn't made it in into the kernel 4.14 merge window, so it now targets kernel 4.15. Version 8 of the patchset has been posted to LKML recently (note: the archive of the corresponding thread on lkml.org appears to be incomplete). While the patchset has received an overall positive review from kernel developer Arnd Bergmann, he and two other kernel developers have pointed out a few minor points that require some further discussion and probably some restructuring of the timer code. The plan for version 9 of the patchset is to address those issues and split the patchset into an architecture-core and a driver patchset. The architecture-core patchset can then hopefully be soon included in linux-next as a preparation for getting it merged during the kernel 4.15 merge window.
- The RISC-V upstream kernel patchset has gone through a number of review cycles, but hasn't made it into the kernel 4.13 merge window. Judging from the review comments, chances for an inclusion into kernel 4.14 look quite good, though. There are a number of open questions concering the RISC-V memory model, whose formal specification is still work-in-progress. The corresponding RISC-V foundation working group has announced that the formal memory model specification should be published in the near future (before end of 2017).
- The upstream glibc maintainers have made clear that they require the kernel port to be accepted (at least as part of linux-next, preferably as part of a Linux release candidate) before the glibc support can be accepted for upstream inclusion. As a result, the upcoming glibc 2.26 release won't have RISC-V support. The earliest upstream glibc version that could have RISC-V support will therefore be 2.27, which is planned to be released around 02/2018.
The first version of an upstreaming patchset for glibc has been posted to the upstream glibc development list (libc-alpha).
The first version of an upstreaming patchset for the Linux kernel has been posted to the upstream Linux kernel mailinglist.
Upstream GCC 7.1 has been released with RISC-V support.
Unofficial repository published (WIP, incomplete and probably not working for you at the moment): http://riscv.mit.edu/
More information about details and story in https://people.debian.org/~mafm/posts/2017/20170422_debian-gnulinux-port-for-risc-v-64-bit-riscv64/
- Upstream binutils 2.28 have been released with RISC-V support on 2017-03-02.
- The binutils support for RISC-V has been accepted upstream in November/December 2016 and will be part of binutils 2.28 (expected to be released in Q1/2017).
The GCC support for RISC-V has been accepted for upstream inclusion by the GCC Steering Committee but is still pending the final stages of the technical review as there have been a number of review comments that need to be addressed in a new version of the upstreaming patchset. There is reason for hoping that the RISC-V support could make it into the GCC 7 release, but this depends on how fast the review process can be finished.
- The preparations for this port started in private a while ago, but nothing has been made public so far and nothing useful yet for users and developers.
The main reason is the lack of official support for this architecture in fundamental pieces of the toolchain (binutils, gcc, glibc), the main OS kernel (linux) or even other software that might help with the port (e.g. qemu). All of the mentioned pieces have support in progress and are considered to submit for upstreaming, but nothing definitive has happened at the moment.
In particular, a recent message informed about some upcoming changes to the supervisor specifications (the ABI), which will affect binutils at least. Starting a Debian port without the ISA being settled is not very good, since the effort will need to be restarted from scratch.
- It is expected that this situation will change soon (within few months) and that progress on this port can be resumed.
Manuel A. Fernandez Montecelo (ManuelMontecelo)
- Also using personal computers and regular Debian infrastructure
- Created page of the port in the wiki
Unofficial repository (WIP, incomplete and probably not working for you at the moment): http://riscv.mit.edu/
To use it, in /etc/apt/sources.list:
deb [ arch=riscv64 signed-by=/usr/share/keyrings/debian-keyring.gpg ] http://riscv.mit.edu/debian unstable main deb-src [ signed-by=/usr/share/keyrings/debian-keyring.gpg ] http://riscv.mit.edu/debian unstable main
The repository is signed with the key from Manuel as Debian Developer, contained in the file /usr/share/keyrings/debian-keyring.gpg, which is part of the package debian-keyring (available from Debian and derivatives).
Not in Debian infrastructure at the moment, but when it is, follow instructions in: http://www.ports.debian.org/archive . Example:
deb http://ftp.ports.debian.org/debian-ports/ sid main deb http://ftp.ports.debian.org/debian-ports/ unreleased main deb-src http://ftp.ports.debian.org/debian-ports/ sid main
Mirrors (use them if possible, they may be closer to you): http://www.ports.debian.org/mirrors
buildd (build-daemon) information
NOT CREATED YET
Contact: buildd maintainers <firstname.lastname@example.org>
Stats graph: https://buildd.debian.org/stats/?arch=riscv64
Stats overview: https://buildd.debian.org/stats/riscv64.txt
Currently there are no porterboxes available. See the qemu section to install locally, if available.
Upstreaming of qemu support for RISC-V is currently work-in-progress; the code is available in the "qemu-upstream" branches at https://github.com/riscv/riscv-qemu/. In 2017-12 several major enhancements to qemu have been implemented, the most important being support for version 1.10 of the RISC-V privileged ISA specification, which allows running upstream kernels in qemu. The first supported system-emulation target was a spike-compatible board, which unfortunately doesn't support any block devices besides the initrd and doesn't have any networking support. There is now also a "virt" target that supports virtio block and network devices as well as a serial console.
The Linux kernel has a very useful "binfmt-misc" feature that allows to transparently run foreign-architecture user-mode binaries with qemu. Debian supports this out-of-the-box for the release architectures with the qemu-user-static package; riscv64-support can be added as follows:
Build a static qemu binary with support for user-mode emulation:
$ git clone https://github.com/riscv/riscv-qemu/ $ cd riscv-qemu $ ./configure --static --disable-system --target-list=riscv64-linux-user $ make $ sudo cp riscv64-linux-user/qemu-riscv64 /usr/bin/qemu-riscv64-static
Create a binfmt-support config file and register it:
$ cat >/tmp/qemu-riscv64 <<EOF package qemu-user-static type magic offset 0 magic \x7f\x45\x4c\x46\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xf3\x00 mask \xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff interpreter /usr/bin/qemu-riscv64-static EOF $ sudo update-binfmts --import /tmp/qemu-riscv64
With this it is now possibe to transparantly run user-mode riscv64 binaries on another architecture:
$ uname -m x86_64 $ file busybox busybox: ELF 64-bit LSB executable, UCB RISC-V, version 1 (SYSV), statically linked, for GNU/Linux 3.0.0, stripped $ ./busybox touch foo $ ls foo foo
This also works in chroots if the /usr/bin/qemu-riscv64-static binary is available inside the chroot.
For the use of qemu in the bootstrap process of other ports, please see
When support for RISC-V targets are added to gcc upstream and enabled in the relevant packages in Debian, they can be installed directly from the main Debian repositories:
# apt install gcc-riscv64-linux-gnu g++-riscv64-linux-gnu
irc.oftc.net / irc.debian.org (https://www.oftc.net/)
#debian-bootstrap (general port bootstrap efforts)
- #lowRISC (not exactly Debian specific, but many interested people within Debian participate)
- riscv64: all bugs related to the Debian riscv64 port
To: email@example.com Subject: foo: FTBFS on riscv64 Package: foo Version: 1.2.3-4 X-Debbugs-CC: firstname.lastname@example.org User: email@example.com Usertags: riscv64 The version of the package currently FBTFS on the riscv64 port: URL_of_the_log
To: firstname.lastname@example.org Subject: riscv64 usertags for #BUGNUMBER CC: email@example.com user firstname.lastname@example.org usertag BUGNUMBER + riscv64 stop
To: BUGNUMBER@bugs.debian.org Subject: Setting riscv64 usertags CC: email@example.com Control: user firstname.lastname@example.org Control: usertag -1 + riscv64