There is a relevant comment on the article, reproducing here in case it gets edited out:

"Hi DigitalEngineer,

I am a member of the PULP group as a researcher in both University of Bologna and ETH Zurich.

You are right that the tool chain and the multi-core platform have not been released in the open yet. However, we are working hard toward releasing both of them - we never intended PULPino to be the "final" step in open-sourcing the PULP platform, but merely the first step. Eventually, our plan is to release the whole platform, save of course for IPs that depend on private agreements between ETHand/or University of Bologna and other parties.

For several reasons our RISC-V toolchain could not be open-sourced together with PULPino. I cannot give a definite date, but we should be able to solve most problems related with it relatively soon, and then it will be open-sourced immediately.

For a public release of the multi-core platform (which is one of our main objectives - hence the name PULP that stands for Parallel Ultra-Low Power Platform), there will be need of a bit more time. We want this to be well polished and ready. However, parties interested in collaborating can already contact us privately (e.g. via the contacts on our website http://pulp-platform.org).

Hope this solves some of your doubts!"

Key points

- RISC-V implementation

"The PULP quad-core IC was subject of a tape-out in 28nm from Globalfoundries in November 2015 while the first PULPino implementation (called Imperio) taped out in January 2016 in 65nm CMOS from UMC. The PULPino platform is available for RTL simulation, for FPGA and SoC . It has full debug support on all targets and includes a port of FreeRTOS. Operating at a clock frequency of 400MHz and 1.2V the chip consumes 32.8mW."

License is this:

"SOLDERPAD HARDWARE LICENSE version 0.51

This license is based closely on the Apache License Version 2.0, but is not approved or endorsed by the Apache Foundation."

See https://github.com/pulp-platform/pulpino

Apparently it has enough features to run FreeRTOS, but I don't think it comes with an MMU to run anything beefier. It's a microcontroller. However, there's nothing stopping someone trying to build a better SoC around it..

RISC-V protected mode is still being worked out.

Here is a slide deck that goes into greater detail on the architecture. Speaks more to design choices and PULP project goals:

http://riscv.org/wp-content/uploads/2016/01/Wed1315-PULP-ris...

I wonder how far are we from being able to produce a completely open-source laptop with an open source CPU core? Quite far, it seems, judging by the facts that this is still in development, and protected mode is still being figured out. 5 years, maybe?

The lowRISC team (http://www.lowrisc.org/) aims to develop a Linux capable open source SoC based on RISC-V. They want to use the PULPino RI5CY for their minion cores.

The PULP team added a release plan how they proceed with open source: http://www.pulp-platform.org/release-plan/

libreboot is a BIOS/firmware replacement, and works only on x86 and ARM.

The chip in this article is a microcontroller, not a full-on application processor. Seems like libreboot would be senseless on a platform such as this.

I don't really understand the connection, please explain what you mean?

The only connection is my absolutely dreadful understanding of electronics in general :-)

coreboot (that libreboot is built upon) also supports MIPS, RISC-V, and has ongoing development for Power8. More platforms can certainly be supported.

This is relevant in this case because the chip in question is also RISC-V based...

As I said to the parent poster, my knowledge of electronics is atrocious - but does this mean that the chip could be used as a BIOS replacement?

If not, then I guess I start to wonder what prevents someone from designing such a chip - there seems to be a demand. Almost more demand than a CPU!

The issues people find in contemporary systems are inside the CPU or chipset (and the distinction between these two is blurring more and more due to increasing levels of integration).

The "BIOS" (or rather: firmware in general; BIOS being one specification of a firmware interface) is software, just highly specific for the device in question and stored in a flash chip that is available to the CPU from the start.

For firmware, there are alternatives such as coreboot, but they're limited by what the CPU/chipset come with. If they feature a coprocessor that runs before the CPU even starts (and in fact starts the CPU), has full access to all kinds of hardware (eg. RAM), and that is only running code signed by the chip's vendor, the CPU firmware can't outsmart that.

And so the Intel Management Engine, AMD's Platform Security Processor and similar less than brilliant functions exist in contemporary hardware, and the only chance to get rid of them is to evaluate other platforms (and that means CPUs) that ship without such extras. Which is what Timothy (author of that email) is doing.

On the upside, a new architecture isn't as frightening when you're shopping for fully open source platforms, since stuff is (for the most part) just a recompile away.

Typically the bootloader/BIOS for microcontrollers are very simple, and are really only needed to allow for easy software updates without needing JTAG or other vendor specific updating hardware.