[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Packaging of the RISC-V ecosystem?


2016-11-09 19:43 Karsten Merker:
On Wed, Nov 09, 2016 at 09:55:25AM +0800, Paul Wise wrote:

I wonder how much of the RISC-V ecosystem we should include within Debian.

Presumably we want a Linux riscv64el port and the associated
bootloader, kernel and toolchain support.

I was using just "riscv64" as port name, btw, since in principle nothing
has been done for big-endian or heard about anybody interested in that.

Other possibilities like rv64 would be shorter but less descriptive.

I'm open to change it, but obviously if it's going to be something other
than "riscv64" better to change it now.

Perhaps we want bare-metal cross-toolchains for non-64-bit RISC-V
CPUs? This would be useful for compiling firmware for the lowRISC
minion cores I guess.

Maybe we want hardware development tools like the Chisel hardware
description language, the Spike simulator and so on?

Do we want some of the open CPU cores packaged and built for the FPGA
architectures with libre toolchains?

A bare-metal toolchain makes sense at least as far as it targets
the LowRISC minion cores which will probably be PULPino-based and
therefore effectively RV32I-only.  AFAIK The PULPino implements
hardware multiply but not hardware division, so code for it
cannot be built with a compiler targeting full RV32IM.

Information about the Pulpino from the 3rd RISC-V workshop:

I heard about a (upcoming?) crowd-sourcing campaing from people of UIS
in Colombia who plan a 32-bit RISC-V microcontroller (they presented it
in previous workshops).  There can be potentially many devices not
conforming exactly to the standards, or not to the RISC-V 'G'eneral set,
so I am not sure how we're going to manage this.

That's why, on my part (and I think that Karsten thinks the same about
it, from previous conversations), I think that 64-LE is the most useful
target at the moment, and then we will see what happens with other
devices.  Compilers for bare-metal can be useful, but maybe not even
worth for Debian stable releases (e.g. if they crop up and disappear
fast, and are not very popular).

As for kernel, bootloader, qemu and toolchain (probably in reverse order
of importance) -- absolutely, when ready upstream or with special

Manuel A. Fernandez Montecelo <manuel.montezelo@gmail.com>

Reply to: