[Arm-netbook] Libre RISC-V RV64GC SoC

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


On Wed, Dec 27, 2017 at 2:25 PM, Andrew M.A. Cater
<amacater at galactic.demon.co.uk> wrote:
> On Wed, Dec 27, 2017 at 09:08:42AM +0000, Luke Kenneth Casson Leighton wrote:

>> so, any ideas, input etc. welcomed.
>>
>
> Talk to Debian for the software, obvs :)

 yes - on it :)  debian-riscv.  there's also fedora-riscv.

> They have most things packaged
> somwehere and ties to Debian Edu/Skolelinux. The problem, if problem it
> is, is that you need a new port to do this well and that means good
> emulators and, eventually, fast build hardware.

 yehyeh.  right now they're running under qemu, which is not the way
you're supposed to do it, but they at least have a base suite of
packages compiled up, the bootstrapping's been done.

> RISCv64 also needs to be well supported by the Linux kernel, so you
> probably need to make sure that there's an easy way to build the Linux
> kernel (GCC build chain and GNU tools ... )

 yehyeh, the riscv-kernel has been up and running for a long time,
now, the most important thing is the acceptance of the riscv-gcc
patches (done recently) and also libc6 and binutils patches.

 also there's an outstanding bugreport for debian which "finalises"
the strings (architecture names) and the port names and also they
*must* have the support of the *exact* same versions of binutils and
gcc which are utilised *right* across the board for every other debian
architecture.

 this is absolutely critical for stability, otherwise you can't
guarantee that packages will be properly compiled and dynamically link
together.

 so it's a chain that's slowly propagating and sorting itself out...
and being handled.

 what i meant by software is things like, for example... if we get a
3D engine up and running (however it's done), that *will* need mesa3d
support to be made for it.  and/or vulkan, and/or whatever the
flavour-of-the-month for accelerated graphics happens to be.

 likewise if we add a VPU, someone has to do the....  whatever-it-is,
ffmpeg, gstreamer, blah-blah porting and so on.

 there are lots of little details that need someone to work on *AT THE
SAME TIME* as the actual hardware *ITSELF* is being developed (!!).

 it's quite an interesting and tricky self-bootstrapping problem that
will require quite a bit of thought and careful planning.

l.