Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A trustworthy, free (libre), Linux capable, self-hosting 64bit RISC-V computer

contrib.andrew.cmu.edu

Post reply on HN
Print view View original

11–20 of 59 posts

Re: A trustworthy, free (libre), Linux capable, self-hosting 64bit RISC-V computer

#11

Post by bitcompost »

shrubble wrote: post #9
bitcompost wrote: post #5

While I love the idea of self-hosting HW and SW, I can't even imagine the pain of building stuff like GCC on 60Mhz CPU. Not to mention the Rocket CPU is written in Scala. I recently stopped using Gentoo on RockPro64, because the compile times were unbearable, and that's a system orders of magnitude faster than what they want to use.

People used 50Mhz SPARC systems to do real work, and the peripherals were all a lot slower (10mbps Ethernet, slower SCSI drives) with less and slower RAM. But it might take a week to compile everything you wanted, I agree; of course there is always cross-compiling as well.

Oh I believe in theory a 50Mhz CPU is capable of doing almost everything I need, but it just lacks the software optimized for it. I think a week to compile everything is too optimistic.

Re: A trustworthy, free (libre), Linux capable, self-hosting 64bit RISC-V computer

#12

Post by RobotToaster »

shrubble wrote: post #9
bitcompost wrote: post #5

While I love the idea of self-hosting HW and SW, I can't even imagine the pain of building stuff like GCC on 60Mhz CPU. Not to mention the Rocket CPU is written in Scala. I recently stopped using Gentoo on RockPro64, because the compile times were unbearable, and that's a system orders of magnitude faster than what they want to use.

People used 50Mhz SPARC systems to do real work, and the peripherals were all a lot slower (10mbps Ethernet, slower SCSI drives) with less and slower RAM. But it might take a week to compile everything you wanted, I agree; of course there is always cross-compiling as well.

That was before everything became a snap package in a docker image.

Re: A trustworthy, free (libre), Linux capable, self-hosting 64bit RISC-V computer

#13

Post by nxobject »

amelius wrote: post #7

> The chip foundry wouldn't know what the FPGA will be used for, and where the proverbial "privilege bit" will end up being laid out on the chip, which mitigates against Privilege Escalation hardware backdoors. Exposure is limited to DoS attacks being planted into the silicon during FPGA fabrication, which yields a significantly improved level of assurance (i.e., the computer may stop working altogether, but can't be…

I wonder as well whether it wouldn't just be easier to snoop I/O and somehow exfiltrate the data. (This would be completely impractical for dragnet surveillance, of course – but I'm sure if a state actor knew that some organization was using this technique to avoid surveillance, _and_ was using a predictable software setup...)

Re: A trustworthy, free (libre), Linux capable, self-hosting 64bit RISC-V computer

#14

Post by ruslan »

I'm kind of going the same direction, but different route. My design is based on VexRiscv and all hardware is written in SpinalHDL. It does not run Linux yet because of limited SRAM (512KB) on my Karnix board, but it has Ethernet and HDMI. I have coded a CGA-like video adapter with HDMI interface that supports graphics (320x240x4) and text (80x30x16) modes with hardware assisted smooth scrolling. :)

If someone is interested, here's a rather brief README: https://github.com/Fabmicro-LLC/VexRiscvWithKarnix/blob/karn...

KiCAD project for the board: https://github.com/Fabmicro-LLC/Karnix_ASB-254

Re: A trustworthy, free (libre), Linux capable, self-hosting 64bit RISC-V computer

#15

Post by rwmj »

amelius wrote: post #7

> The chip foundry wouldn't know what the FPGA will be used for, and where the proverbial "privilege bit" will end up being laid out on the chip, which mitigates against Privilege Escalation hardware backdoors. Exposure is limited to DoS attacks being planted into the silicon during FPGA fabrication, which yields a significantly improved level of assurance (i.e., the computer may stop working altogether, but can't be…

For a nation state the most useful thing would be a "kill bit" where you can broadcast some signal or key and disable all your enemy's computers. That's fairly easy to do in an FPGA - the signal would be detected by the serdes block(s) and the kill bit could just kill the power or clock or some other vital part of the chip.

Re: A trustworthy, free (libre), Linux capable, self-hosting 64bit RISC-V computer

#16

Post by sweetjuly »

