Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Risc-v
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Gentoo on Alternative Architectures
View previous topic :: View next topic  
Author Message
jlpoole
Guru
Guru


Joined: 01 Nov 2005
Posts: 355
Location: Salem, OR

PostPosted: Thu Aug 21, 2014 1:09 pm    Post subject: Risc-v Reply with quote

This headline caught my attention: RISC creator is pushing open source chips for cloud computing and the internet of things. I learned of it on reddit:

http://www.reddit.com/r/opensource/comments/2e2emz/risc_creator_is_pushing_open_source_chips_for/

Computer scientists at the University of California, Berkeley, are spearheading a movement to create an open source instruction set. RISC-V (Reduced Instruction Set Computing) was originally developed in the Computer Science Division of the EECS Department at the University of California, Berkeley. Their project page is at http://riscv.org/

See also: http://en.wikipedia.org/wiki/Field-programmable_gate_array

This piqued my curiosity, and I found this guide to building a system:

http://riscv.org/download.html#tab_zynqfpga

It seems that there are two platforms where the RISC-V could run on:

Zybo: http://www.xilinx.com/products/boards-and-kits/1-4AZFTE.htm $189

Zedboard: http://www.zedboard.org/buy ~$395?

Has anyone worked with these boards? I'm thinking Gentoo could be installed on one of these and thus have a completely open source computer. Although it may not be practical, it seems to be a step in the direction of being completely self-sufficient and free of black-box technologies and free from potential government intrusion -- an ideal I sense is embraced by the Gentoo community.

Comments?


Last edited by jlpoole on Sat Aug 23, 2014 10:01 pm; edited 1 time in total
Back to top
View user's profile Send private message
John R. Graham
Administrator
Administrator


Joined: 08 Mar 2005
Posts: 10459
Location: Somewhere over Atlanta, Georgia

PostPosted: Thu Aug 21, 2014 3:13 pm    Post subject: Reply with quote

Thanks for that link. Interesting. However, even though they state that their architecture will run at greater than 1 GHz on those FPGA boards, the current cores are in-order execution with minimal cache, which likely translates to performance equivalent to a < 400 MHz Pentium, so I don't see it becoming a practical "daily driver" right away.

- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters.
Back to top
View user's profile Send private message
jlpoole
Guru
Guru


Joined: 01 Nov 2005
Posts: 355
Location: Salem, OR

PostPosted: Thu Aug 21, 2014 3:59 pm    Post subject: Reply with quote

John R. Graham wrote:
Thanks for that link. Interesting. However, even though they state that their architecture will run at greater than 1 GHz on those FPGA boards, the current cores are in-order execution with minimal cache, which likely translates to performance equivalent to a < 400 MHz Pentium, so I don't see it becoming a practical "daily driver" right away.

- John


Would that lack of performance be a result of the architecture, itself, or a result of the fact that it runs on a an FPGA board? I read at http://www.lowrisc.org/ that they are hoping to manufacture a run of chips that might sell for $10 in a couple of years. Would such a chip be, in your guess, have the same problems or competitive with what's available to day from AMD or Intel?
Back to top
View user's profile Send private message
John R. Graham
Administrator
Administrator


Joined: 08 Mar 2005
Posts: 10459
Location: Somewhere over Atlanta, Georgia

PostPosted: Fri Aug 22, 2014 2:27 am    Post subject: Reply with quote

Partially because of the architecture. Absolutely positively not competitive with AMD and Intel, for at least three insurmountable (in the near term) reasons:
  • Clock for clock, CISC provides 2 to 3 x performance vs. RISC.
  • AMD and (especially) Intel have access to semiconductor processes that the RISC-V chip makers simply won't have.
  • There's a huge amount of additional complexity that helps modern x86 run faster (e.g., out of order execution, branch prediction).
- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters.
Back to top
View user's profile Send private message
jlpoole
Guru
Guru


Joined: 01 Nov 2005
Posts: 355
Location: Salem, OR

