
Debian port for RISC-V 64-bit - desdiv
https://people.debian.org/~mafm/posts/2017/20170422_debian-gnulinux-port-for-risc-v-64-bit-riscv64/
======
phkahler
As someone who has followed tech for almost 40 years, I've watched a lot of
things come and go. I've seen "the next big thing" go nowhere countless times
while some obscure things surprised me. Well intentioned good ideas didn't
make it because of external factors or they lacked enough momentum to push
through developmental barriers. Having seen all of that, my assessment of RISC
V is simple: If they complete the privileged spec as planned this year (and
hopefully the vector extensions too) it's going to explode onto the stage like
newly formed star. The ramp will appear slow to people with high hopes and
unrealistic expectations, but in the context of my life it will be a sudden
shift the likes of which are rarely seen.

That is IFF they get the specs finalized, and I hope they support Googles VM
threads while they're at it.

~~~
rwmj
The thing that has delayed Linux on RISC-V is simple enough: They keep
changing and breaking ABIs. There was even one massive source break (changing
#ifdef __riscv64 to __riscv) which broke several projects that I'd contributed
RISC-V support to.

The reason that the Fedora port is on hold is because I'm waiting for
everything to go upstream so that this sort of thing stops happening.

IMO this was entirely avoidable, and would have meant that we could have had
both Fedora and Debian full RISC-V ports one or two years ago.

~~~
legulere
The way I understand it, those breakages happened because problems were found
during porting. So it is kind of an egg-hen problem. Without porting problems
cannot get fixed and in a stable state. Without a stable state people do not
want to port things.

~~~
rwmj
They could have maintained backwards compatibility (eg. by still defining
#define __riscv64 as a deprecated definition), but chose not to. More of a
problem is there was no real process for making the changes or informing
anyone about the changes, they "just happened" and we only noticed later.

Anyway, once glibc & kernel changes are upstream, we'll have the stable ABIs
we need. I'm very much hoping that upstreaming will be completed this year.

------
EvgeniyZh
Other software support status for RISC_V: [https://github.com/riscv/riscv-
wiki/wiki/RISC-V-Software-Sta...](https://github.com/riscv/riscv-
wiki/wiki/RISC-V-Software-Status)

------
rwmj
Fedora RISC-V port:
[https://fedoraproject.org/wiki/Architectures/RISC-V](https://fedoraproject.org/wiki/Architectures/RISC-V)

------
eximius
Does anyone know of good introduction for RISC V and why I should care about
it from a technical perspective?

I get the Open Source argument. And I get that x86 is full of warts and weird
decisions. But does RISC learn from those mistakes and make something useable?

~~~
rwmj
I think the design technically is more elegant. The instruction format is
better: there are only a few formats, register numbers are always in the same
place, which makes instruction decoding easier. The instruction set is also
properly extensible, you can add extensions in an official way. They've
avoided making lots of special-case instructions, claiming that micro-op
fusion can be used to the same effect.

The financial argument is: You want to license an ARM-like chip design,
without paying any license fees. Lots of companies currently license ARM and
use it to make everything from embedded controllers to tablet computers. They
pay ARM both a one-off license fee and per core manufactured (actually the
fees are not that large in the grand scheme of chip design).

There are several RISC-V designs, which are BSD licensed, or you can make your
own without any licensing fees. However if you want to call it "RISC-V" or use
the logo you have to join the Foundation. If you don't want to call it
"RISC-V" then the license is completely free.

Of course what's missing is the ecosystem: Linux, Android, and massive numbers
of tools. That's why this announcement of the Debian on RISC-V project
restarting is interesting.

(Forget about licensing an x86 design, that is basically impossible).

------
lamby
RISC will change everything.

~~~
keithpeter
What time-scale do you envisage for actual hardware?

~~~
richardxia
Linux-capable hardware will be coming out this year.

~~~
desdiv
Some have already shipped[0], though the availability is very limited.

[0]
[https://www.crowdsupply.com/sifive/hifive1](https://www.crowdsupply.com/sifive/hifive1)

~~~
rwmj
These have very limited RAM, and won't run Linux.

~~~
shakna
128MB Flash off-chip, and I know of several Linux distros that can run with
under 50MB, so I would say it would be entirely possible to run it.

~~~
rvense
128 MB Flash, not RAM.

Linux will run in 8 megabytes of RAM if you want. The SiFive board has 16
kilobytes.

~~~
shakna
What's to stop you connecting up an old SIMM card? The memory won't be fast,
but doable.

I saw Flash as the larger limitation, as expanding that is problematic.

~~~
rvense
> What's to stop you connecting up an old SIMM card? The memory won't be fast,
> but doable.

There aren't enough pins. Certainly not enough pins accesible in single-cycle
reads/writes. Maybe you could multiplex them with external hardware to talk to
a SIMM but you'd be talking to memory at single megahertz effectively.

An SDRAM controller in an FPGA on the other side of the QSPI link would be
faster, but it'd still be slow. You could get it to work to say you've done
it, but it'd run at literal-days-to-boot speeds.

The board (and chip) is meant and marketed for freetards who like Arduinos -
so I bought one and so did several of my friends. LEDs were blinked and better
futures dreamt of. It's cool. But it's not a workstation chip by any stretch
of the imagination.

Hopefully the next version will have a real external memory bus.

~~~
welterde
I reckon it would be more in the range of minutes (depending on how complete
of a linux system we are talking about here). The QSPI peripherial can run at
100MHz if I read the datasheet correctly (so you can read/write data at about
400MBit/s minus overhead). For reference booting linux on an ATmega@24MHz
running an ARM emulator and external SDRAM with an memory bandwidth of about
300kbyte/s seems to take about 6 hours [1]. Assuming the SiFive is just as
efficient as the ATmega it would take less than a minute (assuming the memory
bandwidth is the only bottleneck and not the slow CPU - the SiFive also has
16kB of L1 cache and has a clock rate 10x faster).

[1]
[http://dmitry.gr/index.php?r=05.Projects&proj=07.%20Linux%20...](http://dmitry.gr/index.php?r=05.Projects&proj=07.%20Linux%20on%208bit)

~~~
rvense
OK, maybe it could work. I remembered that ATmega port as slower. Maybe it
should be tried.

