We really need a term to describe the openness of devices like to Pyra or almost any x86 box with an nvidia video card. At least the primary computation path is all using open source code, it's just the final picture you draw depends on a binary blob (although if your writing to a framebuffer provided from that blob I reckon that would be relatively easy to test out)
I'm not sure RISC-V is strictly relevant to this discussion. The ARM ISA is fully documented, even if the internal layout isn't, so it's all deterministically specified (apart possible from some TrustCore weirdness I don't fully understand yet). Of couse, RISC-V giving us an open source layout which is neat to have, but it doesn't give us particularly more power to run open source code, which I care about more personally.
¿A term to describe openness (open, openness level)? The same than a term to describe heat levels
1st there is true real openness, like real white and after that there is grey, more gray, a lot of darker grays... and black
On other side I think you begin with a bad comparison: you get Pyra with ARM SOC, where near all ARM SOC with GPU haven't open drivers, and with x86 box you get one with a discrete graphics card, while Intel x86 can have integrate graphics with open drivers, something near most ARM can't have.
«At least the primary computation path is all using open source code»: sorry but binary blob is at kernel level, so you have soft in a very inner circle that you don't know what it is doing or what it can do. The same if you include cell phone modem: this is even worse, as they can introduce code from cell network! For example Librem 5 phone will have a separate hard for baseband, so main CPU/SO will be separate from them (baseband will have it's CPU-SO).
«The ARM ISA is fully documented»: the same for Intel ISA. The problem is that those chips (Intel and most ARM) include much much more than that documented ISA: there is much more in a SOC than Cortex or x86 cores, and we don't have control over them: even worse, some of those parts can have total control over our cores. This is really nasty, but so is reality about most actual computers.
My complain is that some people think that ARM SOC is free/Linux while Intel isn't, while Intel has Linux too, Intel support Linux, even Intel GPUs are the few with open driver, while near most GPUs used in Intel aren't.
Some people think ARM is good while Intel is bad (speaking about open model), and that isn't real. Of course, I like ARM ISA more than Intel, as ARM is a much more clean modern ISA than x86 with all its heritage from old CPU, but that is another history.
Be warned: RISC-V is free, but in extreme: it has BSD Open Source license, so each manufactures can decide if he wants to open all, some parts, or close its chip/development. They have that freedom (to show/open or not, its work/product), and that is a requirement for industrial interest. The good part is that can be open hard, like for example Si-Five.
About a 100% RISC-V with less power: I would love to have one, even with less power. Because freedom and being real owner of my computer (I can control it) has no price: even I prefer half power and being real owner. But RISC-V isn't enough mature in this moment. We have seen 1st 64 bit RISC-V capable of running Linux, but still not in mass production and even without integrated graphics chip.
[doublepost=1520005275,1520004736][/doublepost]
on a slightly related note, last bios update for the GPD Pocket is from August last year and they do not seem to plan an update to fix Spectre ... so I personally would not trust them with that kind of money again
Do you know the date of last old OMAP5 binary driver/blob and if that 'update' solves ACTUAL Spectre bugs?
And the problem with Spectre is that there is no final solution (new forms to use Spectre will be discovered and new patch will be needed):
Meltdown and Spectre are not just hardware exploits, they are the processor and microprocessor exploits. Meltdown is an exploit against the CPU which has a patch in progress, while Spectre is an exploit against the design of microprocessors which has a “possibility to patch upon each exploit as it is identified” in a never ending game of cat-and-mouse.
Source:
https://puri.sm/posts/meltdown-spectre-and-the-future-of-secure-hardware/
PD: Remember that OMAP5 binary driver/blob is at kernel level, all time on. So if it doesn't solves Spectre, that bug is present at a very inner circle.