PostPosted: Fri Aug 22, 2014 2:46 pm    Post subject: Reply with quote

John R. Graham wrote:
Partially because of the architecture. Absolutely positively not competitive with AMD and Intel, for at least three insurmountable (in the near term) reasons:
  • Clock for clock, CISC provides 2 to 3 x performance vs. RISC.
- John


I shared your comments and learned of a paper presented at the 19th IEEE International Symposium on High Performance Computer titled "Architecture Power Struggles: Revisiting the RISC vs. CISC Debate on Contemporary ARM and x86 Architectures" which suggests otherwise:

Quote:
Our study suggests that whether the ISA is RISC or CISC is irrelevant...

Our study suggests that at performance levels in the range of A8 and higher, RISC/CISC is irrelevant for performance, power, and energy.

Thus, while ISA evolution has been continuous, it has focused on enabling specialization and has been largely agnostic of RISC or CISC.

http://research.cs.wisc.edu/vertical/papers/2013/hpca13-isa-power-struggles.pdf


I do not mean to be argumentative, but what you have written sounds very damning for RISC-V and with all due respect, I do not want people to read this thread thinking that statement is the final word on the matter. Your statement above seemed particularly compelling, so I wanted to learn more and share what I found.
Back to top
View user's profile Send private message
_chris
n00b
n00b


Joined: 22 Aug 2014
Posts: 2

PostPosted: Fri Aug 22, 2014 5:18 pm    Post subject: Reply with quote

As a RISC-V user, I would like to clarify a few misconceptions in this thread.

John R. Graham wrote:
Thanks for that link. Interesting. However, even though they state that their architecture will run at greater than 1 GHz on those FPGA boards, the current cores are in-order execution with minimal cache, which likely translates to performance equivalent to a < 400 MHz Pentium, so I don't see it becoming a practical "daily driver" right away.


I believe you misunderstood the links. The provided "Rocket" in-order core runs at well over 1 GHz in silicon. For an FPGA, it depends on what you buy, but I've been able to run it at 100 MHz while using 64kB level 1 caches and 256kB level 2 caches using the above zedboard. Just to make life easy for people with really tiny FPGAs, we provided a version with very small caches. But that's just a parameter.



John R. Graham wrote:
"Clock for clock, CISC provides 2 to 3 x performance vs. RISC."


Incorrect. Modern, high performance CISC processors translate CISC instructions into RISC micro-ops. This is almost always a 1:1 conversion (if they want to see any decent performance anyways). As the previously quoted Wisc "ISA Struggles" paper demonstrated, CISC and RISC are fairly equal in performance- certainly not 2-3x.

John R. Graham wrote:
"AMD and (especially) Intel have access to semiconductor processes that the RISC-V chip makers simply won't have."


Intel's main advantage has always been its foundries. But AMD (and pretty much all other processor companies like NVIDIA and Apple) are fabless.


John R. Graham wrote:
"There's a huge amount of additional complexity that helps modern x86 run faster (e.g., out of order execution, branch prediction)."



OoO and branch prediction are micro-architectural implementation details that are completely orthogonal to the ISA. If anything, x86 makes OoO harder than RISC, requiring incredibly complex decoder units that they attempt to turn off for energy and performance reasons when they can (aka, the "run in RISC mode"). There is no reason RISC-V can't utilize the same micro-architectural features to run as fast as modern x86 processors (and in fact, I know of at least IIT Madras building OoO RISC-V cores). Performance will be dependent on the quality of the implementation, not the instruction set architecture.


John R. Graham wrote:
I don't see it becoming a practical "daily driver" right away.


I think the biggest hurdle to Gentoo on RISC-V would be the device driver story (Linux already works, but most system calls are proxied onto something else, like the ARM core attached to the FPGA). I think "lowrisc" is a good group to follow who are working on building exactly what jlpoole wants - an open-source SoC that can run Linux and talk to your devices.
Back to top
View user's profile Send private message
lowrisc
n00b
n00b


