User:Cmsigler/RISC-V

From ArchWiki
Jump to navigation Jump to search

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

α -- Unnamed Allwinner single-core XuanTie C906 64-bit RISC-V (RV64GCV) processor @ up to 1 GHz; 22nm manufacturing process. See also this LinuxGizmos article.

  • This first one is nice because it's cheap (US$12.50 IIUC), albeit underpowered compared to ARM SoC boards available at this time (November, 2020).

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

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

Basic thoughts and ideas for porting

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

Experimental Gentoo stages

Debian images

Fedora images

Additional Fedora images

AltLinux RISC-V64 port

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/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

Experimental development: Procedures and steps used

  • Initial testing
    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. 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
    3. Repository of pre-built RISC-V pkgs from FelixOnMars
      • Install qemu-arch-extra, qemu-arch-static-bin, binfmt-qemu-static
      • 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
    4. RISC-V PKGBUILD repository pkgs from FelixOnMars
      • Add and commit patches for RISC-V PKGBUILDs to local repo
      • Push to origin (personal gitlab repo)
      • Send merge request upstream

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"