Potential for Linux-libre on the Pyra?

[Pyramancer]

If someone were willing to do the necessary work, what is the potential for running a Linux-libre kernel on the Pyra?

Are there components of the device that will definitely not function without blobs or other non-Free software? Is the answer to this question different for the mobile-capable versions of the device?

Just to be clear, this question is hoping for a broad technical answer, not a political/philosophical one!

Thanks.

 

[slaeshjag]

Wifi/BT requires a blob, could be worked around with a USB dongle.
The mobile version has a module with on-board firmware. It is stored in flash inside the module and is generally not touched by the kernel.
The hardware accelerated video encoding/decoding requires a firmware blob to be loaded into its subsystem. Work-around would be to fall back to software decoding. Some 1080p bitstreams will decode in real time on CPU alone.
The SGX (3D accelerator) will at a very minimum require userland blobs to function, if you can do without accelerated 3D, you don't need them.
The GC320 2D accelerator requires userland blobs (at least, I haven't found the source to them...) Not sure if it requires a firmware blob, but I don't think so. Not functional in PyraOS yet afaik.
There maybe some scattered blobs in microcontrollers around the board, but I don't think those count?

That's what I'm aware of anyway. So the answer is: It's the usual traps.

 

[levi]

FWIW, I thought the kernel itself was always 'libre' at least in vaguely sensible linuxes line Debian - all kernel blobs would be in sepearate .ko files that can be rmmoded easily at runtime (although you might be reccommeded to drop down to text mode for some of them I guess).

But slaeshjag's list is probably the best list of which bits might need non-OS blobs to work I've seen yet.

 

[diligentcircle]

Debian is the only mainstream distro that deblobs the kernel. But yes, it does. All the blobs are in separate packages found in the non-free section.

 

[Pyramancer]

I made a little progress in answering the question in my OP. On the Free Software Foundation's page on single-board computers [1] it mentions the TI OMAP SoCs indirectly in the following paragraphs under "Single Board Computers with Serious Flaws" [2]:

The BeagleBoard (various versions) as well as the PandaBoard use the TI OMAP family of SoCs. These come with free startup software as well as free drivers for the peripherals.

However, the graphics accelerator (GPU) and the video decoding hardware for formats such as MPEG-2 are nonfunctional, because they require nonfree blobs to be installed into them. The workaround for these flaws is to do these jobs on the CPU with free software.

The Pandaboard has another serious flaw: a WiFi and Bluetooth chip that can't work without nonfree software. The workaround is to get an external USB device for these functions, if you want them. See the documentation of your board for information about using these USB devices with it.​

This page hasn't been updated since June 2015 though. Maybe the situation has improved.

The Pyra wiki [3] and [4] lists the Pyra's WiFi/Bluetooth chip as the Texas Instruments WL1837MOD. I looked on the h-node hardware list [5] hoping to find this chip listed as compatible with a fully Free system, but it isn't listed there.

I can probably live without hardware video decoding (I live most of my life in plain text). But not having on-board WiFi and Bluetooth on a mobile device would make be rather sad. I'm not sure whether I will use an external WiFi/Bluetooth device, or surrender my principles, for the time being, as too impractical.

[1] https://www.fsf.org/resources/hw/single-board-computers

[2] Note: To be clear, we're talking about serious flaws from the point of view of being purely Free. Those with looser morals or lower standards or possibly just those who are more pragmatic might not see these flaws as serious.

[3] https://www.pyra-handheld.com/wiki/index.php?title=WiFi

[4] https://www.pyra-handheld.com/wiki/index.php?title=Bluetooth

[5] https://h-node.org/

 

[Silent-Hunter]

I would consider myself pragmatic. While I would greatly prefer free drivers, I'm not going to give up those things, or the Pyra entirely, as that will just harm the wrong people.

 

[Pyramancer]

Well, there's no way I'm giving up on the Pyra: It's the only hand-held device that runs GNU/Linux (and, it may be, GNU/GNU Linux-libre) and which also has a serious keyboard.

 

[SneHebNor]

We have to distinguish two cases:

1. If you need non-free firmware blobs, it is not free, but there are few practical problems (well, depends). I can live with this and still sleep well.
   
2. If there are non-free kernel drivers, it is not only not free, but you cannot upgrade the kernel anymore! This would be not acceptable for me at all.

Also, we should distinguish:

1. Without certain blobs, the system does not work at all (like older Raspberry Pi, IIRC). This would be very, very bad.
   
2. Without certain blobs, some functions do not work, e.g. display acceleration or bluetooth. This is OK, but depends on ones needs.

 

[Pyramancer]

Without certain blobs, the system does not work at all (like older Raspberry Pi, IIRC). This would be very, very bad.

I feel that "very, very bad" is a bit too negative. Being totally Free (Linux-libre-Free, requiring no non-Free blobs) was not, as far as I know, ever a design goal for the Pyra, after all. By existing at all, the Pyra brings Free software to more people; that is A Good Thing. Requiring it to be totally Free is not really a practical requirement in the current state of the world... it is better, I feel, to raise awareness of the problem, so that future computers can be. It will be great if it turns out to be Free enough that it can run Linux-libre and be still be reasonably functional. (But a true totally Free device will need to have Free firmware/BIOS, and, sadly, I think a fairly large shift in perspective will be needed before such a machine can be built in a Pyra-like format.)

 

[AnimatedFreak]

Who owns these binary-blobs? Maybe it would be possible for the license to change them to a GPL-compatible license.
If an image of the Pyra version of Debian (or a port of the approved GNU/Linux distros from gnu.org) can be made with the Linux-Libre kernal I think it would be great just on principle as we would be providing an option that directly doesn't use proprietary software. An option that says "We will provide this even thou it's not perfect" and maybe it would bring some of the hardcore free-software advocite user who really like the design of the system and are willing to sacrifice the GPU and use USB wifi devices. I don't know if I would be willing to do that, but I would try it out for sure

 

[sebt3]

as far as I know, ever a design goal for the Pyra

You know so few There's just no source-able (in pyra's volume) options