Joined: 23 Aug 2014
Posts: 1

PostPosted: Sat Aug 23, 2014 5:56 pm    Post subject: Reply with quote

Hi all,

yes, as Chris notes, the lowRISC team is aiming to create (and sell, in volume) a RISC-V based SoC. We're a not-for-profit organization.

Our (placeholder) website is at www.lowrisc.org (it has a brief FAQ).

We're also hiring right now! Two positions are open based in Cambridge UK (closing date 9 Sep 2014).

Personally, I'm a huge Gentoo fan (and user), so I hope we will see it running on one of our devices some day. :D
_________________
Gavin
Back to top
View user's profile Send private message
jlpoole
Guru
Guru


Joined: 01 Nov 2005
Posts: 355
Location: Salem, OR

PostPosted: Sat Aug 23, 2014 6:40 pm    Post subject: Reply with quote

Gavin's reputation in the open source world is noteworthy: http://www.gnome.org/news/2013/07/interview-with-gavin-ferris-gnome-privacy-campaign-donor/

In 2007, he started with Ubuntu. As of July 2013 he reconsidered his choice and moved to Gentoo about two years ago, undoubtedly touched by the omniscient one.

I'm pleased to learn of his participation as a principal in this endeavour.

A milestone will be running Gentoo on such a platform and then comparing results from standardized performance tests. It's tempting to try installing Gentoo on a system Zybo or Zedboard (see my prior postings in this thread) just to do a proof-of-concept and have a baseline for performance. Could also compare with my experiences on a Sheeva Plug (1.2GHz Marvell Sheeva CPU), Genesi Efika (Freescale i.MX515 (ARM Cortex-A8 800MHz)), and BeagleBone (AM335x 720MHz ARM® processor) just for kicks.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 46370
Location: 56N 3W

PostPosted: Sat Aug 23, 2014 8:22 pm    Post subject: Reply with quote

I'll stir the pot a little.

its been a long time since AMD or Intel made anything but a RISC CPU.
The microcode just makes their offerings look like CISC systems.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
szatox
Veteran
Veteran


Joined: 27 Aug 2013
Posts: 1944

PostPosted: Sun Aug 24, 2014 4:49 pm    Post subject: Reply with quote

Quote:
its been a long time since AMD or Intel made anything but a RISC CPU.
The microcode just makes their offerings look like CISC systems.
A bit of "what if" kind of question, but..... Would it be possible to recompile our toys and make them use native architecture rather than have RISC pretend CISC?
Would it give noticable performance boost?
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 46370
Location: 56N 3W

PostPosted: Sun Aug 24, 2014 5:04 pm    Post subject: Reply with quote

szatox,

In theory, you can write your own microcode for you CPU but its a daunting task - even when you know which bit in the microcode does what.
The first thing you need to to is to reverse engineer existing an microcode, which itself may not be correct.

In effect, the microcode builds up CISC instructions from a sequence of RISC instructions.
Being able to do that in the microcode will be faster than the extra RISC instructions since less instructions need to be fetched from RAM.

Of course, if you know how the hardware operates maybe you can optimise the microcode better than AMD/Intel but somehow I doubt you have the time for that.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
_chris
n00b
n00b


Joined: 22 Aug 2014
Posts: 2

PostPosted: Sun Aug 24, 2014 9:32 pm    Post subject: Reply with quote

szatox wrote:
Quote:
its been a long time since AMD or Intel made anything but a RISC CPU.
The microcode just makes their offerings look like CISC systems.
A bit of "what if" kind of question, but..... Would it be possible to recompile our toys and make them use native architecture rather than have RISC pretend CISC?
Would it give noticable performance boost?


