[lowrisc-dev] building lowRISC binaries with current riscv-gnu-toolchain?

Michael Clark michaeljclark at mac.com
Tue Oct 16 23:04:30 BST 2018

What version of which component do you want to support?

I don’t know if this helps, but i took the riscv-linux port overlay (earlier versions just contained the arch/riscv directory) and merged it with underlying linux kernel version, the most recent supporting priv-1.9.1 (linux 4.6.2) so the commits are a branch off the Linux stable tree (Linus doesn’t have tags for these in his tree, only -rc and x.x.0, so the history comes from Greg Kroah-Hartman’s tree. This is so I could insulate against backwards incompatible breakages while incorporating them into a tree that contained the mainline Linux history. It’s here:


QEMU still supports priv-1.9.1, but not priv-1.9 which is unfortunately binary incompatible with priv-1.9.1. rv8 is still on priv-1.9.1 and the interrupt handling is a bit wonky.

I don’t think the toolchain should be too much of a problem as I believe it has aliases for old CSRs. CSRs are the only thing that changed from the toolchain perspective and I have a repo that tracks the history of changes (riscv-meta). At least I think the toolchain should be fine.

linux kernel has shed support for priv-1.9.1 as it used “config string”. Lucky these are only soft cores and can be upgraded. The situation with QEMU was we didn’t want to be in a situation where we didn’t support at least two versions of the spec (i.e. break backwards compatibility with priv-1.9.1 without fully supporting priv-1.10). I also have a bbl tag in my riscv-pk repo for priv-1.9.1.

There was a point in history where there were no mutually compatible versions of the tools and emulators. QEMU supports from priv-1.9.1 forwards.

It’s very hard to see what the exact delta is when folk try to wipe past history hiding it in git rm -r commits versus using tags. It means anyone who can’t keep up has all of their tools broken. The collaborative approach to version management requires step-wise changes that consider the past/present.

It’s nice to have repos with stable dependencies so that one can still check them out and type “make” and have it not blow up. Even better if it passes tests.

> On 17/10/2018, at 10:11 AM, Karsten Merker <merker at debian.org> wrote:
>> On Tue, Oct 16, 2018 at 03:59:29PM -0400, Gabriel L. Somlo wrote:
>> I'm trying to bring together a reasonably current hardware+software
>> riscv environment, and lowRISC (on nexys4-ddr) appeared to be the most
>> likely candidate :)
>> So I managed to replicate the entire from-source build process for
>> "lowrisc-chip-ethernet-v05", including the bitstream (with Vivado),
>> and riscv-tools (riscv-fesvr, riscv-isa-sim, riscv-gnu-toolchain,
>> busybox, the kernel, and the bbl bootloader).
>> I also managed to build poky, but as it turns out I can leave that
>> out, and still get a minimal busybox-in-initramfs working, bootable
>> system.
>> So far, so good.
>> I would, however, like to move toward upgrading this system to more
>> modern/recent/upstream components.
>> Busybox is easy, I can build 1.28.3 (currently the latest) with the
>> included toolchain, and things are still OK.
>> This is where I got stuck, though:
>> I can't build a more recent kernel (e.g. 4.19-rc8) with the included
>> toolchain.
>> So I grabbed the sources for https://github.com/riscv/riscv-gnu-toolchain
>> and built it for multilib, including "rv64imafd-lp64" which I believe
>> "should" work on the lowRISC implementation of the ISA.
>> However, if I try building a statically linked busybox binary with the
>> new/upstream toolchain, I'm getting either a signal-7 bus error or a
>> signal-4 illegal opcode error from the existing (working) lowRISC
>> kernel.
> According to https://www.lowrisc.org/docs/ethernet-v0.5/, LowRISC
> v0.5 implements only priv-1.9.1, but the upstream kernel requires
> priv 1.10 or newer, so running an upstream kernel on a LowRISC
> v0.5 isn't possible.  To make things even worse, upstream glibc
> in turn AFAIK requires an upstream kernel (3.15 or newer) and
> doesn't build cleanly against older (priv-1.9.1-supporting)
> kernels.  AFAIK LowRISC v0.6 is planned to support priv 1.10 and
> thereby should work with upstream Linux and glibc.
> HTH,
> Karsten
> -- 
> Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
> sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
> Werbung sowie der Markt- oder Meinungsforschung.

More information about the lowrisc-dev mailing list