User:Cmsigler/RISC-V

From ArchWiki

Working Document: Planning to Port Arch to RISC-V -- please edit :)

Please edit this to your heart's content, without destroying prior work of value, or of historical or reference significance. I would like to construct a plan for porting Arch to the newly emerging RISC-V hardware.

I am very much a novice to this. I've had success running ARM SBCs via ArchLinuxArm, but I've never ported anything :\

I quickly created a personal, non-professional, simple text logo for RISC-V. I don't have sysop upload privilege, so here's a link to view:

https://drive.google.com/file/d/1WKZLl0G_BriPsmRQaMz6yGtIcjJ7pqmd/view?usp=sharing

I license this logo under CC BY-SA 2.0. If it is of any interest, feel free to use it with attribution.

Target hardware

  1. α -- Allwinner D1 single-core XuanTie C906 64-bit RISC-V (RV64GCV) processor @ up to 1 GHz; 22nm manufacturing process (Called AllWinner D1-H (H for HDMI) now, with a cheaper D1s version that include 64MB of DDR2 RAM on SoC itself). See also this LinuxGizmos article. support Matrix of the D1 on mainline Linux.
  2. β -- RISC-V International Open Source (RIOS) Laboratory is collaborating with Imagination technologies to bring PicoRio RISC-V SBC to market at a price point similar to Raspberry Pi. See also this blog article from RISC-V International.
    • This second one is also projected to cost close to the RPi.
  3. γ -- BeagleBoard.org and Seeed unveiled an open-spec, $119-and-up “BeagleV” SBC with a StarFive JH7100 SoC with dual SiFive U74 RISC-V cores, 1-TOPS NPU, DSP, and VPU. The SBC ditches the Cape expansion for a Pi-like 40-pin GPIO. See also this LinuxGizmos article, and this ExtremeTech article.
    • Initial prices are given as US$119 and US$149, which is much more affordable than the original system mobo.
  4. δ -- RVBoards Nezha D1, using the XuanTie C906 mentioned above.
    • Current price is $99, in-line with the other boards.
  5. ε -- VisionFive 2, "open source quad-core RISC-V dev board", StarFive JH7110 SOC with 4x U74 cores, GPU etc. Clearly aimed straight at RasPi, has 40-pin GPIO, a bit larger form factor (100x72 vs 86x57mm), close to RPi4 CPU performance, better IO including M.2 M-Key. Already has Debian & Fedora ports, more to follow. Now in pre-order via Kickstarter, lots of good info there.
    • Current price (kickstarter/preorder) is US$55-85, depending mainly on RAM (2-8GB).
  1. φ -- Pine64 Ox64 SBC using Bouffalolab BL808 (Looks like this company switched from SiFive closed source core (in BL602 and BL702) to faster and open source T-Head core, "open source C906 RV64GCV RISC-V microprocessor + E907 RV32 microcontroller + Bouffalo NPU accelerator. The C906 RV64 is similar to D1 one but at lower frequency, should boot Linux, and the embedded RV32 could execute microcontroller dedicated code (a Rust toolkit is developed by Bouffalo) 64MB on chip RAM.
    • Current price from US$6 with 16MB flash to US$10 with 128MB flash.

(Any others? I don't plan on spending US$1,000 on a development system/motherboard.)

RiscV Arch image builder

These scripts allow to build RISC-V Arch linux image for Sipeed Licee RV, based on AllWinner D1.

https://github.com/sehraf/riscv-arch-image-builder

Experimental development: Procedures and steps used

  • Initial setup, testing for further work
    1. Git repository setup -- Push commits to gitlab repos, mirror gitlab to forked github repos
      • Clone RISC-V repositories on github to local repos
      • Fork RISC-V repositories on github
      • Create gitlab repositories
      • Rename github origins for cloned repos, then add gitlab repos as origins
      • Push local repos to gitlab
      • Configure gitlab repos to mirror to github forks using a personal access token generated on github
    2. Test running x86_64/amd64 installations via chroot (or systemd-nspawn)
      • Gentoo:
        • Create a subdirectory for the chroot installation; untar Gentoo amd64 stage3 tarball into subdirectory 
          $ cd ./subdir/ && sudo tar xpvf stage3-*.tar.xz --xattrs-include='*.*' --numeric-owner && cd ..
        • Configure and emerge:
          1. Configure Gentoo compilation options in ./subdir/etc/portage/make.conf to set GENTOO_MIRRORS and edit other env vars; copy DNS info into ./subdir/etc/resolv.conf
          2. Enter chroot environment 
            $ sudo arch-chroot ./subdir/
          3. # source /etc/profile && source $HOME/.bashrc
          4. Optionally, update default prompt 
            # export PS1="(chroot) ${PS1}"
          5. # emerge --sync
          6. Double-check system profile (e.g., amd64 systemd, rv64_lp64d systemd) is correct 
            # eselect profile list
          7. # emerge --ask --verbose --update --deep --newuse @world
          8. Optionally, configure USE variable 
            # emerge --info | grep ^USE
            # nano -w /etc/portage/make.conf
          9. Configure timezone 
            # echo "Region/Location" > /etc/timezone
            # emerge --config sys-libs/timezone-data
          10. Configure locales 
            # nano -w /etc/locale.gen
            Add desired locales, e.g., 'en_US.UTF-8 UTF-8', 'en_US ISO-8859-1'; remove unnecessary entries 
            # locale-gen
          11. Select locale 
            # nano -w /etc/env.d/02locale
            Add, e.g., 'LANG="en_US.UTF-8"' and 'LC_COLLATE="C"' 
            # env-update && source /etc/profile
          12. Optionally, set /etc/conf.d/hostname; add 'hostname="system_name"'
          13. Exit chroot environment 
            # exit
        • Chroot (or systemd-nspawn) into subdirectory and test normal administrative operations, e.g., 
          # emerge --sync
          # emerge --ask --verbose --update --deep --newuse @world
      • Arch:
        • Create a subdirectory for the chroot installation; install base, base-devel and a basic editor 
          $ sudo pacstrap -c ./subdir/ base base-devel nano
        • Configure:
          1. Copy DNS info into ./subdir/etc/resolv.conf
          2. Create bind mountpoint for subdir 
            $ sudo mount --bind ./subdir/ ./subdir/
          3. Enter chroot environment 
            $ sudo arch-chroot ./subdir/
          4. # source /etc/profile
          5. Optionally, update default prompt 
            # export PS1="(chroot) ${PS1}"
          6. Configure timezone 
            # ln -sf /usr/share/zoneinfo/Region/Location /etc/localtime
          7. Configure locales 
            # nano -w /etc/locale.gen
            Uncomment desired locales, e.g., 'en_US.UTF-8 UTF-8', 'en_US ISO-8859-1' 
            # locale-gen
            # nano -w /etc/locale.conf
            Add, e.g., 'LANG="en_US.UTF-8"' and 'LC_COLLATE="C"'
          8. Optionally, update system 
            # pacman -Syu
          9. Optionally, set /etc/hostname; add 'hostname="system_name"'
          10. Exit chroot environment 
            # exit
        • Chroot (or systemd-nspawn) into subdirectory and test normal administrative operations, e.g., 
          # pacman -Syu
    3. Test running rv64_lp64d/riscv64 installations via chroot (or systemd-nspawn) using same installation and configuration procedures
  • RISC-V binary tests and demos
    1. Test cross-compiling, linking RISC-V (riscv64-lp64d) C programs
      1. Test building, executing on host system
        • Install riscv64-linux-gnu-gcc, qemu-arch-extra, qemu-user-static-bin, binfmt-qemu-static-all-arch
        • Write hello_world.c, other test programs
        • Compile: 
          $ riscv64-linux-gnu-gcc -c -Wall -o hello_world-riscv64.o hello_world.c
        • Link: 
          $ riscv64-linux-gnu-gcc -o hello_world-riscv64 hello_world-riscv64.o
          $ riscv64-linux-gnu-gcc -static -o hello_world-riscv64-static hello_world-riscv64.o
        • Run: 
          $ qemu-riscv64 -L /usr/riscv64-linux-gnu/ ./hello_world-riscv64
          $ ./hello_world-riscv64-static
      2. Test building, executing under RISC-V system chroot
        • Install, configure Gentoo (later, Arch) RISC-V system under chroot subdirectory
        • Copy source files and cross-compiled RISC-V binaries from host system into chroot
        • Enter RISC-V chroot
        • Compile, link source files inside chroot using native gcc
        • Test running both host cross-compiled and chroot native-compiled binaries inside chroot
      3. Any additional tests, experiments
    2. Repository of pre-built RISC-V pkgs from FelixOnMars
      • Configure binfmt-qemu-static to run RISC-V binaries as native programs
      • Following the Arch installation guide, use pacstrap to install base pkgs into risc-v subtree
      • Run arch-chroot to run subtree as a RISC-V container
      • Test running RISC-V binaries from coreutils
      • Test running other binaries, and installing other RISC-V pkgs from this repository
      • Test using systemd-nspawn to run subtree as a RISC-V container
  • Cross-bootstrapping to build basic RISC-V system
    1. RISC-V PKGBUILD repository pkgs from FelixOnMars
      • Experiment with cross-compiling pkgs from RISC-V PKGBUILDs
      • Test building cross-compiled pkgs from all PKGBUILDs
      • Fix PKGBUILDs for which building fails
      • Add and commit patches for RISC-V PKGBUILDs to local repo
      • Push to origin (personal gitlab repo)
      • Send merge request upstream
    2. archlinux-cross-bootstrap
      • Use a build tree separate from the git source tree (is this the default?)
      • Initially, test build of all 4 stages without creating build/.KEEP_GOING file to ignore build errors; read .MAKEPKGLOG in each build directory, as well as teeing output of overall build process into a log file
      • Identify pkgs with build errors; debug and patch
      • Individually test rebuilding pkgs which failed with errors; correct patches
      • Add and commit patches to local git repository
      • Push to origin (personal gitlab repo)
      • Send merge request upstream

Basic thoughts and ideas for porting

Notes 2021/01/31:

Finally making some more progress:

  • Tested creating a Gentoo amd64/systemd chroot by unpacking a stage3 tarball into a target subdir, then pre-configuring, chrooting (via arch-chroot) into the target, and updating and configuring as needed the chroot system. This seems to work fine. Also installed a minimal X windows program, qemacs, inside the chroot and ran it after allowing X windows programs access to the parent X server.
  • Installed Arch base and base-devel into a target subdir via pacstrap -c, then chrooted (via arch-chroot) into the target and configured the installation for timezone, locale and hostname.
  • Wrote, tested and debugged a few simple C programs on x86_64 in order to test compilation for the RISC-V riscv64-lp64d target. Then, after installing riscv64-linux-gnu-gcc to cross-compile, compiled and linked these to produce riscv64-lp64d binaries. After installing qemu-arch-extra, tested running them with qemu-riscv64 -L /usr/riscv64-linux-gnu/.

Additional info 2020/11/14:

Thanks to eschwartz, here are links to resources produced by FelixOnMars, who has tackled some RISC-V porting in his spare time:

There's a lot of finished work he's done -- good stuff :) and one shouldn't be spending most of one's efforts reinventing the wheel ;)