As NeddySeagoon mentioned, the best you could do is write your own micro-code to govern the x86->RISC uop translation. This has two huge assumptions (which aren't true) - 1) you have the ability to upload your own micro-code and 2) you understand the micro-code.

Unless you are Intel (or the NSA), I don't know of anybody who has the ability to patch micro-code. But let's assume we do...

For performance, most of the x86 instructions are 1:1 to the RISC uops. So there's nothing to gain here. Then there's instructions like string operations, but I bet Intel has put serious development into making those instructions very fast. So I doubt a hacker will do better than Intel.

Of course, if you control the micro-code, you can always add your own x86 instructions that will only run on your own hacked Intel processor. I'm not sure what there is to win here though, especially if you're a RISC person who doesn't believe in heavily micro-coded instructions.

Perhaps what you were really asking is "would there be a performance improvement if we could remove the complicated x86 front-end and direct execute RISC micro-ops with no complicated translation required?" That's a damn good question and the answer is hotly debated. I'll give two answers to that question.

The first is "almost certainly." In fact, high performance x86 processors make use of uop caches to allow them to turn off the x86 fetch and decode front-end, and run "RISC-style" straight out of the uop cache (treating it as a regular RISC L1 instruction cache). This gives Intel significant performance and power savings. So naturally, one would think this would be a win if they could just always get away with it, right?

My second answer is "not really." First, you would need to handle all of the corner cases of executing weird x86 instructions, otherwise you are no longer an x86 processor. So you already need the hardware datapaths for stopping the machine and injecting micro-code. Second, most executed x86 instructions are 1:1 decoded to RISC uops, so they already can basically execute "natively" as is. And this common case datapath is what's on the "critical path" of the machine, allowing it to speculate that it can execute stuff quickly with minimal decode anways. And again, Intel has added uop caches, so they can still stay CISC and get the benefits of RISC, so why bother trying to be "more pure"? Finally, all of the complicated x86 front-end let's them do weird things like micro-op fusion, micro-op cracking, and other such things to get great performance that would match an equivalent RISC machine.

Basically what I'm saying is I suspect CISC and RISC are probably not very different in terms of raw machine performance (although low-power CISC may be very difficult) ... but in terms of ease to build, CISC has got to be a fucking terrible architecture to implement, verify, and debug.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 46370
Location: 56N 3W

PostPosted: Mon Aug 25, 2014 4:39 pm    Post subject: Reply with quote

_chris,

_chris wrote:
... CISC has got to be a fucking terrible architecture to implement, verify, and debug.


There is lots of evidence for that. Consider the early AMD x86 CPUs. They didn't have the same bugs an the Intel chips so there were a few nasty corner cases.
As Intel was the defacto standard for x86, it didn't matter that Intel chips did not work as advertised, just that the AMD offering was different.

AMD learned the lesson and copied the Intel bugs too.

I have been in the position of debugging microcode for an in house embedded system.
It gets really hard when you run out of space in the microcode storage area but you need just one more line.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 3450

PostPosted: Tue Feb 19, 2019 11:26 pm    Post subject: Reply with quote

I just found this rather old thread, and am re-awakening it.

I may well have a need for RISC-V in my day job. I'm looking at something that needs an embedded processor, and I'd like to pick it up off the shelf. Furthermore, due to the nature of the project, I believe I need to fully expose the design and software to the customers, so RISC-V is very handy for that purpose. I might have liked the m6809, from familiarity, code density, and not needing any sort of linking loader or other complex infrastructure, but I also probably need to stay closer to mainstream. For the other stretch, I think it would be good in Rust.

So a quick RISC-V search indicates that there at least is a Gentoo project underway to port to it. Though to be honest, that is completely inappropriate for me, because my use will be embedded - no OS, maybe not even a monitor, just an application, self-test, etc. However it would be best to have a RISC-V ecosystem to work with, get familiar, etc.

To begin, is there a RISC-V emulator somewhere in Gentoo-land? My intent would be to cross-compile, but I'd absolutely need emulation. I'm a long time from even submitting the design, much less seeing hardware. By the way, my usage is ASIC, not fpga.
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
pa4wdh
Guru
Guru


Joined: 16 Dec 2005
Posts: 401

PostPosted: Thu Sep 17, 2020 10:30 am    Post subject: Reply with quote

I hope you don't mind me waking up this old topic :)

Yesterday i got interested in RISC-V after reading this news:
https://www.businesswire.com/news/home/20200914005108/en/SiFive-To-Introduce-New-RISC-V-Processor-Architecture-and-RISC-V-PC-at-Linley-Fall-Virtual-Processor-Conference

Emulation seems to be available via qemu with riscv32 and riscv64 as softmmu and userspace targets.

Is the gentoo project for RISC-V still running?
_________________
The gentoo way of bringing peace to the world:
USE="-war" emerge --newuse @world

Free as in Freedom is not limited to software only:
Music: http://www.jamendo.com
Recipes: http://www.opensourcefood.com
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 3450

PostPosted: Thu Sep 17, 2020 12:21 pm    Post subject: Reply with quote

Presuming the nVidia purchase of ARM goes through, it wouldn't surprise me to see more live in RISC-V. Safe port in the storm, and all of that. It's not clear that ARM will be safe any more, after the purchase.
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
pa4wdh
Guru
Guru


Joined: 16 Dec 2005
Posts: 401

PostPosted: Fri Sep 18, 2020 6:58 am    Post subject: Reply with quote

The nVidia/ARM deal is worrying indeed.

Yesterday i had my first experiment with QEMU for RISC-V and got a fedora version for RISC-V booting. Since this is all emulated it was very slow, but it worked :D
_________________
The gentoo way of bringing peace to the world:
USE="-war" emerge --newuse @world

Free as in Freedom is not limited to software only:
Music: http://www.jamendo.com
Recipes: http://www.opensourcefood.com
Back to top
View user's profile Send private message
jlpoole
Guru
Guru


Joined: 01 Nov 2005
Posts: 355
Location: Salem, OR

PostPosted: Fri Sep 18, 2020 12:06 pm    Post subject: Reply with quote

pa4wdh wrote:
The nVidia/ARM deal is worrying indeed.

Yesterday i had my first experiment with QEMU for RISC-V and got a fedora version for RISC-V booting. Since this is all emulated it was very slow, but it worked :D


https://www.tomshardware.com/news/sifive-readies-risc-v-desktop-pc-for-devs-new-cpus-with-vector-extensions
Back to top
View user's profile Send private message
pa4wdh
Guru
Guru


Joined: 16 Dec 2005
Posts: 401

PostPosted: Fri Sep 18, 2020 2:37 pm    Post subject: Reply with quote

I'm really curious about that hardware ... can't wait for October :)

Is there any documentation or tooling to get gentoo going on a new architecture? I guess i'll have to start by cross-compiling a kernel and toolchain and create a stage1 from that.
_________________
The gentoo way of bringing peace to the world:
USE="-war" emerge --newuse @world

Free as in Freedom is not limited to software only:
Music: http://www.jamendo.com
Recipes: http://www.opensourcefood.com
Back to top
View user's profile Send private message
pa4wdh
Guru
Guru


Joined: 16 Dec 2005
Posts: 401

PostPosted: Thu Oct 15, 2020 5:49 pm    Post subject: Reply with quote

I've been playing with qemu's risc-v emulation a bit and got to the point where i have a working gentoo. I'm sharing my my steps, maybe it helps someone else :) Feedback and tips are welcome too of course.

Crossdev
We need to cross compile a kernel, so we need a risc-v toolchain. To build that we can use crossdev, so first we need to emerge crossdev.
With crossdev installed we can build a risc-v toolchain: crossdev -S -t riscv64-linux-gnu.

Kernel
Now we have a toolchain we can cross-comile the kernel. Download the most recent one from https://kernel.org and unpack it.
Copy the defconfig for risc-v: cp arch/riscv/configs/defconfig .config
Configure the kernel using make ARCH=riscv menuconfig
I added CONFIG_DRM_BOCHS=y and CONFIG_DRM_CIRRUS_QEMU=y to be able to use qemu's graphical display, the serial console is a bit crappy in my opinion.
Quit menuconfig and save the config.
Now actually build the kernel: make ARCH=riscv CROSS_COMPILE=riscv64-gnu-linux- Image
The finished product will be arch/riscv/boot/Image

