Differences between revisions 53 and 165 (spanning 112 versions)
Revision 53 as of 2018-04-09 20:32:37
Size: 28129
Editor: ?VagrantCascadian
Comment: mention qemu packages available on people.debian.org
Revision 165 as of 2022-09-26 13:02:44
Size: 41439
Comment: Nezha: manually install debian-ports-archive-keyring
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
This page contains details about a port of Debian for the RISC-V architecture called '''riscv64'''. This page contains details about a port of Debian for the RISC-V architecture called '''riscv64''', for 32 bit (riscv32) see [[RISC-V/32|32 bit RISC-V]].
Line 19: Line 19:
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).

See https://www.debian.org/ports/ and DebianPorts for more information.
In short, a '''''port''''' in Debian terminology means to provide the software normally available in the Debian archive (over 30,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).

See https://www.debian.org/ports/ and [[Ports]] for more information.
Line 26: Line 26:
 * Software-wise, this port will target the '''Linux''' kernel
 * Hardware-wise, the port will target the '''64-bit''' variant, '''little-endian'''
 * Software-wise, this port targets the '''Linux''' kernel
 * Hardware-wise, the port targets the '''64-bit''' variant, '''little-endian'''
Line 35: Line 35:
 * and 128 is simply not realistic at this time.  * A 128-bit port is simply not realistic at this time.

== Summary ==

See [[Ports/riscv64]].
Line 39: Line 43:
Percentage of packages that build on RISC-V (bottom right, grey line) Percentage of packages that build on RISC-V (grey line)
Line 43: Line 47:
= Upstream project / Architecture / Hardware = = Upstream project / Architecture =
Line 49: Line 53:
 * Mailing lists (''see below for Debian-specific''): https://riscv.org/mailing-lists/

 * IRC (''see below for Debian-specific''): #riscv (general RISC-V discussions) and #linux-riscv (RISC-V Linux kernel development) at [[https://freenode.net/|freenode]]
 * Mailing lists (''see below for Debian-specific''):
 
https://lists.riscv.org/g/main
 * IRC (''see below for Debian-specific''): #riscv (RISC-V discussions) at [[https://libera.chat/|Libera Chat]]
Line 56: Line 60:

== Hardware ==

=== FPGA implementations ===