Revised 2020/11/13:

In essence, what I'm looking to do is:

  1. Build RISC-V pkgs for Arch.
  2. Build bare-metal RISC-V Arch disk images that can potentially be booted on physical hardware. Of course, device tree/drivers will have to be individually customized for each mainboard/SBC. Getting a disk image that works in KVM/QEMU would scratch my itch of getting most of the work done. Someone with more bare-metal hardware/driver work may have to put the finishing touches on it.

Hoping my understanding and itemized steps are more-or-less correct.... Methods to make porting progress:

  1. So, if we want to build Arch RISC-V pkgs, we can simply cross-compile them. When a pkg won't build, we patch it until it does (assuming we can eventually get it working).
    • Note that Vadim Kaushan (Disasm on github) has patched upstream parabola-cross-bootstrap from Andreas Grapentin (oaken-source on github) to create archlinux-cross-bootstrap. The last commit was January, 2019. Some things may have b0rken but it's worth trying (and patching) this to cross compile base-devel pkgs to RISC-V. Then we can perhaps extend its coverage to more repository pkgs.
  2. We can unpack a RISC-V stage tarball (or image). Then we can chroot, or use something really fancy like systemd-nspawn, into that tree and use QEMU user-mode emulation to run RISC-V binaries.
  3. We can create a VM disk image (GPT, of course) and unpack inside it, e.g., a RISC-V Gentoo stage3 and complete installation and configuration. We also need to compile a RISC-V kernel and bbl (Berkeley Boot Loader from the riscv-pk github project) (some instructions here and here), or we may be able to download pre-built kernel/binaries/utilities. Then we can boot the image with KVM/QEMU.
    • Also available are Debian RISC-V, Fedora RISC-V and openSUSE RISC-V images. In those wiki pages are some instructions for putting together bare-metal disk images.
    • Also, there are ready-made QEMU images that one can download and run. See Debian, Fedora, additional Fedora, AltLinux. I guess this ready-made solution would be the ultimate in ease of use, but it doesn't solve the problem of building from scratch. But at least inside a running VM I could download and build dev infrastructure (pacman, et al) and then build pkgs as if I were running on bare metal. It might be only a little slower than running on a SBC?...