Disk image
Now create a disk image using dd, for example: dd of=/dev/zero of=disk.img bs=1024k count=2k which will create a 2GB file
Format it: mkfs.ext2 disk.img
Mount the disk image: mount disk.img <some mountpoint>
Download a stage3 tarball here: https://dev.gentoo.org/~dilfridge/stages/
Extract the stage3 tarball in the mountpoint.
Edit etc/inittab and:
- Enable the "s0" line to enable the serial console if yuu want
- Find the line with s0 (serial) or c1 (console) and add -a root to agetty's parameters. This will auto-login root, this is needed because root doesn't have a password yet.
Add the disk to fstab:
/dev/vda / ext2 noatime 0 1 >> etc/fstab (be careful, not /etc/fstab :) )
Umount the image

Qemu
Make sure to set QEMU_SOFTMMU_TARGETS="riscv64" in make.conf and emerge qemu
When that's done, boot your risc-v gentoo with:
Code:

qemu-system-riscv64 -machine virt -smp 2 -m 2G \
  -bios /usr/share/qemu/opensbi-riscv64-virt-fw_jump.bin \
  -kernel <Path to your cross compiled Image> \
  -append "root=/dev/vda net.ifnames=0 console=tty0 ip=dhcp" \
  -usb \
  -device nec-usb-xhci,id=xhci \
  -device usb-kbd,bus=xhci.0 \
  -device bochs-display,xres=640,yres=480 \
  -device virtio-blk-device,drive=hd0 \
  -drive file=<path to disk.img>,format=raw,id=hd0 \
  -netdev user,id=net0 -device e1000e,netdev=net0 \

Once booted (be patient, on my system this takes a few minutes) root will be logged in automatically. Give root a password with the passwd command and remove the autologin from /etc/inittab.

Now you can finish your install as you would do after chrooting into your new install.
Enjoy!

Edit:
Added root autologin to work around not having a root password at first boot, added ip=dhcp to -append line.
_________________
The gentoo way of bringing peace to the world:
USE="-war" emerge --newuse @world

Free as in Freedom is not limited to software only:
Music: http://www.jamendo.com
Recipes: http://www.opensourcefood.com


Last edited by pa4wdh on Sun Oct 18, 2020 11:16 am; edited 1 time in total
Back to top
View user's profile Send private message
pa4wdh
Guru
Guru


Joined: 16 Dec 2005
Posts: 401

PostPosted: Fri Oct 16, 2020 5:34 pm    Post subject: Reply with quote

To get networking going you'll need DHCP. Because there is no dhcp client in the stage3 you'll have to add "ip=dhcp" to the -append line. The kernel will take care of setting up the interface and routing. You'll have to setup the DNS yourself in /etc/resolv.conf.
_________________
The gentoo way of bringing peace to the world:
USE="-war" emerge --newuse @world

Free as in Freedom is not limited to software only:
Music: http://www.jamendo.com
Recipes: http://www.opensourcefood.com
Back to top
View user's profile Send private message
pa4wdh
Guru
Guru


Joined: 16 Dec 2005
Posts: 401

PostPosted: Thu Oct 29, 2020 9:20 pm    Post subject: Reply with quote

Today some more info about the Risc-V PC was revealed:
https://www.sifive.com/blog/the-heart-of-risc-v-development-is-unmatched

Specs look nice, price it a bit higher compared to standard hardware. It doesn't contain video hardware, so GPU with good open source drivers is required. Any ideas? "Good open source drivers" rules out most nVidia and AMD cards s far as I know :)
_________________
The gentoo way of bringing peace to the world:
USE="-war" emerge --newuse @world

Free as in Freedom is not limited to software only:
Music: http://www.jamendo.com
Recipes: http://www.opensourcefood.com
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo on Alternative Architectures All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum