
Debian Riscv64 port in mid 2019 - Oxynux
https://people.debian.org/~mafm/posts/2019/20190617_debian-gnulinux-riscv64-port-in-mid-2019/
======
josteink
Basically LLVM is now a dependency of equal importance to GCC for Debian.

Hopefully this will help motivate expanding architecture-support for LLVM, and
by proxy Rust.

~~~
ncmncm
Godbolt shows that Clang is a lot more aggressive with use of "cmov" \--
conditional move instructions.

When the Spectre and Meltdown family of security debacles surfaced, cmov was
promoted as a way to choke off speculative execution. But that suggests, also,
that cmov would be bad for performance in places where cross-process security
isn't a concern.

Did something important change, or did I misunderstand? Maybe only cmov memory
-> register blocks speculation?

~~~
dbcurtis
CMOV replaces branches. So no branch, no speculation. Typically, though, only
branches that the compiler identifies as not reliably predictable would be
replaced. Because with a well predicted branch you do not waste resources.
CMOV executes both paths, wasting the work of one path, but saving the
mispredict penalty. Which for “flakey” branches can be a overall win.

------
kstenerud
I'm surprised at how m68k was rescued from oblivion in 2013... Who is using
it?

~~~
boomlinde
I suspected that it had something to do with ColdFire. It seems that was
partly true, but another interesting factor was apparently ARAnyM (an Atari
68k ST/TT/Falcon emulator) which can conveniently run a Linux system:
[https://grep.be/blog/en/computer/debian/m68k/arrakis/](https://grep.be/blog/en/computer/debian/m68k/arrakis/)

~~~
0815test
There's also the Apollo core used in the Vampire accelerator, that's much
faster than anything else m68k, and even faster than ColdFire.

~~~
boomlinde
Yes, but that doesn't explain the m68k porting effort of 2013. The Apollo core
doesn't have an MMU so it won't run Linux.

~~~
wolf550e
I thought m68k/nommu exists and is used?

~~~
boomlinde
That's true and I didn't know of that. That said, the Amiga configuration
depends on an MMU. I don't know how hard it would be to retarget it for an
MMU-less system.

------
ncmncm
They say Rust support is blocked by having no RISC-V backed for LLVM, and no
Rust Gcc front-end. But I thought there was a working Gcc front-end, just
without the borrow checker, which is superfluous for code generation. Maybe it
is for an old version of the language, and can't build the current library?

~~~
littlestymaar
AFAIK there's no gcc port underway. There is another Rust compiler[1] but it's
not a complete alternative to Rustc, in the short run it was mainly intended
to be a way to bootstrap a Rust compiler without needing to go all the way
back to the original ocaml implementation of the first Rust compiler. As such,
it is only known to output correct binary when running on the code of the Rust
1.19 compiler. This was a really successful project, but it's not something
you can use to replace to compile your own arbitrary rust code.

[1]
[https://github.com/thepowersgang/mrustc](https://github.com/thepowersgang/mrustc)

~~~
infinity0x-2
Debian Rust maintainer here.

We don't need to bootstrap from scratch, Rust (via LLVM) can cross-compile
very easily once riscv64 support is added.

In practise I am already cross-compiling amd64->mips/mipsel for every stable
Rust release on my home box, because a native mips rustc compile runs out of
memory on those 32-bit machines. [1] The cross-compiled mips works completely
fine to build smaller rust packages, e.g cargo [2] ripgrep [3]

[1] [https://github.com/rust-lang/rust/issues/56888](https://github.com/rust-
lang/rust/issues/56888) [2]
[https://buildd.debian.org/status/package.php?p=cargo](https://buildd.debian.org/status/package.php?p=cargo)
[3] [https://buildd.debian.org/status/package.php?p=rust-
ripgrep](https://buildd.debian.org/status/package.php?p=rust-ripgrep)

~~~
inferiorhuman
Yeah back with 1.14 or so I set up some cross (and native) toolchains for
mipsel with the intent of putting some stuff on my ER-X. While it was a giant
pain in the dick with the unsupported version of Debian Ubiquiti was using, it
was doable. Cross compiling on Debian has come a long way (altho I'm using
crosstool-ng on OSX these days which is fairly slick).

------
ncmncm
I am waiting until the Bitmanip extension lands to get excited about RISC-V:
[https://github.com/riscv/riscv-bitmanip](https://github.com/riscv/riscv-
bitmanip)

Just can't live without that popcount.

~~~
kristianp
What do you need popcount for?

------
sjmulder
Good to see it so far along!

There's some work to be done in rust on portability - it's been a problem in
pkgsrc too.

------
als0
Looking forward to a standardized MMU interface and page table format.

~~~
rwmj
What's the precise problem? As far as I know the privspec has standardized
enough in this area.

In any case, as one of the maintainers of the Fedora/RISC-V port (we also work
closely with Debian) we're relaxed about _kernel_ changes, because those are
simple to make. (The big problems are changes in userspace code and glibc)

------
sschueller
Any "Pi'esc" boards available yet? I would love to run Buster on a RISC-V
board.

Seeedstudio has an "Arduino'esc" RISC-V board for around USD 30 which looks
very interesting. [1]

This board [2] also looks very interesting but is around USD 1000 and I can't
find any comparisons on performance to a "regular" PC. I know these things are
like comparing apples to oranges but I would like to know how for example a
browser performs loading a webpage in comparison with another CPU.

There also appears to be an expansion board with PCI so you can add a GPU for
USD 2000. [3]

[1] [https://www.seeedstudio.com/Sipeed-Maixduino-Kit-for-
RISC-V-...](https://www.seeedstudio.com/Sipeed-Maixduino-Kit-for-RISC-V-AI-
IoT-p-4047.html)

[2] [https://www.sifive.com/boards/hifive-
unleashed](https://www.sifive.com/boards/hifive-unleashed)

[3] [https://www.crowdsupply.com/microsemi/hifive-unleashed-
expan...](https://www.crowdsupply.com/microsemi/hifive-unleashed-expansion-
board)

~~~
carlosedp
The Unleashed board has a performance similar to a Raspberry Pi 3 in cpu terms
but it's biggest bottleneck is that the SD card is running on a SPI bus where
it gets something like 2MB/s. This is due to having the complete SOC as
opensource and the SD card association not allowing open source IP for it's
interface.

~~~
0815test
I think there's some degree of compatibility between SD-card and MMC-card
standards, and that the latter are comparatively more open. Surely that could
solve the open-IP issue?

~~~
q3k
Last time I looked both MMC and SD were JEDEC standards available under the
same terms?