So, in the end, the best solutions seem to be:

  • Cross-compiling using existing scripting/tooling to build Arch pkgs. archlinux-cross-bootstrap should build base-devel pkgs. Using its scripts with modified PKGBUILDs, it should be possible to build other repository pkgs.
  • To test cross-compiled pkgs, create a chroot to use via QEMU user-mode emulation (after setting up qemu-user-static and binfmt_misc; note proot). Follow the usual installation instructions using pacstrap, etc., to install RISC-V pkgs inside the chroot, then complete installation and configuration.
    • Note that this creates a running RISC-V Arch system.... Tinker with it to your heart's content. Then you could make an archive (tar) snapshot of it and use this as the basis of a bare-metal VM image :)
    • However, since these cross-compiled pkgs will contain dynamically linked binaries, I'm not sure ATM how binfmt_misc will work to run them with the "-L" flag to reference the RISC-V linker path? Although, once inside the chroot will user-mode QEMU just use the .so libraries inside the chroot?....
  • For final image building, create a VM disk image, follow the usual installation instructions to install an Arch RISC-V system inside the image, configure it just like a bare-metal installation, and see if it works :)
  • When running the VM disk image like bare metal, bootloading to boot the kernel will need to work. Otherwise, the bootloader and kernel used to boot and run the VM will have to be exterior to the disk image. We want to create a turnkey disk image including bootloading....

