RISC-V is not entirely “open”. The Risc-V ISA is an open standard, but the organisation that controls it acts more like a closed shop from the look of it. Judging from the references below, the RISC-V Foundation ignores external contributions and makes it difficult to access technical documentation.
The ISA (instruction set architecture) only defines the CPU instructions and not how it is implemented in silicon. So you can still be forced to use binary blobs to use a chip that implements the open RISC-V ISA.
It seems that the RISC-V ISA is only gaining traction with the major players because it lowers the cost of IC development and not for protecting user freedoms.
On top of all this, power CPUs are a proven technology with decades of experience behind it. Longevity is a serious concern for any platform and I’d feel much more confident developing towards or for power architecture than RISC, at least in the current landscape.
There is already a group working on a libre-hardware design for a powerPC based laptop with the goal of meeting the FSF Respects Your Freedom criteria. Looks very promising and actively being developed.
@nicole.faerber Could Purism reach out and join forces with them?
The power laptop project is interesting and i hope they will succeed, but for some reason they are going for big endian while almost all distro like debian and fedora do support little endian only.
So i hope purism will join the effort with raptorcs if this help both, since they both care about open softwate open hardware and open firmware
That is troubling… While it is possible to run qemu cross endian, the performance penalty is considerably higher, and there are more bugs… That pretty well precludes running x86 stuff on their laptop.
Or did you mean Debian on the PowerPC architecture supports little endian only? while supporting big endian on other architectures e.g. MIPS?
A lot of code should be completely oblivious to the endianness. If you are writing general application code that depends on the endianness then you may be doing it wrong.
Any code that depends on the endianness should generally be using conditional compilation or other compile-time features to work with either endianness (statically).
(Of course @lperkins2 makes a valid point where for whatever reason the source code is not used and emulation is used instead.)
Anyway, at least RISC-V is unambiguously the little endian that we know and love.
In theory that is far more true than it is in practice. No one is born a master programmer, and the demand for code far exceeds what master programmers can produce. So most code is written by less-than-perfectly-competent programmers. There’s lots of ‘it works on the systems I have available for testing’, and lots of novice programmers aren’t even aware of what host-byte-order means. I admit I have production code in the wild which assumes it’s running on a little-endian machine, just because it’s faster to write with that assumption, and I don’t have a good way to test on non LE machines anyway (it’s also not a public program).
Fortunately, lots of those programmers write in Python, Javascript, or other languages which abstract away those messy details, so people on EB machines don’t hit snags too often. But the fact is that little-endian is the de-facto standard, so porting programs to big-endian systems is likely to find all sorts of bugs (especially once JITs get involved).
A note of clarification, there is no “the PowerPC architecture”, there is the PowerPC big-endian architecture, and the PowerPC little-endian architecture. While the two are quite similar, they are distinct, and must be supported separately. Similarly, there is MIPS big-endian and MIPS little-endian. Debian does support other big-endian architectures.
As for debian PPC64BE, it looks to still be supported, sorta. There are 2 entries for PowerPC on their package list, one looks to be the legacy big-endian version, the other is the little-endian version. Thing is that IBM has mostly dropped support for big-endian software, and is planning to continue moving everything to little-endian, so maintaining the big-endian PPC distros will get harder as time goes by.
Debian do have an official support for ppc64le while there is no official support for big endian, that’s why i think it’s important for hw manufacturer to go with little endian, same for fedora
It is not feasible a laptop with Power9, but there are rumors that RaptorCS is preparing a laptop with Power10.
Anyway Power10 launch is postponed to 2021 according to many sources.
There are other rumors that Vikings will sell RaptorCS Talos II and Blackbird in Europe soon, then I hope that Purism could get IBM Power10 CPUs too for their laptops, although Purism servers haven’t got Power9 CPUs, I cannot understand if there is an exclusivity agreement between IBM and RaptorCS according to their FAQ #5.
The problem with RISC-V is that the ISA is just a small step. Actually used are implementations of said ISA. And the RISC-V foundation proclaims at every opportunity that they are no tree-huggers — aka free software evangelists. Which means they are fine with proprietary RISC-V implementations.
I’m fine with WD to do whatever they want in their SSD and HDD controllers. I view those components as black boxes and only expect them to have free device drivers. As a customer I’m not affected by the choice of the manufacturer if they use RISC-V or not.
And regarding RISC-V general purpose computers I have yet to discover a product that doesn’t require proprietary software to run. That’s a problem for me. I already have that with x86 and arm. The only platform that can be used with free software exclusively is POWER9.
I agree. Therefore just to let you consider that 2 days to donate 2504,01 € left:
EDIT: I find this as just fine and useful comment: “RISC-V aims at the complete other side of the spectrum when it comes to horsepower: Yes, you can validate the HDL, but you can also integrate it alongside custom peripherals and build something that fits in a 24QFP and needs 3.3v at 100mA to do a very specific task.” Link to the rest of the original post is here: https://hackaday.com/2020/08/19/ibm-reveals-power10-cpu-based-on-the-openpower-isa-3-1-specification/.