Who owns these binary-blobs? Maybe it would be possible for the license to change them to a GPL-compatible license.

the keyword here is "maybe" as-in : there's not a single chance.

 

[Pyramancer]

Who owns these binary-blobs?

The blobs without which certain parts of the hardware don't work (or have a reduced feature set) are owned by the respective manufacturers of the hardware.

Maybe it would be possible for the license to change them to a GPL-compatible license.

Well it certainly can't hurt to ask manufacturers to Free their software. One problem is that it seems that manufacturers don't want the software to be Free because they use it to serve their business interests; for example they use it to restrict the features exposed in the hardware.

 

[Letalis Sonus]

One problem is that it seems that manufacturers don't want the software to be Free because they use it to serve their business interests

Don't forget the lawyer costs for the legal review. Releasing documents and software that have already been written into the public is a very expensive process if you have to look out for legal issues, especially if 3rd party IPs are involved.

AMD demonstrated that several times in the past, people easily forget how much money had to be invested just to release the hardware documentation.

 

[EvilDragon]

Most of the time, the reason for binary blobs is technical knowledge.

If the firmware of the SGX or Wifi chip would be open, this would also mean that competitors can use it to improve their own chips, without the need to fund the development themselves.

This would allow competitors to throw way cheaper Wifi chips onto the market, as they have a lot less development costs.


Sent from my XT1650-03 using Tapatalk

 

[Silent-Hunter]

Most of the time, the reason for binary blobs is technical knowledge.

If the firmware of the SGX or Wifi chip would be open, this would also mean that competitors can use it to improve their own chips, without the need to fund the development themselves.

This would allow competitors to throw way cheaper Wifi chips onto the market, as they have a lot less development costs.


Sent from my XT1650-03 using Tapatalk

That makes a lot of sense, but aren't there laws in place already to prevent that?

 

[levi]

Yes, it's called copyright, which is in opposition to the copyleft of the GPL and so on.

 

[Grench]

This would allow competitors to throw way cheaper Wifi chips onto the market, as they have a lot less development costs.

That makes a lot of sense, but aren't there laws in place already to prevent that?

Yes, it's called copyright, which is in opposition to the copyleft of the GPL and so on.

Those same legal bits that are often entirely ignored by the same competitors / companies who would make the competing parts. Using the laws to go after them would require months and years of international legal actions that would likely not be enforced by the authorities in the infringing company country.

Without solid international copyright enforcement cooperation, it becomes in their best interest to hold the hardware driver details as 'secrets'. Ironically, poor international copyright and patent enforcement leads to lower chances for publication of the information needed for open source development.

 

[Silent-Hunter]

I mean to prevent another company from stealing hardware designs. That way we can have open source drivers and the company won't be afraid to make them open source.

 

[levi]

Well, that's the situation a lot of manufacturers are in. And the best solution for linux diehards they've come up with thus far is to have an open source driver which plugs into the kernel and in turns calls a binary blob which has no public source but is freely distributable and available on most linuxes if you install the right package.

If there's a bug in that binary blob, it's a lot harder to fix if you don't have the source, so it's a compromise, but the best we've found so far if companies believe the source to the blob would release too much info on how the hardware's made. I do personally believe the compromise could be better made and the many companies protect too much stuff by putting in on the blob side of the divide, but until there's a monetary reason for them to seek out this better compromise they're unlikely to change. And nobody seems to be pushing for this; most people are perfectly happy with overzealous blobs provided they work today, and libre die-hards want a totally open system.

 

[SneHebNor]

I feel that "very, very bad" is a bit too negative. ... Requiring it to be totally Free is not really a practical requirement in the current state of the world.

I did not write "totally free". The question is: Will the Pyra at least work without any blobs or not? E.g. if a blob is needed to use accelerated graphics, fine, one can still use the Pyra without acceleration. If a blob is needed for bluetooth, fine, one can live without bluetooth or use a USB bluetooth dongle. Etc.
[doublepost=1495143006,1495142774][/doublepost]After the security desaster when an HP audio driver worked (probably accidently, but anyway) as keylogger, one should really care about free drivers and be careful with any blobs. Otherwise one cannot use the computer for any confidential communication, which makes it somewhat dispensable.