VisionFive 2 RISC-V

What do you consider “firmware for it”? Does it include the WiFi module? Bluetooth? eMMC firmware? CPU microcode (if any)? The mask ROM for the dozen chips on board? The firmware for the HDMI controller and Ethernet controllers?

Also, do you do it with or without docs/schematics?

Worst case, I can see how such a project could burn through 10 million USD.

It doesn’t make a whole lot of sense to do it against the vendor, because once they roll out a new generation and you’re back to the beginning. As you mention, it’s better to invest the money to convince vendors to release the firmware in the open as a long-term strategy.

1 Like

Then I would suggest you get yourself one! It is a really nice board and ha everything that one would need to get started - four USB3, two gigabit Ethernet, HDMI, micro SD card slot (via SDIO) and even a PCIe NVME M.2 slot!

Oh, here yo got me wrong. Developing a custom SOC silicon chip would cost way north of $10mio. The only firmware that I am currently aware of in the VisionFive2 is the DDR4 PHY firmware, maybe some more tiny ones, I have not looked into it very deeply yet, I could imagine e.g. the HDMI PHY/DSI also having a tiny bit, but I do not know (yet).

Yes, I would think so. It is pretty specialized, confined and tiny, while it would be nice to have it freed it is not super relevant either.

I do not know how far the Imagination drivers for the GPU in the VisionFive2 are along by now but Imagination has publicly stated that they want to release a blob free driver set for it. So even if it is not yet there, and as I said I am not sure about it, it will pretty sure be coming.

I need to more seriously look into the JH7110, geez… just so many other things to do!


They have libreboot on some Arm Chromebooks.

Ideally, I would love to see all firmware 100% open source, but that may not be economically feasible.

I doubt it cost them ten million dollars to get libreboot running on those Arm Chromebooks.

Libreboot touches only 1-2 chips on the board: the CPU, and the embedded controller.

Not Wifi, Bluetooth, Ethernet, HDMI, eMMC, USB, TPM, and the myriad others that make up the complete functionality of a computer. Stopping at 2 chips out of 20 hardly makes something open.

1 Like

I agree; I would like to see a 100% open-source RISC-V computer.

Everything at every level completely open source.

I would make this a thing if I had the money to do so.

That said, it would be nice to have a computer that is as open source as possible; that seems to align with Purism’s business plan, no?

Of course!
And that’s exactly what we are doing since 2014. But we can only do so much and the availability of chips on the market is what limits us, so at some point we have to choose, either go out of business or do some compromise, as little as possible, but still failing to reach the final goal. We need to make money to be able to invest in more open development so at some point we have to bite the bullet and look for the smallest evil.

Take the Librem5 as an example. We really tried super hard to make it RYF. We even jumped through quite some hoops to get there, like confining the necessary firmware parts (like DDR4 init, display controller firmware, TPS firmware etc.) in a separate flash chip, away from the operating system. We even put significant money down and convinced a WiFi chipset maker (RedPine at the time) to move the firmware from a blob in user space onto the card itself (which to me makes no sense, it’s the same firmware just stored somewhere else and all of a sudden it’s RYF conformant!). Just last year we were notified that the RedPine M.2 card will not be available anymore - besides that it had quite some issues. There are no (somewhat current) WiFi chipsets on the market (none!) that do not require a firmware download at run time and the dozens I looked at do not allow to attach an external SPI flash or something anymore to hold it. So the only way is a download through the operating system which then would loose FSF endorsement if this comes from the same source the OS comes from - and the whole device looses RYF. So what are we doing now? We create even further hoops to jump through, the “firmware jail” which will either copy or get mounted from a separate storage (the SPI flash) so that the kernel can load the firmware from there. Except for sticking to the words of the FSF for not loosing the endorsement this only brings issues, nothing else. But we did it, nonetheless.



I wish I could win a billion dollars and make the dream of a 100% open-source computer a reality.

Hopefully, as time goes on, we will get more RISC-V offerings.

Personally, I think the sweet spot would be a device like the VisionFiver2, and if I needed a workstation, I would go for a Talos II desktop.

I simply do not require cutting-edge performance, and I doubt that most people do either for web browsing, YouTube viewing, word processing, or email.

I would be very interested to see if, in the near future, we couldn’t get a RISC-V phone, tablet, laptop, etc. from Purism.

I understand that we may never have 100% open source, but we can take baby steps, right?

Well this card A770 requires PCIe 4.0, DDR 4, reBAR, ME-10th-up to work 100%. As far i know on ARM or AMD or even on intel without ME or old ME enabled just not work at all.

GNU Libreboot just touch the BIOS Chip not the EC.

Yeah, no, I’m not buying any of what you’re saying. Intel itself acknowledges the ARM porting effort:

1 Like

In any case, I’m still not seeing a citation (which you previously requested).

The suggestion that on x86 it will only work if the ME is enabled could be true or might be completely false. Does @carlosgonz own the necessary Intel discrete GPU hardware in order to cite personal experience? Or, if not, can a link to relevant discussion or documentation be provided?

However a statement that on x86 it will only work if the ME is enabled is not as such a claim about what happens on platforms that are not x86. Could Intel somehow engineer it in some twisted way so that the two claims are not connected? I’ll keep an open mind on that until evidence emerges.

It is already stated above that even without the discrete GPU, you are forced to keep the ME enabled if you want S3.

How much worse could it get in future generations of Intel CPUs?

If it reached the point where you simply had to keep the ME enabled (e.g. HAP bit non-existent or ignored) then this specific question about the discrete GPU would be irrelevant.

In many circumstances it could be a reasonable opinion that one ought move away from x86 but as Nicole notes above, it isn’t that simple.

I would love to see Intel face genuine pressure to lift its game. In some weird way that could come from Apple more so than RISC-V at the current time.

I immediately had to think about the MNT Reform and their research in Risc-V.

Maybe they would be willing to evaluate putting an existing SOC like the StarFive StarFive JH7110 onto a CPU board for the MNT Reform to offer an alternative to the pricy MNT RKX7 FPGA Module.

I guess someone would need to organize the customers (and the money) to make it possible.

I bought an A770 graphics card a month ago to use it in a machine with coreboot, this machine has ME disabled, and it is also pcie 3.0(pcie version not matter much), the problem is that i can’t get the A770 card to work, trying to find out why not working, i saw a video of an intel engineer saying that it requires ME enabled to work properly, since then i stopped get work my A770. I wanted the Intel card A770 card because it is AV1 encoder and free software driver, plus powerful gpu.
My computer baseboard it is:


Can you show the video in question? I remember there was some initial misunderstanding about that in the beginning.

Well I guess the test then is … if you don’t disable the ME (HAP bit) then does the graphics card suddenly start working? But of course I understand you might not want to do that test. :wink:

Given that you have paid actual money to buy an actual Intel product … and it isn’t working … maybe you should ask Intel.

1 Like

JH7110 Preliminary Technical Reference Manual including memory map

Well i do not want enable ME. I still have some troubleshooting to test like linux 6.3 and Mesa 23, so i guess that the next evil-opensource-ubuntu version i will use it to testing again.

Yes i will when i found the video.

Right, but still very very incomplete. But I am confident they will complete this. Writing such documentation is very work intense…


1 Like

This was published today: