Debian port for RISC-V 64-bit
people.debian.org
people.debian.org
That is IFF they get the specs finalized, and I hope they support Googles VM threads while they're at it.
I'm not so optimistic. I wish the best for them but precedents go against it.
I really want it to succeed, but PowerPC and POWER have left their scars.
1) Talos™ Mainboard for $3,700 for a POWER 8
Why do you think that? In which market? Who's going to pay to market it to SoC vendors and provide the very necessary pre-sales work? You aren't expecting it to put a dent in Intel, are you?
On the software side you've got GCC, LLVM, core boot, Rust, and Google Go, all going there. There are thousands of Fedora and Debian packages already ported.
Several companies exist to support real world implementation by others - they'll help you put RISC V into whatever SoC or system you want.
This is all falling into place for an instruction set that has no production silicon yet. It's going to go somewhere. All it needs is finalized specs and some actual hardware.
Having said all that, one thing desperately missing is a free GPU. If SoCs for the public do arrive soon they will have to come from someone with graphics IP.
I don't expect Intel to be directly affected for a good while, but they will be missing out on whatever markets it takes for the next few years. I do see ARM in grave danger, but not immediately.
There's no shortage of those ..
> It's going to go somewhere
.. why? Could you expand on the "step 2: ???" of the world domination plan?
Some companies are designing RISC V into their products (nVidia, Samsung) but not for user facing applications yet. There are designs in process to bring about something like the raspberry pi, which will bring it to the masses (not the consumer masses). There is a ton of corporate and academic support behind the effort.
But let me offer simple slightly plausible scenarios: What if Google ported Android to it? What if Apple brought iOS to it? What if some other new thing that takes off is based on it?
> What if Google ported Android to it?
OK. So .. what advantages does this offer? Why would they do that? Why would manufacturers choose the unknown option?
> What if Apple brought iOS to it?
Why would they do that? What advantages does it offer?
I'm just asking for the really basic features/advantages/benefits stuff. Preferably including an explanation of why said advantages can't be cloned or overtaken by Intel or ARM.
Having said that, RISC V doesn't need something like that to happen. It's going places already because it's better in a number of ways.
Here, watch this: https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-R...
And notice that they indicate a desire to run a full OS and apps in the future. Tell me that doesn't seem like a step toward Tegra with RISC V.
And then there is Samsung aiming at IoT with it. And others...
I wonder if the Larrabee approach would work here: many simple RISC-V cores running in parallel, with wide vector units and a little specialized hardware (eg texture sampling).
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.
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.
Fortunately that is happening. GCC 7 now has RISC V support and will be the compiler for Fedora 26. They really do need to get the priv spec finalized so kernel patches can go upstream as well. It's falling into place slower than people (both of us included) would like, but it is happening much more so than it did for Power, Sparc, or OpenRisc.
I saw the slides on the VM threads concept. I'm unsure as to the point. A process essentially sees a virtual CPU, multiplexed by a kernel. The point of a hypervisor could be understood as multiplexing things (aka OSes) that weren't written to share hardware.
What exactly is the point of a VM thread, which I understand as something which makes a VM look to a kernel as a process?
There doesn't seem to be any "win". Apart from perhaps making implementing Type II hypervisors, like KVM, easier. My critique of them is that their TCB is far larger than the Type I kind.
And all this for an architecture that doesn't have any legacy binary software... very strange.
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?
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).
> Burn: RISC architecture is going to change everything. > Cool: Yeah, RISC is good...
https://unix.stackexchange.com/questions/190350/mmu-less-ker...
Linux will run in 8 megabytes of RAM if you want. The SiFive board has 16 kilobytes.
I saw Flash as the larger limitation, as expanding that is problematic.
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.
[1] http://dmitry.gr/index.php?r=05.Projects&proj=07.%20Linux%20...
There are other companies on the verge of releasing hardware implementations. But in every case, I would wait for the final specs before jumping on any particular hardware even if it shipped now. Other than the micro controllers of course.
Basically, it enables you to do hard real-time tasks like signal generation (controlling led matrices, audio) or fast data/signal acquisition, but without running some specialty os. The minion cores can read+write memory from the main cpu that's running normal Linux.
That feature also gives them a little breathing room on initial pricing. Their SoC board would be viewed as competition for a $70 board, instead of competition for a cheaper Raspberry PI or similar. So, initial pricing wouldn't necessarily hurt the popularity.
They seem to plan to have something out either this year, or sometime next year: "We are expecting to crowdfund an initial instantiation of the lowRISC platform during the course of 2017."
[1]http://www.lowrisc.org/downloads/lowRISC-memo-2014-001.pdf