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