There are freely available softcores which can be synthesized to an [[FPGA]], such as [[https://github.com/freechipsproject/rocket-chip|Rocket]], a 64-bit RISC-V in-order core (optionally including an MMU and an IEEE 754-2008-compliant FPU).

=== ASIC implementations, i.e. "real" CPU chips ===

 * At FOSDEM 2018, working production samples of the !SiFive "Freedom U540" SoC (quad-core RV64GC) and a corresponding development board ("!HiFive Unleashed") have been presented. As of February 2018, availability of a limited number of boards from the first production run is planned for March 2018; general availability is planned for end of June 2018.

 * For the future further RISC-V-based ASICs are expected, among them a SoC from the [[http://www.lowrisc.org/|lowRISC]] project, which has described itself as follows:
||||||<tablestyle="min-width: 90%; max-width: 90%; background-color: #dddddd; margin: auto; padding: 0.5em 2em; ">||
||~-"lowRISC is a not-for-profit organisation working closely with the University of Cambridge and the open-source community.<<BR>>lowRISC is creating a fully open-sourced, Linux-capable, RISC-V-based SoC, that can be used either directly or as the basis for a custom design. [...]<<BR>>Our open-source SoC (System-on-a-Chip) designs will be based on the 64-bit RISC-V instruction set architecture. Volume silicon manufacture is planned as is a low-cost development board. [...]"-~||
Line 76: Line 66:
 * linux kernel: upstreaming in progress (the architecture core code is in kernel 4.15; for full system support additional driver code is necessary which is planned to go into kernel 4.16/4.17)
 * gdb: not upstreamed yet
 * qemu: merged upstream, targets the 2.12 release. For more information about qemu please refer to the [[#Qemu|qemu]] section below.
 * linux kernel: upstreamed (the architecture core code went into kernel 4.15; kernel 4.19 contains all drivers necessary for booting a qemu "virt" system to userland)
 * gdb: upstreamed (8.3 is the first release with support for riscv*-*-linux* targets)
 * qemu: upstreamed (2.12 is the first release with RISC-V support)

= Hardware =

== ASIC implementations, i.e. "real" CPU chips ==

=== Lichee RV ===

[[https://www.cnx-software.com/2021/11/24/sipeed-licheerv-a-low-cost-allwinner-d1-linux-risc-v-board/|Released in late 2021]], based on Allwinner D1 with T-Head XuanTie C906. 512MB of RAM. Very inexpensive at approx 20€.

A carrier board adding HDMI, USB and optional WiFi [[https://www.cnx-software.com/2021/12/30/sipeed-lichee-rv-risc-v-module-gets-5-carrier-board-with-hdmi-and-usb-ports-optional-wifi/|became available later on]]. And later a 1GB version

Also available on [[https://www.seeedstudio.com/lichee-RV-Nezha-CM-Allwinner-D1-SoC-1-14-Inch-SPI-LCD-p-5254.html|Seeed]].

See details on [[InstallingDebianOn/Sipeed/LicheeRV]]

The Sunxi community (mainlining AllWinner SoCs features) wiki contains a [[https://linux-sunxi.org/Sipeed_Lichee_RV|page about Lichee RV]], with instructions to compiling Linux kernel and installing GNU/Linux distributions including Debian on the board.


=== Mango Pi MQ Pro ===

Based on Allwinner D1 with T-Head XuanTie C906 core at 1Ghz, there are 2 version, one with 512MB or ram, the other with 1GB. There is also [[https://www.cnx-software.com/2022/04/21/bga-socket-allows-ram-upgrades-on-sbcs/|a version with a BGA socket]].


=== Nezha ===

On [[https://www.indiegogo.com/projects/nezha-your-first-64bit-risc-v-linux-sbc-for-iot|IndieGoGo]]

Based on Allwinner D1 with T-Head XuanTie C906 core at 1Ghz

{{{
# apt-get update
...
"The following signatures couldn't be verified because the public key is not available..."
}}}

You need to download https://www.ports.debian.org/archive_2022.key
{{{
# apt-key add archive_2022.key
}}}

Or manually download and install [[https://packages.debian.org/sid/all/debian-ports-archive-keyring/download | debian-ports-archive-keyring]]. This way the key can be updated via apt when it has to be replaced.

Now you can run # apt-get update

=== SiFive "Freedom U540" SoC (quad-core RV64GC) / "HiFive Unleashed" ===

Instructions on how to install Debian on this hardware: [[InstallingDebianOn/SiFive/HiFiveUnleashed]]

At FOSDEM 2018, working production samples of the !SiFive "Freedom U540" SoC (quad-core RV64GC) and a corresponding development board ("!HiFive Unleashed") have been presented. A limited number of boards from the first production run has been made available in February 2018, a second production run has been done in June 2018.

=== Microchip "PolarFire SoC FPGA" / "PolarFire SoC FPGA Icicle Kit" (MPFS-ICICLE-KIT-ES) ===

Microchip offers the "Polarfire SoC FPGA" (quad-core RV64GC plus an integrated FPGA) and a corresponding development board (the "Icicle Kit") with 2GB of RAM, SD/eMMC, a PCIe slot, Gigabit Ethernet and various further I/O.

=== SiFive "Freedom U740" SoC / "HiFive Unmatched" ===
!SiFive "!HiFive Unmatched" is a Mini-ITX board with a "Freedom U740" SoC (quad-core RV64GC), 16GB of RAM, SD, a PCIe slot, Gigabit Ethernet, an M.2 socket for an NVMe SSD and various further I/O.
More info here: https://www.sifive.com/boards/hifive-unmatched

Instructions on how to install Debian on this hardware: [[InstallingDebianOn/SiFive/HiFiveUnmatched]]

As of Q1/2022, the Freedom U740 Unmatched board is no longer available and there are no plans to make additional boards. See: https://forums.sifive.com/t/sifive-update-on-hifive-unmatched-boards-in-2022/5569
It is possible that used boards may be obtained.


=== StarFive "JH7100" SoC / BeagleBoard+Seedstudio+StarFive "BeagleV" board ===

Developer samples of the BeagleV single board computer became available in Q2/2021. Production models were planned to become available end of Q3/2021 or start of Q4/2021, but the project has been cancelled.

=== StarFive "JH7100" SoC / "VisionFive" board ===

Released in December 2021, this board is similar to the cancelled "BeagleV" board. It also includes special hardware for computer vision applications. It is [[https://shop.allnetchina.cn/products/starfive-visionfive-ai-single-board-computer|available for purchase]].

Instructions on how to install Debian on this hardware: [[InstallingDebianOn/StarFive/VisionFiveV1]]

=== Planned ===

In the future further RISC-V-based ASICs are expected, among them a SoC from the [[http://www.lowrisc.org/|lowRISC]] project, which has described itself as follows:
||||||<tablestyle="min-width: 90%; max-width: 90%; background-color: #dddddd; margin: auto; padding: 0.5em 2em; ">||
||~-"lowRISC is a not-for-profit organisation working closely with the University of Cambridge and the open-source community.<<BR>>lowRISC is creating a fully open-sourced, Linux-capable, RISC-V-based SoC, that can be used either directly or as the basis for a custom design. [...]<<BR>>Our open-source SoC (System-on-a-Chip) designs will be based on the 64-bit RISC-V instruction set architecture. Volume silicon manufacture is planned as is a low-cost development board. [...]"-~||

== FPGA implementations ==

There are freely available softcores which can be synthesized to an [[FPGA]], such as [[https://github.com/freechipsproject/rocket-chip|Rocket]], a 64-bit RISC-V in-order core (optionally including an MMU and an IEEE 754-2008-compliant FPU).
Line 107: Line 180:
Submitting a new bug:
Line 113: Line 188:
Severity: important
Line 117: Line 193:
The version of the package currently FBTFS on the riscv64 port: The version of the package currently FTBFS on the riscv64 port:
Line 122: Line 198:
or Tagging an existing bug: (Don't use Control: user/usertag or User:/Usertag: to `BUGNUMBER@bugs.debian.org`, because [[https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798122|they don't work]].)
Line 134: Line 210:
or

{{{
To: BUGNUMBER@bugs.debian.org
Subject: Setting riscv64 usertags
CC: debian-riscv@lists.debian.org

Control: user debian-riscv@lists.debian.org
Control: usertag -1 + riscv64
}}}
=== FTBFS, packages that Fail To Build From Source (in riscv64) ===

Breno Leitão or other people from his team (ppc64el) created the following script, which lists packages that currently fail to build in riscv64, classifying them by number of arches in which it fails (e.g. only in riscv64 or in more than this one) or if there are pending patches or not, etc.; and with links to several related places handy to have (e.g. build logs, BTS).

So it's a nice place to start looking at things that need to be fixed.

 * https://udd.debian.org/cgi-bin/ftbfs.cgi?arch=riscv64
Line 149: Line 222:
Since 2018-03-23 both gcc-7-based as well as gcc-8-based cross-toolchains targeting riscv64 are available in unstable. These include glibc and related basic libraries for riscv64 in arch:all packages. As those packages use different library paths than the corresponding "native" (i.e. arch:riscv64) packages and don't include some of the configuration that is part of their "native" counterparts, making full use of them for building packages in a multiarch configuration requires the following steps: Since buster cross-toolchains targeting riscv64 are available in Debian. These include glibc and related basic libraries for riscv64 in arch:all packages. As those packages use different library paths than the corresponding "native" (i.e. arch:riscv64) packages and don't include some of the configuration that is part of their "native" counterparts, making full use of them for building packages in a multiarch configuration requires the following steps:
Line 154: Line 227:
$ sudo cat >/etc/ld.so.conf.d/riscv64-linux-gnu.conf <<EOF $ sudo sh -c "cat >/etc/ld.so.conf.d/riscv64-linux-gnu.conf <<EOF
Line 160: Line 233:
"
Line 161: Line 235:
}}}

=== Using pre-built toolchains with sbuild ===

While crossbuild-essential-riscv64 is not yet present, you can ask
sbuild to instead install the cross-build dependencies explicitly.
Add the following to ~/.sbuildrc:

{{{
$crossbuild_core_depends = {
riscv64 => ['gcc-riscv64-linux-gnu:native', 'g++-riscv64-linux-gnu:native', 'dpkg-cross:native'],
};
}}}

And then run sbuild:

{{{
sbuild --build=amd64 --profiles=cross --host=riscv64
Line 170: Line 262:
$ git clone https://anonscm.debian.org/git/users/helmutg/rebootstrap.git $ git clone https://salsa.debian.org/helmutg/rebootstrap.git
Line 172: Line 264:
$ mkdir -p /tmp/repo && sudo pbuilder execute --bindmounts /tmp/repo bootstrap.sh HOST_ARCH=riscv64 REPODIR=/tmp/repo GCC_VER=7 $ mkdir -p /tmp/repo && sudo pbuilder execute --bindmounts /tmp/repo bootstrap.sh HOST_ARCH=riscv64 REPODIR=/tmp/repo
Line 177: Line 269:
Rebootstrap supports building gcc-7-based and gcc-8-based cross-toolchains; just set the "GCC_VER" parameter accordingly. After the build process has finished, you can find a repository with a cross-toolchain and a number of cross-built packages in /tmp/repo. Don't worry when rebootstrap stops the build process with an error - that is expected as rebootstrap tries to build further packages after the toolchain is ready and some of those don't yet properly cross-build for riscv64. After the build process has finished, you can find a repository with a cross-toolchain and a number of cross-built packages in /tmp/repo. Don't worry when rebootstrap stops the build process with an error - that is expected as rebootstrap tries to build further packages after the toolchain is ready and some of those don't yet properly cross-build for riscv64.
Line 183: Line 275:
Starting from 2018-03-09, [[https://git.qemu.org/?p=qemu.git|upstream qemu git]] contains RISC-V support. In system-emulation mode, it implements a "virt" board that allows running upstream kernels with virtio block and network devices and a serial console, and a "spike"-compatible board.

DebianBug:893767 has been filed to enable riscv64 targets.

A limited set of packages are available, including qemu-system-misc and qemu-user-static with riscv64 enabled, until the packaging is included in Debian:

{{{
 deb https://people.debian.org/~vagrant/debian-riscv64 UNRELEASED main
}}}

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 DebianPkg:qemu-user-static package; riscv64-support can be added as follows:

Build a static qemu binary with support for user-mode emulation:
Since buster RISC-V support is available in the qemu packages in unstable.

In system-emulation mode, qemu implements a "virt" board that allows running upstream kernels with virtio block and network devices and a serial console, and a "spike"-compatible board. For user-mode emulation, the the Linux kernel provides a very useful "binfmt-misc" feature that allows to transparently run foreign-architecture user-mode binaries with qemu.

=== Installing qemu from the Debian archive ===

For using full system-emulation install the DebianPkg:qemu-system-misc package, for transparent user-mode emulation (e.g. in a chroot) install the DebianPkg:binfmt-support and DebianPkg:qemu-user-static packages.

{{{
  apt install qemu-system-misc qemu-user-static binfmt-support
}}}

=== Manual qemu-user installation ===

If you don't want to use the Debian qemu packages, a static qemu for user-mode emulation can be built from upstream git as follows:
Line 237: Line 332:
== Package repositories ==

=== Debian-Ports Repositor
y ===

The Debian-Ports repository is now the main package repository for the Debian riscv64 port - unless there are special circumstances, this is the repository that should be used as the base for further work on the port. A basic set of riscv64 packages has been imported into Debian-Ports on the weekend of 2018-03-24/25 and there are [[#buildd (build-daemon) information|autobuilders]] running to keep the repository up-to-date.
== Package repository ==

The Debian-Ports repository is the main package repository for the Debian riscv64 port - unless there are special circumstances, this is the repository that should be used as the base for further work on the port. A basic set of riscv64 packages has been imported into Debian-Ports on the weekend of 2018-03-24/25 and there are [[#buildd (build-daemon) information|autobuilders]] running to keep the repository up-to-date.
Line 245: Line 338:
 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 are available (please use them if possible): https://www.ports.debian.org/mirrors

==== Creating a riscv64 chroot from the Debian-Ports repository ====

Currently there are still a number of RISC-V-specific patches for essential packages that are only available in the "unreleased" suite, but not in the "unstable" suite. This poses a problem when trying to use debootstrap to build a riscv64 chroot due to the fact that debootstrap can only use one single suite as its package source. For the time being, the easiest way to create a very bare-bones riscv64 chroot is the use of multistrap. In comparison to debootstrap, multistrap has the limitations of only working on Debian systems while debootstrap is designed to be distribution-agnostic, and several of the configuration options that debootstrap provides don't have a direct equivalent in multistrap.

To build a bare-bones riscv64 chroot on a Debian/unstable system of a different architecture, perform the following steps:

{{{
$ sudo apt-get install multistrap debian-ports-archive-keyring
$ cat >/tmp/multistrap-riscv64.conf <<EOF
[General]
arch=riscv64
aptsources=Unstable Unreleased Sid-main
bootstrap=Unstable Unreleased Sid-main

[Sid-main]
source=http://deb.debian.org/debian
suite=unstable
omitdebsrc=true
keyring=debian-archive-keyring

[Unstable]
source=http://deb.debian.org/debian-ports
suite=unstable
omitdebsrc=true
keyring=debian-ports-archive-keyring

[Unreleased]
source=http://deb.debian.org/debian-ports
suite=unreleased
omitdebsrc=true
 deb http://deb.debian.org/debian-ports sid main
 deb http://deb.debian.org/debian-ports unreleased main
 deb-src http://deb.debian.org/debian sid main
}}}

After adding above Debian-Ports repository and before running `apt update`, you should install the DebianPackage:debian-ports-archive-keyring package to prevent the error " E: The repository 'http://deb.debian.org/debian-ports sid InRelease' is not signed."

Other mirrors are available: https://www.ports.debian.org/mirrors

For information about previously used historic package repositories please refer to the [[RISC-V/Attic|Attic]] page.

== Creating a riscv64 chroot ==

The "standard" way of creating a chroot in Debian is by running DebianPkg:debootstrap. Unfortunately debootstrap has one serious limitation, and that is that it can only work with a single suite (e.g. unstable). For riscv64 this has posed a problem for quite some time because there were a number of RISC-V-specific patches for packages that were only available in the "unreleased" suite, but not in the "unstable" suite. Therefore for a long time debootstrap couldn't create a fully-working riscv64 chroot of the type "standard", although creating chroots of the types "minbase" and "buildd" worked, but since 2019-05-29 everything that is required for creating a chroot of type "standard" with debootstrap is now available in unstable.

An alternative to DebianPkg:debootstrap is DebianPkg:mmdebstrap, which can create a chroot from packages distributed over multiple suites while providing a largely debootstrap-compatible user interface. Unless there are specific reasons for using debootstrap, the use of mmdebstrap is therefore recommended.

=== mmdebstrap ===

To create a riscv64 chroot in /tmp/riscv64-chroot with mmdebstrap, perform the following steps:

{{{
$ sudo apt install mmdebstrap qemu-user-static binfmt-support debian-ports-archive-keyring
$ sudo mmdebstrap --architectures=riscv64 --include="debian-ports-archive-keyring" sid /tmp/riscv64-chroot "deb http://deb.debian.org/debian-ports sid main" "deb http://deb.debian.org/debian-ports unreleased main"
}}}

=== debootstrap ===

To create a "standard" chroot in /tmp/riscv64-chroot with debootstrap, execute the following commands:

{{{
sudo apt-get install debootstrap qemu-user-static binfmt-support debian-ports-archive-keyring
sudo debootstrap --arch=riscv64 --keyring /usr/share/keyrings/debian-ports-archive-keyring.gpg --include=debian-ports-archive-keyring unstable /tmp/riscv64-chroot http://deb.debian.org/debian-ports
}}}

=== Preparing the chroot for use in a virtual machine ===
After a basic chroot has been created in /tmp/riscv64-chroot, some further steps are necessary to prepare it as the base for a virtual machine:

{{{
$ sudo chroot /tmp/riscv64-chroot
# Update package information
apt-get update
# Set up basic networking
cat >>/etc/network/interfaces <<EOF
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp
Line 283: Line 388:
$ sudo multistrap -d /tmp/riscv64-chroot -f /tmp/multistrap-riscv64.conf
}}}

This provides a (very bare-bones) riscv64 chroot in /tmp/riscv64-chroot. Performing these steps on a Debian/stable system requires installing the debian-ports-archive-keyring package from unstable beforehand.

=== Cross-bootstrap repository, based on upstream gcc/glibc/kernel ===

A number of Debian packages that have been cross-built for riscv64 with a cross-toolchain based on upstream gcc/glibc/kernel are available in an [[https://people.debian.org/~merker/repositories/risc64-bootstrap-clean/|apt repository]]. This repository is work-in-progress, incomplete and packages in it may well be broken - use at your own risk! It targets Debian developers working on riscv64 support and cross-bootstrappability issues in Debian and is neither suitable nor intended for use by end-users.

For more detailed information, please read the [[https://people.debian.org/~merker/repositories/risc64-bootstrap-clean/README.riscv64-bootstrap|README.riscv64-bootstrap]] in the repository.


=== Historic repository, based on pre-upstream glibc/gcc/kernel ===

'''IMPORTANT NOTE: Due to ABI breaks during the kernel and glibc upstreaming process, the packages in this repository are ABI-incompatible with modern toolchains and modern kernels.'''

Unofficial repository (WIP, incomplete and probably not working for you at the moment): http://riscv.mit.edu/

See https://people.debian.org/~mafm/posts/2017/20170422_debian-gnulinux-port-for-risc-v-64-bit-riscv64/ for more details.

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).
# Set root password
passwd
# Disable the getty on hvc0 as hvc0 and ttyS0 share the same console device in qemu.
ln -sf /dev/null /etc/systemd/system/serial-getty@hvc0.service
# Install kernel and bootloader infrastructure
apt-get install linux-image-riscv64 u-boot-menu
# Install and configure ntp tools
apt-get install openntpd ntpdate
sed -i 's/^DAEMON_OPTS="/DAEMON_OPTS="-s /' /etc/default/openntpd
# Configure syslinux-style boot menu
cat >>/etc/default/u-boot <<EOF
U_BOOT_PARAMETERS="rw noquiet root=/dev/vda1"
U_BOOT_FDT_DIR="noexist"
EOF
u-boot-update
exit
}}}

== Setting up a riscv64 virtual machine ==

 1. Install DebianPkg:qemu-system-misc, DebianPkg:opensbi and DebianPkg:u-boot-qemu from unstable.

 2. Create a [[#Creating_a_riscv64_chroot|chroot]].

 3. Create a disk image for qemu from the previously-created chroot in /tmp/riscv64-chroot with

 {{{
sudo apt-get install libguestfs-tools
sudo virt-make-fs --partition=gpt --type=ext4 --size=10G /tmp/riscv64-chroot/ rootfs.img
sudo chown ${USER} rootfs.img
 }}}

 6. Run qemu-system-riscv64 with OpenSBI, U-Boot and the disk image:

 {{{
qemu-system-riscv64 -nographic -machine virt -m 1.9G \
 -bios /usr/lib/riscv64-linux-gnu/opensbi/generic/fw_jump.elf \
 -kernel /usr/lib/u-boot/qemu-riscv64_smode/uboot.elf \
 -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-device,rng=rng0 \
 -append "console=ttyS0 rw root=/dev/vda1" \
 -device virtio-blk-device,drive=hd0 -drive file=rootfs.img,format=raw,id=hd0 \
 -device virtio-net-device,netdev=usernet -netdev user,id=usernet,hostfwd=tcp::22222-:22
 }}}

 This uses qemu's "usernet" implementation which provides the virtual machine with NATed network access to the outside and works without root privileges, but it is rather slow and doesn't support all network protocols (ICMP support is limited). The "hostfwd" parameter sets up a port forwarding from port 22222 on the host to port 22 inside the virtual machine so that it is possible to log into the VM from the host.
Line 320: Line 443:
Currently there are no porterboxes available. Please refer to the [[#Qemu|qemu section]] for installing a riscv64 virtual machine locally. Currently there are no porterboxes available. Please refer to the [[#Setting_up_a_riscv64_virtual_machine|"Setting up a riscv64 virtual machine"]] or [[#OS_.2F_filesystem_images|"OS / filesystem images"]] sections for installing a riscv64 virtual machine locally.

== OS / filesystem images ==

Experimental development images are [[https://people.debian.org/~gio/dqib/|created weekly by DQIB for RISC-V]], as well as for other Debian architectures. Please report bugs to [[GiovanniMascellani]].

There is also a minimal tarball that can be used for quick installation, at least as evaluation (signed with [[ManuelMontecelo]]'s key):

 * https://people.debian.org/~mafm/debian-riscv64-tarball-20180418.tar.xz (74MB)
  * https://people.debian.org/~mafm/debian-riscv64-tarball-20180418.tar.xz.sig
 * https://people.debian.org/~mafm/debian-riscv64-tarball-20180418.tar.gz (101MB)
  * https://people.debian.org/~mafm/debian-riscv64-tarball-20180418.tar.gz.sig
 * https://people.debian.org/~mafm/debian-riscv64-tarball-20180418.tar (185MB)
  * https://people.debian.org/~mafm/debian-riscv64-tarball-20180418.tar.sig

Once the file is downloaded and unpacked, for example in the "!HiFive Unleashed" Board (most or all operations need "root" from the main OS):

{{{
# mount 2nd partition of SD card
mount /dev/mmcblk0p2 /mnt

# unpack under /mnt
cd /mnt && tar xvf DOWNLOADED_TAR

# from the main OS, chroot into it
chroot /mnt/debian-riscv64-tarball-20180418 /bin/bash -l

# set date with good precision, recent versions of "apt" are strict about time validity of repositories, and remind the timezone differences!
date -s -d'2018-05-07T21:28:57'

# add some nameserver to /etc/resolv.conf, use a local one if you can
cat <<EOF > /etc/resolv.conf
nameserver 4.4.2.2
nameserver 8.8.8.8
EOF


# mount virtual filesystems
mount -t sysfs sysfs /sys/
mount -t proc proc /proc
mount -t devtmpfs udev /dev/
mkdir -p /dev/pts
mount -t devpts devpts /dev/pts
mount -t tmpfs tmpfs /run
mkdir -p /run/lock


# update apt and install software
#
# /etc/apt/sources.list has to be edited to point to "debian ports":
# https://wiki.debian.org/RISC-V#Debian-Ports_Repository
cat <<EOF > /etc/apt/sources.list
deb http://deb.debian.org/debian-ports sid main
deb http://deb.debian.org/debian-ports unreleased main
deb-src http://deb.debian.org/debian sid main
EOF

apt update
apt install emacs25-nox openssh-server

# (re)start openssh-server if necessary
service ssh restart

# log through ssh from another host, enjoy and be merry :-)

}}}

With this file unpacked one can easily create an image to use with Qemu or similar, but still an external kernel is needed.
Line 323: Line 513:

 2021-10-14 ::

 :: The Debian stock parts (kernel, u-boot-sifive, opensbi, ...), has been tested to work with real hardware (on HiFive Unmatched board).

 2019-08-06 ::

 :: A new kernel package (linux-image-5.2.0-1-riscv64) that includes a backport of the new RISC-V kernel image header from kernel 5.3 has entered unstable. Together with OpenSBI (in unstable) and u-boot-qemu (in experimental) this allows using syslinux-style menus in U-Boot and makes setting up a virtual riscv64 system a lot easier.

 2019-05-29 ::

 :: With version 0.176-1.1 elfutils has moved from unreleased to unstable which makes it now possible to use debootstrap to create a riscv64 chroot of type "standard".

 2019-05-17 ::

 :: DebianPkg:OpenSBI is now available from experimental.

 2019-05-12 ::

 :: U-Boot version 2019.07~rc1+dfsg-3 includes u-boot-sifive and u-boot-qemu package, which ship the sifive_fu540, qemu-riscv64, and qemu-riscv64_smode targets. The qemu-riscv64_smode target has been tested to work with qemu+[[https://bugs.debian.org/928724|opensbi]] to boot linux.

 2019-01-05 ::

 :: Starting with version 4.19.13-1, the regular Linux kernel packages in unstable have riscv64 support and provide a kernel image that can be booted in qemu. There has also been progress on the issue of debootstrapping a riscv64 system - while creating a "standard" chroot with debootstrap still fails due to an upstream issue in elfutils, it is now possible to use debootstrap for creating chroots in the "minbase" and "buildd" variants. As a result, sbuild now works out-of-the-box on riscv64.

 2018-12-11 ::

 :: Starting with version 3.2.1-9, DebianPkg:libffi6 contains a backport of the riscv64 support from the upstream libffi7 development repository. The Debian riscv64 port had originally used a libffi7 snapshot instead of libffi6 because libffi6 didn't have any RISC-V support at that time and libffi upstream had originally planned to release libffi7 in May 2018. Based on this release schedule, all Debian architectures would have moved to libffi7 before the Buster freeze. In the meantime the upstream libffi7 release has been deferred for an unknown amount of time and riscv64 support for libffi6 has become available. Therefore the Debian riscv64 port moves from using libffi7 to using libffi6 to bring it in line with the other Debian ports. Due to ABI differences between libffi6 and libffi7, the transition requires re-building all packages that link against libffi, which will cause some packages to be temporarily uninstallable.

 2018-09-13 ::

 :: A fix for the broken initrd handling in the Linux kernel has been [[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=96eddb810b146e4d364e35f38dc11d16680c66eb|committed]] to the upstream kernel git repository and will be part of the 4.19rc4 release. First versions of a patchset to support the qemu RISC-V "virt" board in u-boot have been [[https://lists.denx.de/pipermail/u-boot/2018-September/340634.html|posted]] to the upstream u-boot development list.

 2018-08-21 ::

 :: The last driver bits required for booting the mainline kernel to userland on a qemu "virt" machine have been [[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1009aa1205c2c5e9101437dcadfa195708d863bf|merged]] during the Linux 4.19 merge window. It is now possible to build a working kernel directly from upstream git without any additional patches. Please note that this currently only works for a "static" kernel, i.e. without initrd. Initrd support requires an additional patch that is [[https://lists.infradead.org/pipermail/linux-riscv/2018-August/001186.html|planned]] to go upstream later in the 4.19 development cycle.

 2018-08-04 ::

 :: Debian 9.5 has been released on 2018-07-14 and dak now accepts packages with riscv64 in their control file. As a result, a number of essential packages have been moved from the "unreleased" to the "unstable" suite and it is now possible to use debootstrap to create a "minbase" riscv64 chroot.

 2018-06-29 ::

 :: The dpkg/stable update that is necessary to make dak accept packages which explicitly list riscv64 in their control file has been [[https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890791#88|accepted]] into stable-proposed-updates and will be part of the upcoming 9.5 stable release. Once the 9.5 release is out and the system running dak has been updated accordingly, it will be possible to move essential packages like linux and glibc from unreleased to unstable and thereby enable the use of debootstrap for riscv64.

 2018-04-26 ::

 :: Qemu 2.12 with RISC-V support has been [[https://wiki.qemu.org/ChangeLog/2.12|released]] on 2018-04-24.

 2018-04-14 ::

 :: Qemu 2.12rc3 with RISC-V support has been uploaded to unstable on 2018-04-12.

This page contains details about a port of Debian for the RISC-V architecture called riscv64, for 32 bit (riscv32) see 32 bit RISC-V.

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.

In contrast to most ISAs, RISC-V is freely available for all types of use, permitting anyone to design, manufacture and sell RISC-V chips and software. While not the first open ISA, it is significant because it is designed to be useful in modern computerized devices such as warehouse-scale cloud computers, high-end mobile phones and the smallest embedded systems. Such uses demand that the designers consider both performance and power efficiency. The instruction set also has a substantial body of supporting software, which fixes the usual weakness of new instruction sets.

The project was originated in 2010 by researchers in the Computer Science Division at UC Berkeley, but many contributors are volunteers and industry workers that are unaffiliated with the university.

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 30,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).

See https://www.debian.org/ports/ and Ports for more information.

What are the goals of this project in particular?

In this project the goal is to have Debian ready to install and run on systems implementing a variant of the RISC-V ISA:

  • Software-wise, this port targets the Linux kernel

  • Hardware-wise, the port targets the 64-bit variant, little-endian

This 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;
  • A 128-bit port is simply not realistic at this time.

Summary

See Ports/riscv64.

Progress

Percentage of packages that build on RISC-V (grey line)

progress chart

Upstream project / Architecture

Upstream project / Community

Architecture details

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: upstreamed (2.27 is the first release with RISC-V support)
  • linux kernel: upstreamed (the architecture core code went into kernel 4.15; kernel 4.19 contains all drivers necessary for booting a qemu "virt" system to userland)
  • gdb: upstreamed (8.3 is the first release with support for riscv*-*-linux* targets)
  • qemu: upstreamed (2.12 is the first release with RISC-V support)

Hardware

ASIC implementations, i.e. "real" CPU chips

Lichee RV

Released in late 2021, based on Allwinner D1 with T-Head ?XuanTie C906. 512MB of RAM. Very inexpensive at approx 20€.

A carrier board adding HDMI, USB and optional WiFi became available later on. And later a 1GB version

Also available on Seeed.

See details on InstallingDebianOn/Sipeed/LicheeRV

The Sunxi community (mainlining ?AllWinner ?SoCs features) wiki contains a page about Lichee RV, with instructions to compiling Linux kernel and installing GNU/Linux distributions including Debian on the board.

Mango Pi MQ Pro

Based on Allwinner D1 with T-Head ?XuanTie C906 core at 1Ghz, there are 2 version, one with 512MB or ram, the other with 1GB. There is also a version with a BGA socket.

Nezha

On IndieGoGo

Based on Allwinner D1 with T-Head ?XuanTie C906 core at 1Ghz

# apt-get update
...
"The following signatures couldn't be verified because the public key is not available..."

You need to download https://www.ports.debian.org/archive_2022.key

# apt-key add archive_2022.key

Or manually download and install debian-ports-archive-keyring. This way the key can be updated via apt when it has to be replaced.

Now you can run # apt-get update

SiFive "Freedom U540" SoC (quad-core RV64GC) / "HiFive Unleashed"

Instructions on how to install Debian on this hardware: InstallingDebianOn/SiFive/HiFiveUnleashed

At FOSDEM 2018, working production samples of the SiFive "Freedom U540" SoC (quad-core RV64GC) and a corresponding development board ("HiFive Unleashed") have been presented. A limited number of boards from the first production run has been made available in February 2018, a second production run has been done in June 2018.

Microchip "PolarFire SoC FPGA" / "PolarFire SoC FPGA Icicle Kit" (MPFS-ICICLE-KIT-ES)

Microchip offers the "Polarfire SoC FPGA" (quad-core RV64GC plus an integrated FPGA) and a corresponding development board (the "Icicle Kit") with 2GB of RAM, SD/eMMC, a PCIe slot, Gigabit Ethernet and various further I/O.

SiFive "Freedom U740" SoC / "HiFive Unmatched"

SiFive "HiFive Unmatched" is a Mini-ITX board with a "Freedom U740" SoC (quad-core RV64GC), 16GB of RAM, SD, a PCIe slot, Gigabit Ethernet, an M.2 socket for an NVMe SSD and various further I/O. More info here: https://www.sifive.com/boards/hifive-unmatched

Instructions on how to install Debian on this hardware: InstallingDebianOn/SiFive/HiFiveUnmatched

As of Q1/2022, the Freedom U740 Unmatched board is no longer available and there are no plans to make additional boards. See: https://forums.sifive.com/t/sifive-update-on-hifive-unmatched-boards-in-2022/5569 It is possible that used boards may be obtained.

StarFive "JH7100" SoC / BeagleBoard+Seedstudio+StarFive "BeagleV" board

Developer samples of the BeagleV single board computer became available in Q2/2021. Production models were planned to become available end of Q3/2021 or start of Q4/2021, but the project has been cancelled.

StarFive "JH7100" SoC / "VisionFive" board

Released in December 2021, this board is similar to the cancelled "BeagleV" board. It also includes special hardware for computer vision applications. It is available for purchase.

Instructions on how to install Debian on this hardware: InstallingDebianOn/StarFive/VisionFiveV1

Planned

In the future further RISC-V-based ASICs are expected, among them a SoC from 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.
lowRISC is creating a fully open-sourced, Linux-capable, RISC-V-based SoC, that can be used either directly or as the basis for a custom design. [...]
Our open-source SoC (System-on-a-Chip) designs will be based on the 64-bit RISC-V instruction set architecture. Volume silicon manufacture is planned as is a low-cost development board. [...]"

FPGA implementations

There are freely available softcores which can be synthesized to an FPGA, such as Rocket, a 64-bit RISC-V in-order core (optionally including an MMU and an IEEE 754-2008-compliant FPU).

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".

Resources

Mailing list

IRC

  • irc.oftc.net / irc.debian.org (https://www.oftc.net/)

    • #debian-riscv
    • #debian-bootstrap (general port bootstrap efforts)

    • #lowRISC (not exactly Debian specific, but many interested people within Debian participate)

Bugs (BTS)

Submitting a new bug:

To: submit@bugs.debian.org
Subject: foo: FTBFS on riscv64

Package: foo
Version: 1.2.3-4
Severity: important
X-Debbugs-CC: debian-riscv@lists.debian.org
User: debian-riscv@lists.debian.org
Usertags: riscv64

The version of the package currently FTBFS on the riscv64 port:

  URL_of_the_log

Tagging an existing bug: (Don't use Control: user/usertag or User:/Usertag: to BUGNUMBER@bugs.debian.org, because they don't work.)

To: control@bugs.debian.org
Subject: riscv64 usertags for #BUGNUMBER
CC: debian-riscv@lists.debian.org

user debian-riscv@lists.debian.org
usertag BUGNUMBER + riscv64
stop

FTBFS, packages that Fail To Build From Source (in riscv64)

Breno Leitão or other people from his team (ppc64el) created the following script, which lists packages that currently fail to build in riscv64, classifying them by number of arches in which it fails (e.g. only in riscv64 or in more than this one) or if there are pending patches or not, etc.; and with links to several related places handy to have (e.g. build logs, BTS).

So it's a nice place to start looking at things that need to be fixed.

Cross compilation

Pre-built toolchains

Since buster cross-toolchains targeting riscv64 are available in Debian. These include glibc and related basic libraries for riscv64 in arch:all packages. As those packages use different library paths than the corresponding "native" (i.e. arch:riscv64) packages and don't include some of the configuration that is part of their "native" counterparts, making full use of them for building packages in a multiarch configuration requires the following steps:

$ sudo dpkg --add-architecture riscv64
$ sudo apt-get install gcc-riscv64-linux-gnu g++-riscv64-linux-gnu
$ sudo sh -c "cat >/etc/ld.so.conf.d/riscv64-linux-gnu.conf <<EOF
/usr/local/lib/riscv64-linux-gnu
/lib/riscv64-linux-gnu
/usr/lib/riscv64-linux-gnu
/usr/riscv64-linux-gnu/lib/
EOF
"
$ sudo ln -s /usr/riscv64-linux-gnu/lib/ld-linux-riscv64-lp64d.so.1 /lib

Using pre-built toolchains with sbuild

While crossbuild-essential-riscv64 is not yet present, you can ask sbuild to instead install the cross-build dependencies explicitly. Add the following to ~/.sbuildrc:

$crossbuild_core_depends = {
riscv64 => ['gcc-riscv64-linux-gnu:native', 'g++-riscv64-linux-gnu:native', 'dpkg-cross:native'],              
};

And then run sbuild:

sbuild --build=amd64 --profiles=cross --host=riscv64

Building a toolchain with rebootstrap

Another option of getting a Debian multiarch-capable cross-toolchain for riscv64 is to build one locally with rebootstrap:

$ sudo apt-get install pbuilder
$ sudo pbuilder create --distribution unstable
$ git clone https://salsa.debian.org/helmutg/rebootstrap.git
$ cd rebootstrap
$ mkdir -p /tmp/repo && sudo pbuilder execute --bindmounts /tmp/repo bootstrap.sh HOST_ARCH=riscv64 REPODIR=/tmp/repo

As pbuilder works in a throwaway chroot and deletes it again after it has finished, it is important to bind-mount the directory into which the created packages are to be placed ("/tmp/repo" in the example above) from the host filesystem into the chroot, as otherwise the freshly built packages would be deleted again when pbuilder removes the throwaway chroot. This can be achieved by either passing a "--bindmounts" parameter to pbuilder as above or by adding a BINDMOUNTS entry to pbuilderrc.

After the build process has finished, you can find a repository with a cross-toolchain and a number of cross-built packages in /tmp/repo. Don't worry when rebootstrap stops the build process with an error - that is expected as rebootstrap tries to build further packages after the toolchain is ready and some of those don't yet properly cross-build for riscv64.

Please note that you have to delete the repository directory ("/tmp/repo" in the example above) if you want to re-run rebootstrap as rebootstrap currently doesn't properly handle a pre-filled repository directory.

Qemu

Since buster RISC-V support is available in the qemu packages in unstable.

In system-emulation mode, qemu implements a "virt" board that allows running upstream kernels with virtio block and network devices and a serial console, and a "spike"-compatible board. For user-mode emulation, the the Linux kernel provides a very useful "binfmt-misc" feature that allows to transparently run foreign-architecture user-mode binaries with qemu.

Installing qemu from the Debian archive

For using full system-emulation install the qemu-system-misc package, for transparent user-mode emulation (e.g. in a chroot) install the binfmt-support and qemu-user-static packages.

  apt install qemu-system-misc qemu-user-static binfmt-support

Manual qemu-user installation

If you don't want to use the Debian qemu packages, a static qemu for user-mode emulation can be built from upstream git as follows:

$ git clone https://git.qemu.org/git/qemu.git
$ cd 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

Package repository

The Debian-Ports repository is the main package repository for the Debian riscv64 port - unless there are special circumstances, this is the repository that should be used as the base for further work on the port. A basic set of riscv64 packages has been imported into Debian-Ports on the weekend of 2018-03-24/25 and there are autobuilders running to keep the repository up-to-date.

For accessing the Debian-Ports repository, please follow the instructions at https://www.ports.debian.org/archive. Example /etc/apt/sources.list:

 deb http://deb.debian.org/debian-ports sid main
 deb http://deb.debian.org/debian-ports unreleased main
 deb-src http://deb.debian.org/debian sid main

After adding above Debian-Ports repository and before running apt update, you should install the debian-ports-archive-keyring package to prevent the error " E: The repository 'http://deb.debian.org/debian-ports sid ?InRelease' is not signed."

Other mirrors are available: https://www.ports.debian.org/mirrors

For information about previously used historic package repositories please refer to the Attic page.

Creating a riscv64 chroot

The "standard" way of creating a chroot in Debian is by running debootstrap. Unfortunately debootstrap has one serious limitation, and that is that it can only work with a single suite (e.g. unstable). For riscv64 this has posed a problem for quite some time because there were a number of RISC-V-specific patches for packages that were only available in the "unreleased" suite, but not in the "unstable" suite. Therefore for a long time debootstrap couldn't create a fully-working riscv64 chroot of the type "standard", although creating chroots of the types "minbase" and "buildd" worked, but since 2019-05-29 everything that is required for creating a chroot of type "standard" with debootstrap is now available in unstable.

An alternative to debootstrap is mmdebstrap, which can create a chroot from packages distributed over multiple suites while providing a largely debootstrap-compatible user interface. Unless there are specific reasons for using debootstrap, the use of mmdebstrap is therefore recommended.

mmdebstrap

To create a riscv64 chroot in /tmp/riscv64-chroot with mmdebstrap, perform the following steps:

$ sudo apt install mmdebstrap qemu-user-static binfmt-support debian-ports-archive-keyring
$ sudo mmdebstrap --architectures=riscv64 --include="debian-ports-archive-keyring" sid /tmp/riscv64-chroot "deb http://deb.debian.org/debian-ports sid main" "deb http://deb.debian.org/debian-ports unreleased main"

debootstrap

To create a "standard" chroot in /tmp/riscv64-chroot with debootstrap, execute the following commands:

sudo apt-get install debootstrap qemu-user-static binfmt-support debian-ports-archive-keyring
sudo debootstrap --arch=riscv64 --keyring /usr/share/keyrings/debian-ports-archive-keyring.gpg --include=debian-ports-archive-keyring unstable /tmp/riscv64-chroot http://deb.debian.org/debian-ports

Preparing the chroot for use in a virtual machine

After a basic chroot has been created in /tmp/riscv64-chroot, some further steps are necessary to prepare it as the base for a virtual machine:

$ sudo chroot /tmp/riscv64-chroot
# Update package information
apt-get update
# Set up basic networking
cat >>/etc/network/interfaces <<EOF
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp
EOF
# Set root password
passwd
# Disable the getty on hvc0 as hvc0 and ttyS0 share the same console device in qemu.
ln -sf /dev/null /etc/systemd/system/serial-getty@hvc0.service  
# Install kernel and bootloader infrastructure
apt-get install linux-image-riscv64 u-boot-menu
# Install and configure ntp tools
apt-get install openntpd ntpdate
sed -i 's/^DAEMON_OPTS="/DAEMON_OPTS="-s /' /etc/default/openntpd
# Configure syslinux-style boot menu
cat >>/etc/default/u-boot <<EOF
U_BOOT_PARAMETERS="rw noquiet root=/dev/vda1"
U_BOOT_FDT_DIR="noexist"
EOF
u-boot-update
exit

Setting up a riscv64 virtual machine

  1. Install qemu-system-misc, opensbi and u-boot-qemu from unstable.

  2. Create a chroot.

  3. Create a disk image for qemu from the previously-created chroot in /tmp/riscv64-chroot with
    sudo apt-get install libguestfs-tools
    sudo virt-make-fs --partition=gpt --type=ext4 --size=10G /tmp/riscv64-chroot/ rootfs.img
    sudo chown ${USER} rootfs.img
  4. Run qemu-system-riscv64 with OpenSBI, U-Boot and the disk image:
    qemu-system-riscv64 -nographic -machine virt -m 1.9G \
     -bios /usr/lib/riscv64-linux-gnu/opensbi/generic/fw_jump.elf \
     -kernel /usr/lib/u-boot/qemu-riscv64_smode/uboot.elf \
     -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-device,rng=rng0 \
     -append "console=ttyS0 rw root=/dev/vda1" \
     -device virtio-blk-device,drive=hd0 -drive file=rootfs.img,format=raw,id=hd0 \
     -device virtio-net-device,netdev=usernet -netdev user,id=usernet,hostfwd=tcp::22222-:22
    This uses qemu's "usernet" implementation which provides the virtual machine with NATed network access to the outside and works without root privileges, but it is rather slow and doesn't support all network protocols (ICMP support is limited). The "hostfwd" parameter sets up a port forwarding from port 22222 on the host to port 22 inside the virtual machine so that it is possible to log into the VM from the host.

buildd (build-daemon) information

Porterboxes

Currently there are no porterboxes available. Please refer to the "Setting up a riscv64 virtual machine" or "OS / filesystem images" sections for installing a riscv64 virtual machine locally.

OS / filesystem images

Experimental development images are created weekly by DQIB for RISC-V, as well as for other Debian architectures. Please report bugs to GiovanniMascellani.

There is also a minimal tarball that can be used for quick installation, at least as evaluation (signed with ManuelMontecelo's key):

Once the file is downloaded and unpacked, for example in the "HiFive Unleashed" Board (most or all operations need "root" from the main OS):

# mount 2nd partition of SD card
mount /dev/mmcblk0p2 /mnt

# unpack under /mnt
cd /mnt && tar xvf DOWNLOADED_TAR

# from the main OS, chroot into it
chroot /mnt/debian-riscv64-tarball-20180418 /bin/bash -l

# set date with good precision, recent versions of "apt" are strict about time validity of repositories, and remind the timezone differences!
date -s -d'2018-05-07T21:28:57'

# add some nameserver to /etc/resolv.conf, use a local one if you can
cat <<EOF > /etc/resolv.conf
nameserver 4.4.2.2
nameserver 8.8.8.8
EOF


# mount virtual filesystems
mount -t sysfs sysfs /sys/
mount -t proc proc /proc
mount -t devtmpfs udev /dev/
mkdir -p /dev/pts
mount -t devpts devpts /dev/pts
mount -t tmpfs tmpfs /run
mkdir -p /run/lock


# update apt and install software
# 
# /etc/apt/sources.list has to be edited to point to "debian ports":
# https://wiki.debian.org/RISC-V#Debian-Ports_Repository
cat <<EOF > /etc/apt/sources.list
deb http://deb.debian.org/debian-ports sid main
deb http://deb.debian.org/debian-ports unreleased main
deb-src http://deb.debian.org/debian sid main
EOF

apt update
apt install emacs25-nox openssh-server

# (re)start openssh-server if necessary
service ssh restart

# log through ssh from another host, enjoy and be merry :-)

With this file unpacked one can easily create an image to use with Qemu or similar, but still an external kernel is needed.

Status Log

2021-10-14

The Debian stock parts (kernel, u-boot-sifive, opensbi, ...), has been tested to work with real hardware (on ?HiFive Unmatched board).

2019-08-06
A new kernel package (linux-image-5.2.0-1-riscv64) that includes a backport of the new RISC-V kernel image header from kernel 5.3 has entered unstable. Together with OpenSBI (in unstable) and u-boot-qemu (in experimental) this allows using syslinux-style menus in U-Boot and makes setting up a virtual riscv64 system a lot easier.
2019-05-29
With version 0.176-1.1 elfutils has moved from unreleased to unstable which makes it now possible to use debootstrap to create a riscv64 chroot of type "standard".
2019-05-17

OpenSBI is now available from experimental.

2019-05-12

U-Boot version 2019.07~rc1+dfsg-3 includes u-boot-sifive and u-boot-qemu package, which ship the sifive_fu540, qemu-riscv64, and qemu-riscv64_smode targets. The qemu-riscv64_smode target has been tested to work with qemu+opensbi to boot linux.

2019-01-05
Starting with version 4.19.13-1, the regular Linux kernel packages in unstable have riscv64 support and provide a kernel image that can be booted in qemu. There has also been progress on the issue of debootstrapping a riscv64 system - while creating a "standard" chroot with debootstrap still fails due to an upstream issue in elfutils, it is now possible to use debootstrap for creating chroots in the "minbase" and "buildd" variants. As a result, sbuild now works out-of-the-box on riscv64.
2018-12-11

Starting with version 3.2.1-9, libffi6 contains a backport of the riscv64 support from the upstream libffi7 development repository. The Debian riscv64 port had originally used a libffi7 snapshot instead of libffi6 because libffi6 didn't have any RISC-V support at that time and libffi upstream had originally planned to release libffi7 in May 2018. Based on this release schedule, all Debian architectures would have moved to libffi7 before the Buster freeze. In the meantime the upstream libffi7 release has been deferred for an unknown amount of time and riscv64 support for libffi6 has become available. Therefore the Debian riscv64 port moves from using libffi7 to using libffi6 to bring it in line with the other Debian ports. Due to ABI differences between libffi6 and libffi7, the transition requires re-building all packages that link against libffi, which will cause some packages to be temporarily uninstallable.

2018-09-13

A fix for the broken initrd handling in the Linux kernel has been committed to the upstream kernel git repository and will be part of the 4.19rc4 release. First versions of a patchset to support the qemu RISC-V "virt" board in u-boot have been posted to the upstream u-boot development list.

2018-08-21

The last driver bits required for booting the mainline kernel to userland on a qemu "virt" machine have been merged during the Linux 4.19 merge window. It is now possible to build a working kernel directly from upstream git without any additional patches. Please note that this currently only works for a "static" kernel, i.e. without initrd. Initrd support requires an additional patch that is planned to go upstream later in the 4.19 development cycle.

2018-08-04
Debian 9.5 has been released on 2018-07-14 and dak now accepts packages with riscv64 in their control file. As a result, a number of essential packages have been moved from the "unreleased" to the "unstable" suite and it is now possible to use debootstrap to create a "minbase" riscv64 chroot.
2018-06-29

The dpkg/stable update that is necessary to make dak accept packages which explicitly list riscv64 in their control file has been accepted into stable-proposed-updates and will be part of the upcoming 9.5 stable release. Once the 9.5 release is out and the system running dak has been updated accordingly, it will be possible to move essential packages like linux and glibc from unreleased to unstable and thereby enable the use of debootstrap for riscv64.

2018-04-26

Qemu 2.12 with RISC-V support has been released on 2018-04-24.

2018-04-14
Qemu 2.12rc3 with RISC-V support has been uploaded to unstable on 2018-04-12.
2018-03-28

We have now both gcc-7-based as well as gcc-8-based cross-toolchains for riscv64 in unstable.

2018-03-23/24

Port added to debian-ports, the first automatic builds start to build packages after the initial seed of the minimal set.

2018-03-09

The upstream qemu maintainers have accepted the RISC-V patchset.

2018-03-04

The dpkg 1.18.25 update for stable that would (among other things) have made the riscv64 architecture known to dak - and thereby have allowed uploads of packages that mention riscv64 in their control file to the archive - has been rejected by the stable release managers. The rejection hasn't been because of the riscv64 support but because of other factors, but it means it will unfortunately still take some time before we will be able to upload a number of core packages (e.g. linux and glibc) with riscv64 support enabled to the main archive.

2018-02-27

A pull request to include RISC-V support into upstream qemu has been sent.

2018-02-19

Cross-binutils targeting RV64 are now available in unstable/testing and version 5 of the qemu upstreaming patchset has been posted to the qemu-devel mailinglist.

2018-02-05

Glibc 2.27 has been released with support for RV64. Support for RV32 hasn't been fully ready in time for the 2.27 release and will be added later on. A Debian package of glibc 2.27 has been uploaded to experimental.

Since version 1.19.0.5 dpkg includes support for the riscv64 architecture. Uploading of packages that reference riscv64 in their control file to the archive isn't yet possible though, as the Debian archive management software runs on Debian/stable and a corresponding stable update is still pending.

Version 4 of the qemu upstreaming patchset has been posted to the qemu-devel mailinglist.

2018-01-29
Support in glibc has been accepted and committed in the master branch, the release of glibc 2.27 should happen in the next few days.
Linux 4.15 was released a few days ago as well, with support for the userspace ABI needed by glibc. Drivers for this arch will be left for future releases, but ABI was the most important part.
2018-01-02

A first version of the qemu upstreaming patchset has been posted to the qemu-devel mailinglist.

2017-12-22

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.

2017-11-15

The pull request for the kernel has been accepted and the architecture-core patchset has been merged into the upstream kernel repository.

2017-11-13

A pull request for inclusion of the RISC-V architecture-core patchset into kernel 4.15 has been sent to Linus Torvalds.

2017-10-31

The RISC-V Linux kernel upstreaming patchset has been included into linux-next.

2017-10-05

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.

2017-09-17

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.

2017-07-30
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.
2017-06-14

The first version of an upstreaming patchset for glibc has been posted to the upstream glibc development list (libc-alpha).

2017-05-22

The first version of an upstreaming patchset for the Linux kernel has been posted to the upstream Linux kernel mailinglist.

2017-05-02

Upstream GCC 7.1 has been released with RISC-V support.

2017-04-22

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/

2017-03-04
Upstream binutils 2.28 have been released with RISC-V support on 2017-03-02.
2017-02-06

The GCC support for RISC-V has been committed to the upstream GCC repository and will be part of the GCC 7 release. Commit list: 1 2 3 4 5 6

2017-01-18
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.

2016-02-19
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.

Credits

Porters:

Hardware Sponsors:

  • Bytemark provides hardware to help to kick-start this port. Bytemark is a long-time partner of Debian

  • Also using personal computers and regular Debian infrastructure

History

2016-02-19
Created page of the port in the wiki


CategoryPorts