Size: 35340
Comment:
|
Size: 37070
Comment: OS "tarballs"
|
Deletions are marked like this. | Additions are marked like this. |
Line 64: | Line 64: |
* qemu: merged upstream, targets the 2.12 release. For more information about qemu please refer to the [[#Qemu|qemu]] section below. | * qemu: upstreamed (2.12 is the first release with RISC-V support) |
Line 246: | Line 246: |
== OS / filesystem images == There are no filesystem images yet ready to use with Qemu or other emulators. However, there is 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, recent versions of "apt" are strict about time ntpdate pool.ntp.org # 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 # start openssh-server 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 270: | Line 316: |
sudo apt-get install multistrap debian-ports-archive-keyring | sudo apt-get install multistrap debian-ports-archive-keyring qemu-user-static |
Line 463: | Line 509: |
2018-04-26 :: :: Qemu 2.12 with RISC-V support has been [[https://wiki.qemu.org/ChangeLog/2.12|released]] on 2018-04-24. |
This page contains details about a port of Debian for the RISC-V architecture called riscv64.
Contents
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).
See https://www.debian.org/ports/ and DebianPorts 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 will target the Linux kernel
Hardware-wise, the port will target 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;
- and 128 is simply not realistic at this time.
Progress
Percentage of packages that build on RISC-V (bottom right, grey line)
Upstream project / Architecture
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 (general RISC-V discussions) and #linux-riscv (RISC-V Linux kernel development) at freenode
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: 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: upstreamed (2.12 is the first release with RISC-V support)
Hardware
ASIC implementations, i.e. "real" CPU chips
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. 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.
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. |
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)
Usertags for user debian-riscv@lists.debian.org (UDD):
- riscv64: all bugs related to the Debian riscv64 port
bugs.debian.org/usertags examples:
To: submit@bugs.debian.org Subject: foo: FTBFS on riscv64 Package: foo Version: 1.2.3-4 X-Debbugs-CC: debian-riscv@lists.debian.org User: debian-riscv@lists.debian.org Usertags: riscv64 The version of the package currently FBTFS on the riscv64 port: URL_of_the_log
or
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
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
Cross compilation
Pre-built toolchains
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:
$ sudo dpkg --add-architecture riscv64 $ sudo apt-get install gcc-riscv64-linux-gnu g++-riscv64-linux-gnu $ sudo 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
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://anonscm.debian.org/git/users/helmutg/rebootstrap.git $ cd rebootstrap $ mkdir -p /tmp/repo && sudo pbuilder execute --bindmounts /tmp/repo bootstrap.sh HOST_ARCH=riscv64 REPODIR=/tmp/repo GCC_VER=7
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.
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.
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
Starting from 2018-03-09, upstream qemu git contains RISC-V support; since 2018-04-12 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
OS / filesystem images
There are no filesystem images yet ready to use with Qemu or other emulators.
However, there is 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.gz (101MB)
https://people.debian.org/~mafm/debian-riscv64-tarball-20180418.tar (185MB)
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, recent versions of "apt" are strict about time ntpdate pool.ntp.org # 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 # start openssh-server 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.
Package repositories
Debian-Ports Repository
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 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://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 directly from the Debian-Ports repository with multistrap
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 bare-bones riscv64 chroot is the use of multistrap. In comparison to debootstrap, multistrap has the limitation 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, you can perform the following steps, but you have to be extremely careful while doing that - various parts need to run with root permissions and if you e.g forget to export the CHROOT_PATH variable, you can end up with overwriting parts of your host system!
export CHROOT_PATH=/tmp/riscv64-chroot sudo apt-get install multistrap debian-ports-archive-keyring qemu-user-static cat >/tmp/multistrap-riscv64.conf <<EOF [General] arch=riscv64 aptsources=Unstable Unreleased Sid-main bootstrap=Unstable Unreleased Sid-main base-packages [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 [base-packages] packages=adduser apt base-files base-passwd bash bsdutils coreutils dash debconf debian-archive-keyring debian-ports-archive-keyring debianutils diffutils dpkg e2fsprogs fdisk findutils gcc-8-base gpgv grep gzip hostname init-system-helpers libacl1 libapt-pkg5.0 libattr1 libaudit-common libaudit1 libblkid1 libbz2-1.0 libc-bin libc6 libcap-ng0 libcom-err2 libdb5.3 libdebconfclient0 libext2fs2 libfdisk1 libffi7 libgcc1 libgcrypt20 libgmp10 libgnutls30 libgpg-error0 libhogweed4 libidn2-0 liblz4-1 liblzma5 libmount1 libncursesw5 libnettle6 libp11-kit0 libpam-modules libpam-modules-bin libpam-runtime libpam0g libpcre3 libselinux1 libsemanage-common libsemanage1 libsepol1 libsmartcols1 libss2 libstdc++6 libsystemd0 libtasn1-6 libtinfo5 libudev1 libunistring2 libuuid1 login mawk mount ncurses-base ncurses-bin passwd perl-base sed sysvinit-utils tar tzdata util-linux zlib1g openssl1.1 nvi wget busybox net-tools ifupdown sysvinit-core iputils-ping isc-dhcp-client locales ntp lynx whiptail dialog ca-certificates suite=unstable EOF sudo multistrap -d ${CHROOT_PATH} -f /tmp/multistrap-riscv64.conf sudo sh -c "cat >${CHROOT_PATH}/etc/fstab <<EOF proc /proc proc defaults 0 0 sysfs /sys sysfs defaults,nofail 0 0 devpts /dev/pts devpts defaults,nofail 0 0 EOF " sudo sh -c "cat >${CHROOT_PATH}/etc/network/interfaces <<EOF source-directory /etc/network/interfaces.d auto lo iface lo inet loopback allow-hotplug eth0 iface eth0 inet dhcp EOF " sudo mknod -m 666 "${CHROOT_PATH}/dev/null" c 1 3 sudo mknod -m 666 "${CHROOT_PATH}/dev/zero" c 1 5 sudo mknod -m 666 "${CHROOT_PATH}/dev/random" c 1 8 sudo mknod -m 666 "${CHROOT_PATH}/dev/urandom" c 1 9 sudo mknod -m 666 "${CHROOT_PATH}/dev/tty" c 5 0 sudo mknod -m 666 "${CHROOT_PATH}/dev/ptmx" c 5 2 sudo mknod -m 666 "${CHROOT_PATH}/dev/full" c 1 7 sudo mknod -m 600 "${CHROOT_PATH}/dev/console" c 5 1 sudo mknod -m 660 "${CHROOT_PATH}/dev/ttyS0" c 4 64 sudo mkdir -p "${CHROOT_PATH}/dev/pts/" sudo mkdir -p "${CHROOT_PATH}/dev/shm/" sudo mknod -m 666 "${CHROOT_PATH}/dev/ptmx" c 5 2 sudo ln -s /proc/self/fd "${CHROOT_PATH}/dev/fd" sudo ln -s /proc/self/fd/0 "${CHROOT_PATH}/dev/stdin" sudo ln -s /proc/self/fd/1 "${CHROOT_PATH}/dev/stdout" sudo ln -s /proc/self/fd/2 "${CHROOT_PATH}/dev/stderr"
This provides a (still unconfigured) riscv64 chroot in /tmp/riscv64-chroot - with sysvinit instead of systemd as there are still a few packages missing that are required for properly running systemd on riscv64 at the time of writing. Performing these steps on a Debian/stable system requires installing the debian-ports-archive-keyring package from unstable beforehand.
As the next step, copy /usr/bin/qemu-riscv64-static (cf. the qemu section) to ${CHROOT_PATH}/usr/bin. If you use Debian's qemu-user-static package from unstable, this step can be omitted.
To complete the chroot setup, it is necessary to execute the postinst scripts for all packages inside the chroot with the help of qemu-riscv64-static and to perform a bit of local configuration:
sudo chroot ${CHROOT_PATH} export TERM=vt102 dpkg --configure -a echo "S0:23:respawn:/sbin/getty -L ttyS0 115200 vt102" >> /etc/inittab echo "riscv64" > /etc/hostname passwd exit
If the dash package's postinst asks whether you want dash to be the default system sh, answer with "no", otherwise the postinst fails in this setup.
Creating a riscv64 chroot from a merged repository with debootstrap
There is a minimal repository merging debian-ports unstable+unreleased repositories, with enough packages to debootstrap a minimal chroot, as debootstrap is not able to install from multiple repositories, and unstable alone doesn't yet contain all the packages needed for a successful debootstrap.
For this to work, you'll need to install debootstrap and the debian-keyring package.
For cross-architecture install, you'll also need the qemu-user-static package in version 2.12~rc3 or newer.
debootstrap --arch=riscv64 \ --include=debian-ports-archive-keyring \ --keyring=/usr/share/keyrings/debian-keyring.gpg \ sid ROOT https://people.debian.org/~vagrant/debian-riscv64/
Once installed, you'll want to edit ROOT/etc/apt/sources.list* to use the standard unstable and unreleased repositories from debian-ports.
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 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 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).
Setting up a riscv64 virtual machine
Install the qemu-system-misc package from unstable.
Create a chroot.
Install a riscv64 cross-compiler.
- Build the Linux kernel and BBL, the "Berkeley Boot Loader". BBL is somewhat special in that it cannot chainload a Linux kernel like GRUB or U-Boot, but instead the BBL makefile links the kernel binary directly into the BBL ELF file. Therefore BBL must always be rebuilt when the kernel gets rebuilt. Creating a proper separation between BBL and the kernel is planned but not yet implemented.
sudo apt-get install libssl-dev wget "https://patchwork.kernel.org/patch/10300449/raw/" -O PIE-fix.patch git clone https://github.com/riscv/riscv-pk git clone https://github.com/riscv/riscv-linux cd riscv-linux git checkout riscv-linux-4.15 patch -p1 <../PIE-fix.patch make CROSS_COMPILE=riscv64-linux-gnu- ARCH=riscv defconfig make CROSS_COMPILE=riscv64-linux-gnu- ARCH=riscv -j4 cd ../riscv-pk/ mkdir build cd build ../configure --prefix=/tmp --host=riscv64-linux-gnu --with-payload=../../riscv-linux/vmlinux make cd ../../
- Create a disk image for qemu.
qemu-img create rootfs.img 10G /sbin/mkfs.ext4 rootfs.img
- Loop-mount the disk image and copy your chroot contents into it, then unmount the image again.
- Run qemu-system-riscv64 with BBL and the disk image.
qemu-system-riscv64 -nographic -machine virt -m 2G -kernel riscv-pk/build/bbl \ -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-device,rng=rng0 \ -append "console=ttyS0 ro root=/dev/vda" \ -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
Contact: buildd maintainers <riscv64@buildd.debian.org>
Status: https://buildd.debian.org/status/architecture.php?suite=unstable&a=riscv64&priority=
Stats graph: https://buildd.debian.org/stats/?arch=riscv64
Stats overview: https://buildd.debian.org/stats/riscv64.txt
Porterboxes
Currently there are no porterboxes available. Please refer to the "Setting up a riscv64 virtual machine" section for installing a riscv64 virtual machine locally.
Status Log
- 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:
Manuel A. Fernandez Montecelo (ManuelMontecelo)
- Karsten Merker
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