Revised 2020/11/11:

Thanks to Awebb for helping to distill disorganized ideas.

Perhaps the best way to make progress on porting to RISC-V (mainboard and embedded/SBC) is simply to build Arch packages. The bootstrapping and embedded intricacies can be dealt with later. Plus, building packages can be done bit by by when time is available. So....

There are two ways to build packages, I believe:

  1. Cross-compile using available Arch RISC-V tooling (see below)
  2. Install an existing RISC-V system in a KVM/QEMU VM

Frankly, the VM method seems the easiest (and laziest) way. (Update: Probably not as easy/lazy as I was thinking.) There are Gentoo stage3 tarballs so, assuming RISC-V support in KVM/QEMU is generally bug-free, setting up a RISC-V Gentoo VM should be a mechanical process. After this, Arch tools would be compiled inside the VM, and then base, base-devel and then core pkgs would be built. (For related information, see the Gentoo 32-bit RaspberryPi page and the Gentoo 64-bit RaspberryPi page.)

See links below for documentation and instructions.

Original text:

According to the initial press release on the above α hardware target/SoC board, this "Allwinner RISC-V processor will run the Debian Linux operating system (Tina OS)." Provided that "Tina OS" licensing is "clean," one should be able to boot the supplied Debian OS and use that to develop an Arch bootstrap, or perhaps an entire port?

