RISC-V is the future.
Please help us get a computer based on RISC-V with fully open source firmware, drivers, and software.
Right now VisionFive 2 looks to be a great product and with the communities help it could be made more open source, with open source drivers and firmware.
So, first of all, thank you for bringing this up 
Actually I also have ordered one of the VisionFive2 boards and am already tinkering with it. I already previously got myself a THEAD T810 board (that’s by Alibaba) and a SiFive’s Unmatched. The problem with the T810 and the Unmatched was, while these were already nice boards for Linux development, the CPUs/SOCs on them were not really available for custom designs - and their performance was still, well, not great.
The JH7110 by StarFive is changing this. I got in touch with them and they confirmed to me that the JH7110 will become available to third parties as a standalone product, i.e. the chip itself. This is great! A year ago at the RISC-V summit in San Francisco I also talked to the Imagination GPU folks and they confirmed that they are working on and will release full open source drivers for their GPU block for RISC-V. Also great! Although the open source driver will not contain the full bandwidth of functions they can support, some features will only be available with proprietary drivers and special toolchains. Oh well.
As of today I have a full open source Debian running on my VisionFive2 - with some GUI issues since the Imagination drivers for the JH7110 are not super stable yet. But it will get there, I am pretty confident.
But here comes the caveat.
Even though the RISC-V ISA is free and many many things around RISC-V are also pretty open and free this does not guarantee a blob free software ecosystem. I just mention it here for the sake a completeness. The JH7110 seems, as far as I know, very promising for being very close to blob free, yes, but not fully. Still the LPDDR4 PHY firmware is needed (included in UBoot) and I think we will not see a free replacement for this any time soon.
We had this discussion about firmware and blobs a couple of times already and my take on this is less strict as the RYF. Yes, of course in an ideal world we want to have everything free and open. But we are not living in this ideal world so we have to cope with reality somehow and come up with a reasonable middleground that will not cut us off from hardware supplies for our software development and in the end our work needs - I am not doing all this work just for the sake of enjoying development but to create something that I and other people can actually do work with.
I explained my stance on firmware a couple of times, last time here.
Nevertheless, the JH7110 is very promising in this regard too, not 100% blob free but pretty close and the parts that are not free I am not very concerned about. I would be concerned about blobs that are running in kernel space, closed source libraries in user space or proprietary firmware running on peripherals that have very low level access to private data, i.e. peripherals directly attached to the memory bus without IOMMU. But this is not the case here.
My biggest concerns with blobs are about freedom and security.
With freedom I mean that a blob must not limit my choice of free software eco system that I run. It must not limit me to some combination of software runtime or kernel version. And I must be free to copy and combine this blob onto and with anything I see fit. These freedoms must be perpetual, i.e. the proprietor of the blob must not be able to revoke these rights at a later point in time. So as long as this criteria is met I am frankly quite fine with some arbitrary piece of firmware blob that gets shot into some peripheral by a free kernel driver or used by a bootloader to bootstrap some piece of hardware. To me this does not make any difference to this firmware being stored on some flash chip on that peripheral, which e.g. RYF would allow it to be. Even in the contrary if I am in control over the blob by having it stored on my storage device instead of some flash chip that I eventually can not even access, then I prefer the firmware being on my storage under my control. Because this then gives me one more freedom: I get control over this blob, I can eventually have different versions, I can choose to have it downloaded or not, I can replace it and eventually even replace it with something free at some fine day. All that is not possible if the firmware is stored hidden away and, as RYF would require it to be, read only. Makes no sense to me.
With security I mean that in general, firmware aside, we always have to be aware that peripherals can be pretty sophisticated, can run their own software and can have very low level interfaces into the hardware that could eventually allow them to do malicious things. A peripheral sitting directly on the memory bus for example could eventually snoop on the memory, scan it for password and keys and exfiltrate them to $somewhere for retrieval. So when we are talking about firmware we also have to consider how complex the peripheral is that this is running on, which capabilities it might have, which access to other parts of the system and which kind of security threat this could create. This is not always easy.
Let’s take the DDR4 PHY as a first example. The DDR4 PHY is a very tiny logic part of the SOC. Yes, it sits directly attached to the RAM, quite naturally, but the PHY’s only function is to do the physical attachment of the SOC to the DDR4 RAM, controlling signal strength, impedance etc. but it does not understand the data getting pushed through that afterwards and also has no means to run complicated intelligence operations on the data. The PHY firmware only gets executed once after initial power on reset to tune the signal lines to the DDR4, that’s it. I do not know 100% for sure since this would require a really in depth research, but I am fairly sure that there is little to no security risk in it. As for the freedom part it is a tiny piece of hex dump firmware that usually gets rolled into UBoot, downloaded and triggered for execution only once after power on.
It is not what I and all freedom lovers would ideally like to have, but I am OK with that. Better having it this way than not being able to use the hardware at all.
And while talking about DDR4 and LPDDR4 in special, as far as I know the reason for the PHY firmware to be proprietary closed and a blob is that the line training algorithms seem to be an “intellectual property” minefield with patent wars going on between the different PHY block makers. AFAIK there is not a single open source implementation of LPDDR4 training out there. There seems to be some free software for the Alwinner A64 that can run a system without that blob but this just works by skipping the training and instead using hardcoded values taken from a running system. While this can work for many boards this can fail if something even very subtle changes. The training is not done in vain, DDR4 timing and signal optimization is critically important so I would not want to rely on some fixed values. (This worked for DDR3 and before but not with DDR4 and later.)
Another more critical example would be GPU firmware. The GPU is a very powerful computing device (see CUDA / OpenCL), it has a very powerful interface into the system (high bandwidth PCIe or sitting directly on the memory bus in SOCs) and, almost worst of all, gets very tightly integrated into the whole runtime - from kernel drivers, user space libraries and into user applications. There are many spots where a rogue GPU program could compute and exfiltrate critical user data. We also know that some GPUs use humongously large firmware blobs - NVIDIA to point out an example. This is a huge piece of mystery code that will run on a very powerful coprocessor (GPU) and has a lot of access to a lot of data. This can create a risk. But also this risk can be mitigated through the means of e.g. an IOMMU.
So what I am trying to say here is, that I think that the potential security risk of a blob must be evaluated on a case by case basis. And let’s also be clear that putting this firmware in a ROM on the card and taking it out of the user’s sight, which would be fine according to RYF, will not change a thing concerning the security risk. I would even say that putting it out of reach of the user is even worse because then you do not have any means anymore to control it.
IMHO RYF does not fit this day and age anymore, it needs to be updated. Insisting in RYF is debilitating and impairing, even free software development, since it cuts us off from current hardware. And RYF does not make sense, it never fully made sense, it just happened to work for quite some time when we still had hard baked ROMs in our hardware. But no one does that anymore, too expensive and too limiting.
So coming back to RISC-V and the JH7110 in special, yes, be assured that we are watching this very closely, I am in touch with StarFive and we are looking into what we can do with it 
Cheers
nicole
Hi Nicole,
Thank you for your amazing response.
Hopefully one day a custom SOC could be built on previous memory technologies like ddr2 or ddr1 even if needed as a workaround to the ddr4 firmware blob issue.
Really all I want is a computer that can watch video like YouTube, do emails, word processing, etc.
I’d say the vast majority of people looking for a computer running fully open source firmware drivers and software are probably in this demographic.
I don’t think that newer memory technologies are really that necessary.
My librebooted Lenovo t400 runs a core2Duo with ddr3 and it works just fine, but I would assume ddr2 would as well.
As long as I can slap a solid state drive in it I’m okay with an older memory technology it’s not a big deal for me at least.
What bothers me is the fact that I’m not in control of my computer I don’t know what’s running in the background and even if whoever put it there has my best interests at heart what happens if some bad actor discovers this back door vulnerability that’s sitting there it’s very unsettling to think that I’m not in control of my machine.
I really want my daily driver to be as open source as is possible with as few known potential back doors as is possible.
I apologize that I cannot go into further detail as the specifics were discussed with me in confidence, but here is my personal take on StarFive. Some of this will sound very subjective, but it’s a topic I’m very passionate/angry about:
@nicole.faerber I would neither recommend StarFive as a business partner nor recommend supporting their IP. Yes, it’s great that they delivered the VisionFive board, but they performed some incredibly shady business practices to get there.
I was one of the 300 recipients of the BeagleV Starlight boards, which was a collaboration between the BeagleBoard Foundation, Seeed Studio and StarFive, and was a truly groundbreaking effort to revolutionize RISC-V computing and FOSS development. As many of you know, it failed to meet production. The startling news of its cancellation came very abruptly to everyone and the reasons were very vague.
Having some additional insight, I believe that StarFive cooperated with partners long enough to have the board design files and expertise required to spin a board of their own. It’s very suspicious how they had the designs in hand, started dragging their feet with development and not pulling their weight in the partnership, then turned around and quickly developed a board of their own. Unfortunately for the BeagleV Starlight project, there was no breach of contract because none was ever made; everything was a non-legally-binding private agreement between the associated companies.
Take from this what you will; it’s just my opinion, after all.
Yeah, I also hear a bit about the back and forth and final cancellation of the BeagleV Starlight. I do not know any background info on it so can not comment.
Though what I do know is that StarFive is a silicon company not a board maker. The VisionFive2 is just a development vehicle not their real product, the product is the JH7110 SOC. We’ll have to see how this evolves. They still have to publish the full datasheet etc. And I also have no information for ordering the part itself etc. So we’ll have to see about all that. Since StarFive is basically a subsidiary of SiFive I have at least some hopes in them.
But I can of course also understand the disappointment about a seemingly done deal like the BeagleV Starlight not being realized.
We’ll see. Once they can supply us with datasheet and actual parts we will know more.
Cheers
nicole
Opensource will never give you a fully opensource machine because opensource.
FreeSoftware has a sharp and solid vision for a Libre Hardware machine RYF. Of course the linux-opensource will have more elegant machines than RYF, but less libre and inseguro and sinprivacidad.
If your T400 is 35watts PCB you can go up to 3ghz DUO, which you don’t need spend for other machine because Intel microprocessor Penryn it the best and FSFRYF verified.
Then there are the geopolitical considerations. I don’t want at all to start a big geopolitical discussion, only to indicate that those considerations exist.
This is great news. I wonder if it makes sense to release some kind of hobby board before making a retail product with this.
I have put a lot of self hosting stuff on hold, and made upgrades very infrequent because of the lack of ECC memory for low end hardware. Is there any cost to adding ECC to the RISC-V platform? I would guess it would be undesirable for devices that run on a battery. But if it is going to be serving my data, it will have ECC.
The VisionFIve2 is that kind of board?
This would require a different memory controller. For sure possible but this would need to be changed on the silicon, i.e. the JH7110. Since the full datasheet is not out there (yet) it is hard to say if the memory controller can or can not support ECC.
Cheers
nicole
This very unlikely to happen. You will want these new memory technolgies for their speed and RAM speed is becoming more and more crucial since software is becoming more and more complex and larger. I started with Linux in 1991 with a 4MB (yes mega bytes) 80386DX @ 40MHz, at first even without FPU, later added the 80387 FPU. Today you are looking at over 100MB as a kind of minimum for a Linux kernel to run, without GUI - back in 1991 I was even running X11 on it - in 4MB (and quickly realized that this did not work well, so I got myself 8MB
While I can understand the desire to have everything as free as possible I fail to understand why something tiny like a piece of PHY firmware would do any harm? Please also consider that your touchpad has a firmware, but built into it, you do not see it, your Thinkpad trackpoint has a firmware, the embedded controller controlling power sequencing, charging etc. has a firmware, the WiFi card you are using very likely has a firmware, even if it is baked into some ROM on the card itself.
You almost can not avoid firmware. But all hell breaks loose if this firmware suddenly becomes visible and tangible? I do not get it. If I have the choice between a hidden away firmware I can not see, look at, analyze and change or a firmware I can see on my file system, can analyze (with tools like Ghidra for example), that I can tweak because it is just a file as anything, that I can replace etc., then I most definitely want the file on my disk and not some mystery code in mystery storage with mystery access.
Again, of course I would most prefer the third option, a free firmware. But as long as this does not exist? Then I take the blob on disk and very much prefer this over non changeable firmware baked into some piece of silicon. The file on disk gives me freedom, the baked silicon takes it. I favor more over less freedom.
Cheers
nicole
This.
I shudder to think how a current CPU would perform if it was forced back to DDR2 speeds (hypothetically speaking).
As it is, the CPU is generally slowed down by the RAM (hence the proliferation of CPU tricks to paper over the gap in speed between the faster CPU and the slower RAM).
So if someone (not me!) wants DDR2 or DDR1 RAM speed then it would be best to slow down the CPU also.
One minor problem with that is if the card (hardware component) will only accept a digitally signed file. So it gives you flexibility to apply updates but only if they come from the approved source (let’s say from the manufacturer). If the hardware becomes abandonware then a file on disk becomes effectively non-changeable, in which case it might be safer to have unchangeable ROM.
For example, a file on disk can be subject to a downgrade attack where an older firmware version (v2) that is signed by the manufacturer but which has publicly known vulnerabilities can be substituted for the latest firmware version (v3) which does not have that vulnerability, whereas v1 didn’t have the vulnerability at all. (Yes, this is a slightly artificial example.)
For me, what this means is that “free” is not binary, is not black and white. There are shades of grey regarding what you can do and what benefits you get and what potential problems you get.
I guess it is just to have the easy option to have the operating system libre of blobs at the first step. Second big step will be full free firmware of controller. Like talos or mntReform-rbz but still hard with hhd firmwares. What i see is that there is too much fragmentation in soft and hard, which reduces the chance of finishing a specific target.
So GNU RYF just mean libre of blobs for booting… which Librem14 does not pass the RYF test because it requires like 3 blobs for booting thank to intel for this. So final stage will be GNU FRYF which means libre of blobs not only for booting but on the whole machine.
Ideally, I would like to see something as open-source as is humanly possible. I still have older machines running DDR2, and they run just fine and can still do 99% of what I need out of a computer. I would imagine that a fully open-source computer would be used for the basics and not for 3D rendering, gaming, or other intensive workloads. I think most people in the customer demographic would use the machine for very basic tasks. Word processing, email, YouTube, etc.
So the idea here, at least for me, would be a fully open-source computer at all levels: hardware, firmware, drivers, and software.
Everything that can be subjected to a security audit should be.
Short of that, I would like to have everything be as open as is economically feasible for a commercial product.
If the memory controller firmware blob can’t be opened up for some reason and there is no economically viable alternative, then I guess that would have to do.
For me, the reason for all this is that I don’t know what my system is doing; could a small CPU, memory, ROM, etc. be acting as a backdoor?
We don’t know what we don’t know, so this is an unknown unknown.
I would prefer a computer that was as open as is possible at all levels.
Sunlight is the best disinfectant.
I was not sure how different a Purism board would be. If you can make a product that is not too different than a VisionFive, primary component wise, then I agree that another one would be unnecessary. I was assuming that a product would require significant customization or innovation from the VisionFive. Personally, I would prefer chips that support the AV1 codec, and if I have to put off upgrading until that is available, then that is likely what I will do.
I was kind of hoping that Purism would make use of their i.MX 8 investment more before switching directions towards RISC-V. I think that we are long overdue for a good Linux tablet, and I think that it would be best to basically make it exactly like a Librem 5 feature wise (cell modem optional), but with a bigger screen, flatter body (the M.2 cards can be beside the mainboard instead of behind it), and a flatter, but much larger battery. And more memory if that is not too much to ask. But RISC-V would be a step in the right direction. I am just not sure if the power efficiency is there yet, which is why I lean towards making another i.MX 8 device and wait for the next generation of RISC-V for version 2 products. But if the power efficiency of a VisionFive is already better than the i.MX 8, then by all means, lets innovate.
Thank you for your time.
I agree! It does not have to be better than the Librem 5, just a bigger screen, that’s it. The Librem 5 is already good enough for a tablet.
A few comments on the closed-firmware discussion:
Here I think we need to protect the simplicity of things, and recognize that freedom and simplicity go together. Making software more complex will benefit large actors, and will in the end make it impossible for an individual to control your own technology. There is a trend that software becomes more complex, yes, but that is in many ways a bad trend. To protect freedom, we need to preserve simplicity. Remember that in 2023 one of the main tasks we use computers for is still to edit a text file (although I’m sure Microsoft et al would love to change that so that we edit their complex proprietary format instead).
If a piece of hardware has closed-source firmware that it depends on to run, then I think we have to accept the unpleasant fact that we cannot be sure that the device will keep working. It may stop working one day due to something the firmware is doing, and we will not know why, and we will not be able to debug it because it is closed. At that point the piece of hardware becomes garbage. (Unless we go to the vendor who then has power over us, assuming that the vendor still exists.)
While it sometimes seems like there is a tradeoff between performance and freedom, that view misses the more critical aspect of being able to control technology. If I have a device in my hand, then either I can control it (I have access to the needed source code for that) or not. Is it important for me to be in control, and to be able to solve problems as they appear? Then I need that source code, it’s not a matter of some theoretical principle but it is a quite practical matter: I want to be able to rely on the device to keep working, I want to be able to debug it when there are problems.
Finally, note that openness is good for performance in the long run. The lock-in that comes with closed firmware is hampering further development. Look at the success of the Linux kernel – it is the best, it has taken over the world because of the open development. If we had open development of the firmware for various devices that are currently closed, then we would in the long run get better technology, including better performance.
On the other hand, we can edit a text file using a character cell interface like vi or using a GUI interface like gedit and a GUI interface immediately implies thousands upon thousands of extra lines of code, and the memory to store the resulting machine instructions and its attendant data, and the CPU performance to run the machine instructions while still keeping the responsiveness approximately on par with the good old CC interface.
And to be fair to Microsoft, I spend a fair part of the day in Thunderbird writing emails in HTML, rather than plain text. And I don’t see very many people arguing that the entire web should be stripped back to plain text. (Not even the Gemini Project is really going that far.)
Simplicity is also a virtue from the perspective of security. Bugs often lurk in complex code.
I think almost everyone in this forum agrees with the general idea that “closed” is “bad” (for the reasons that you mention).
The question put (not in the OP but no surprise there) is … when forced to choose between “closed” and “not doing anything at all”, what do you choose?
We can see that Purism doesn’t have the resources to make open versions of every single component that goes into a computer. If they stick to “open only” then they won’t build a device. The argument therefore is about whether to compromise and if so where it is most reasonable to make those compromises and what exactly those compromises imply.
I’m curious as to what the last x86 CPU to support DDR2 / first x86 CPU to support DDR3 is. I had a quick look through my computers but couldn’t confirm anything old enough.
Looks like all the first generation Core i7 / i5 / i3 processors were DDR3. So it must be earlier than that i.e. maybe Core or Core 2.
Right, but even the often quoted Thinkpad X are not blob free. They only do not have blobs on the APU but the rest of the device is full of firmware blobs, but these are stored in locations the APU either does not have access to or the access is not documented / known - like I already described just look at the touchpad, touchpoint, the EC etc. All running proprietary closed source firmware.
Get me right, I do not mean to justify non-free firmware. I want this free and open too. But I fail to see why it shall be better to have the firmware hidden away from the user’s sight instead of pulling it out in the open?
The real advantage the older Intel machines have is that they do not have this rotten ME as part of the SOC, this is really the worst and it gets even worse with current Intel SOCs where in some the ME is even necessary to run to be able to do S3 (aka suspend to RAM). So in these you can not even use the HAP bit anymore to disable the ME at runtime or else you loose S3. Pretty bad.
Cheers
nicole
Getting even further off track but … in that scenario and assuming that it can’t be fixed … I hope Purism gives customers the choice i.e. halt the ME if they don’t need suspend-to-RAM or live with the running ME if they do need suspend-to-RAM. (I personally would opt for the former. I’m not a big user of suspend-to-RAM on desktops / laptops.)
How evil is Intel though for putting us in the position of having to make that choice !