bitcompost wrote: post #5

While I love the idea of self-hosting HW and SW, I can't even imagine the pain of building stuff like GCC on 60Mhz CPU. Not to mention the Rocket CPU is written in Scala. I recently stopped using Gentoo on RockPro64, because the compile times were unbearable, and that's a system orders of magnitude faster than what they want to use.

You can definitely go considerably faster. A lot of these FOSS cores are either outright unoptimized or target ASICs and so end up performing very badly on FPGAs. A well designed core on a modern FPGA (not one of these bottom of the barrel low power Lattice parts) can definitely hit 250+ MHz with a much more powerful microarch. It's neither cheap nor easy which is why we tend not to see it in the hobby space. That, and better FPGAs tend not to have FOSS toolchains and so it doesn't quite meet the libre spirit.

But, yes, even at 250MHz trying to run Chipyard on a softcore would certainly be an exercise in patience :)

Re: A trustworthy, free (libre), Linux capable, self-hosting 64bit RISC-V computer

#17

Post by musicale »

Rebuilding the system on itself and validating that the bitfile is the same is nice.

I'm amazed that it could be rebuilt in 512MB (and in "only" 4.5 hours on a ~65MHz CPU.) My experience with yosys (and vivado etc.) is that they seem to want many gigabytes.

> A 65MHz Linux-capable CPU inevitably invokes memories of mid- 1990s Intel 486 and first-generation Pentium processors.

50-65MHz* and 512MB seems comparable to an early 1990s Unix workstation. Arguably better on the RAM side.

*4.5 Mflops on double precision linpack for lowRISC/50MHz

Re: A trustworthy, free (libre), Linux capable, self-hosting 64bit RISC-V computer

#18

Post by kwhitefoot »

bitcompost wrote: post #11
shrubble wrote: post #9

Earlier quoted context omitted.

People used 50Mhz SPARC systems to do real work, and the peripherals were all a lot slower (10mbps Ethernet, slower SCSI drives) with less and slower RAM. But it might take a week to compile everything you wanted, I agree; of course there is always cross-compiling as well.

Oh I believe in theory a 50Mhz CPU is capable of doing almost everything I need, but it just lacks the software optimized for it. I think a week to compile everything is too optimistic.

I did valuable work on a 2 MHz Apple II with a 4 MHz Z80 add-on running CP/M that I used to write the documentation. The documentation part was just as fast forty years ago as it is now but assembling the code was glacially slow. The 6502 macro assembler running on the Apple too forty minutes to assemble code that filled an 8 k EPROM.

Re: A trustworthy, free (libre), Linux capable, self-hosting 64bit RISC-V computer

#19

Post by admax88qqq »

amelius wrote: post #7

> The chip foundry wouldn't know what the FPGA will be used for, and where the proverbial "privilege bit" will end up being laid out on the chip, which mitigates against Privilege Escalation hardware backdoors. Exposure is limited to DoS attacks being planted into the silicon during FPGA fabrication, which yields a significantly improved level of assurance (i.e., the computer may stop working altogether, but can't be…

Without having thought it through fully I feel like the classic "trusting trust" attack could work at the fpga/bitstream level.

Re: A trustworthy, free (libre), Linux capable, self-hosting 64bit RISC-V computer

#20

Post by dwheeler »

bitcompost wrote: post #5

While I love the idea of self-hosting HW and SW, I can't even imagine the pain of building stuff like GCC on 60Mhz CPU. Not to mention the Rocket CPU is written in Scala. I recently stopped using Gentoo on RockPro64, because the compile times were unbearable, and that's a system orders of magnitude faster than what they want to use.

At one time many of us dreamed of having a computer that could run as fast as 60MHz. The first computers I used ran around 1MHz. Compilation will take longer on a slower machine, but that really isn't a big deal. If the computer is reliable and the build scripts are correct, you can just let the process run over days or weeks. I've run many tasks in my life that took days or weeks. Cue "compiling": https://xkcd.com/303/

The real problem is debugging. Debugging the process on a slow system can be unpleasant due to long turn-arounds. Historically the solution is to work in stages & be able to restart at different points (so you don't have to do the whole process each time). That would work here too. In this case, there's an additional option: you can debug the scripts on a much faster though less trustworthy system. Then, once it works, you can run it on the slower system.

Post reply on HN