Debian Riscv64 port in mid 2019 • Hacker News Board

Re: Debian Riscv64 port in mid 2019

#61

Post by rwmj » Wed, Jun 19, 2019, 11:11 PM UTC

ccffph wrote: post #54

rwmj wrote: post #41

Earlier quoted context omitted.

I wouldn't hold your breath (although I wish them luck). There are however a bunch of low cost high performance RV64 chips coming this year and next from China that will change things dramatically. (I'm a Fedora/RISC-V maintainer, and I'm in Beijing today and tomorrow talking to RISC-V people. It's 23:57 here, got to go to bed :-/ )

Do you know what companies are making them? I'd love to take a closer look as I've also been looking for a risc-v rpi alternative.

As is always the way with these things, unfortunately I'm under an NDA until the products are released. However I can tell you the rather obvious thing: We're helping them to understand how to get changes they need integrated into upstream communities (kernel, GCC, binutils, uboot in particular) so that their hardware will boot without patching when or soon after it is released.

Re: Debian Riscv64 port in mid 2019

#62

Post by [deleted] » Wed, Jun 19, 2019, 11:56 PM UTC

ncmncm wrote: post #19

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?

[deleted]

Re: Debian Riscv64 port in mid 2019

#63

Post by infinity0x-2 » Wed, Jun 19, 2019, 11:59 PM UTC

littlestymaar wrote: post #34

ncmncm wrote: post #19

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?

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 reall…

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 [2] https://buildd.debian.org/status/package.php?p=cargo [3] https://buildd.debian.org/status/package.php?p=rust-ripgrep

Re: Debian Riscv64 port in mid 2019

#64

Post by xuejie » Thu, Jun 20, 2019, 1:11 AM UTC

ncmncm wrote: post #19

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?

Nightly Rust already has basic RISC-V support, but the problem is Rust's libc binding is not yet ported to RISC-V. Without libc, Rust's std will not be usable, that's the main blocker here. While the theory is you don't require std to compile a Rust program, most, if not all, Rust programs leverage std in some extent.

Re: Debian Riscv64 port in mid 2019

#65

Post by kristianp » Thu, Jun 20, 2019, 4:46 AM UTC

ncmncm wrote: post #26

I am waiting until the Bitmanip extension lands to get excited about RISC-V: https://github.com/riscv/riscv-bitmanip Just can't live without that popcount.

What do you need popcount for?

Re: Debian Riscv64 port in mid 2019

#66

Post by inferiorhuman » Thu, Jun 20, 2019, 6:15 AM UTC

infinity0x-2 wrote: post #63

littlestymaar wrote: post #34

Earlier quoted context omitted.

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 reall…

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…

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).

Re: Debian Riscv64 port in mid 2019

#67

Post by snvzz » Thu, Jun 20, 2019, 10:12 AM UTC

ekianjo wrote: post #31

snvzz wrote: post #18

Earlier quoted context omitted.

Amiga users (like me), Atari users, x68000 users and mac classic users, among others. Some of these are using netbsd/m68k (like me), with some overlap.

Are you using mainly Debian on the command line on m68k, or actually running a GUI?

Currently away from my A1200 so I haven't touched it in ~3yr.

I'm hoping to move my A1200 to my current location soon and install current versions. The A500+ and A600 I have with me do not have a capable (MMU) CPU.

The last time I had cli-only on Debian (couldn't get X to work), and had X on netbsd.

No GPU, just AGA. Any GPU would make X much easier AIUI.

Re: Debian Riscv64 port in mid 2019

#68

Post by snvzz » Thu, Jun 20, 2019, 10:15 AM UTC

boomlinde wrote: post #60

monocasa wrote: post #56

Earlier quoted context omitted.

Wait, even a 68040 embedded the MMU on die. The Apollo core doesn't have a MMU?

I frequently see it advertised as not having an MMU, but it turns out that it does...it's just that it's a new design that isn't Motorola compatible. On Amiga, where programs typically all live in the same shared memory space, this is not a great concern for a regular user. It could be useful for developers and some specialist applications, and of course for more modern OS models.

Apollo-Core could certainly use better documentation.

I own a V500v2+ and it's an awesome board, but this kind of thing drives me nuts.

It has other silly limitations, such as the kickstart being embedded in the fpga core, which is not open source. There's no way for an user to boot to a custom kickstart; At most, it's possible to softkick one after first boot.