f4pga/ideas

Getting started with Debian Linux on RISC-V with SymbiFlow tutorial

Opened this issue · 8 comments

See #34 - also LiteX/VexRiscv but this time with Debian. This means more advanced capabilities, and the tutorial should showcase some of those to make the user understand how to build a useful, demo-worthy example system with relative ease. This could be the 'fun' tutorial.

Needs to also include Renode, as this can be used for developing the Debian system itself.

The tutorial will be needing some technical work first though. Some thoughts from Manuael (person responsible for the Debian port to RV64):

I am not sure if, apart from the kernel, glibc and other necessary
bits are ready? I got the impression that there are still more bits
missing apart from the kernel for riscv32.

From my side, for the time being I never payed much attention to the
32-bit part, because of several reasons. One is the incompleteness of
toolchain and basic bits, and also because the chips that I have seen
so far are very limited in terms of memory and sometimes other
hardware capabilities that would prevent Linux from running at all.
You can have the same basic binaries as in Debian with very little
memory (8MB) and only Integer instructions for many of them, but as
soon as you want to use common things in Debian like "apt", you'll
soon need 64 or 128MB, if not more. (It can be SWAP, but... you
know). And there's the question of "which baseline". In riscv64 it's
GC, with C being a bit controversial, but not sure if for riscv32
there's such an expectation for most chips.

In any case, to get things going, there's an script that helps to
cross-compile a good part of the Debian base set, on which the rest
can be built, see the following links:
https://wiki.debian.org/HelmutGrohne/rebootstrap
https://salsa.debian.org/helmutg/rebootstrap

This script assumes that most packages needed have support for riscv32
in the Debian unstable archive, and only relatively small changes are
needed, and linux-headers are one of the first things required. If
not ready, one needs to buidl these by hand and modify the script
accordingly to use the tools/headers/libraries that you created
manually. Pulling this for riscv64 was quite an effort that took
months of preparation and weeks in the final pushes, and it was in a
better state than riscv32, so it's not trivial, but it can be done :-)

Now that riscv64 is basically fully functional, it could get used to
build riscv32 from riscv64 hosts as it's been done for other
architectures, but since there's no direct compatibility between 32
and 64 bits I am not sure if this is easier than from a completely
unrelated host like x86_64.

In summary, there's nothing readily available (or even in preparation
for RV32) so far, because of lack of chips capable of running Debian
and nobody showed much interest in this topic so far. If there's
interest I can guide you to try to pull this through, I might help
myself in some aspects although my free time decreased enormously in
the last year, but one of the first things needed is to get a clear
target for the hardware, baseline, timeline for the low-level bits to
get upstreamed, etc.

GitLab
https://wiki.debian.org/HelmutGrohne/rebootstrap

Couple of other links Debian riscv64.

32bit RISC-V would be most comparable to the armel port or sh4 port.

armel uses soft-float and targets ARMv4T, armhf uses hard-float and targets ARMv7 with Thumb-2.

RV32IMA(C) should be soft-float, RV32G(C) should be hard-float.

OpenEmbedded has a rv32gc port that works, and you can probably use meta-debian, to bring it up on qemuriscv32.

ulx3s comes with 32MB of SDRAM, and even the smallest ECP5 on that board should be capable of running vexriscv linux-minimal.

I'm pretty sure we want to use soft-float with vexriscv?

Yep, vexriscv doesn't have the F or D extensions. I suppose you could enable them in the machine mode emulator, to get the hard-float version working first... It would be slow.

The linux-minimal variant (currently) disables the C extension too.

This qemu patchset is relevant:
https://www.mail-archive.com/qemu-devel@nongnu.org/msg611889.html

It allows qemu to have CPUs that don't support the full RV32GC.

Yep, vexriscv doesn't have the F or D extensions. I suppose you could enable them in the machine mode emulator, to get the hard-float version working first... It would be slow.

The linux-minimal variant (currently) disables the C extension too.

But no worries to have, you can enable it if you want, it pass all the regression tests :)

I generaly disable it for two reasons :

  • The LUT cost
  • The combinatorial path length added to the decoding.