IIUC, that should include the bootstrapping and device tree stuff along with device drivers for on-board equipment. (Drivers for optional devices and for devices on available modules/daughter cards will need to be developed, too.)

After that, base and base-devel packages need to be built. Then building packages can be done on bare metal. However, it would obviously be faster and easier to build them using the available RISC-V toolchain in Arch. Right? (I wonder how ArchLinuxArm handles building packages for and maintaining their repositories, as well as their AUR? Note to self: Research ALARM infrastructure....)

Topics to be researched and written up or references pointed to:

  • HOWTO bootstrap a new port from ground zero -- See references below
  • How the bootstrapping process is booted/initiated
  • How device trees work
  • How device drivers work in bootstrapping, e.g., via initrd image
  • Cross-building Arch packages for RISC-V
  • Infra for a new port's repositories (CB/CI tools, repository hosting, front end w/hosting, etc.)
  • Infra for a new port's AUR
  • Possibility of free/open (non-binary blob) bootstrapping image/BIOS (similar to coreboot)

Necessary tools for porting

KVM/QEMU RISC-V emulation documentation, information and instructions

qemu-arch-extra pkg required for RISC-V (and other architecture) full-system emulation

qemu-user-static (or qemu-user-static-bin) for running QEMU user-mode emulation inside a chroot; binfmt-qemu-static (or binfmt-qemu-static-all-arch) for these

Arch QEMU pkgs and variants from repository and AUR

RISC-V Linux on QEMU Getting Started Guide

QEMU RISC-V Documentation

(See also: SiFive RISC-V QEMU Upstream Announcement)

How To Run Linux on RISC-V with QEMU Emulator

Tools available under Arch

Tools from repositories

RISC-V group

Results of "riscv" keyword search

Tools from AUR

Results of AUR "RISCV" keyword search

Results of AUR "risc-v" keyword search

Tools from other dists

Obsolete: Experimental Gentoo stages

Gentoo RISC-V stages

Debian images

Fedora images

Additional Fedora images

AltLinux RISC-V64 port

Parabola GNU/Linux-libre QEMU image

Non-Arch tools

Crosstool-ng

Buildroot

Cross-Linux From Scratch (this project seems to be dormant...)

As-is experimental RISC-V pkgs from work done by FelixOnMars

Arch RISC-V Packages

Arch RISC-V Repo

References -- PLEASE add to and curate this list!

RISC-V Getting Started Guide

https://github.com/archlinux-riscv-abandoned/archlinux-cross-bootstrap

https://bbs.archlinux.org/viewtopic.php?id=237370

https://bbs.archlinux.org/viewtopic.php?id=260639

https://five-embeddev.com/toolchain/2019/06/26/gcc-targets/

https://wiki.qemu.org/Documentation/Platforms/RISCV

https://wiki.gentoo.org/wiki/Project:RISC-V

https://wiki.gentoo.org/wiki/Raspberry_Pi (for embedded build and cross-compiling info)

https://wiki.gentoo.org/wiki/Raspberry_Pi_3_64_bit_Install

https://wiki.archlinux.org/index.php/Cross-compiling_tools_package_guidelines

https://github.com/crosstool-ng/crosstool-ng

https://git.busybox.net/buildroot

https://github.com/cross-lfs

https://github.com/michaeljclark/busybear-linux

https://github.com/janvrany/riscv-debian

(http://dl.sipeed.com/shareURL/MAIX/K210_Linux/Firmware)

https://archlinuxpower.org (WIP RISC-V Arch port co-located with PowerPC Arch builds, might be good as a source base) https://github.com/kth5/archpower

Step-by-step "HOWTO" for porting

Detailed instructions and explanations

Issues addressed, with work-arounds

Bug report list -- Please make notes during triage, and move to above "Issues addressed" list when "solved"

Retrieved from "https://wiki.archlinux.org/index.php?title=User:Cmsigler/RISC-V&oldid=752439"