Why does it require some proprietary components?

[realrichardsharpe@gmail.com]

I have received my phone and installed pmbootstrap. When I ran pmbootstrap init I got this:

Code:

[user@localhost ~]$ pmbootstrap init
[17:35:25] Location of the 'work' path. Multiple chroots (native, device arch, device rootfs) will be created in there.
[17:35:25] Work path [/home/rsharpe/.local/var/pmbootstrap]:
[17:35:34] pmbootstrap does everything in Alpine Linux chroots, so your host system does not get modified. In order to work with these chroots, pmbootstrap calls 'sudo' internally. To see the commands it runs, you can run 'pmbootstrap log' in a second terminal.
[17:35:34] Setting up the native chroot and cloning the package build recipes (pmaports)...
[17:35:34] Clone git repository: https://gitlab.com/postmarketOS/pmaports.git
Cloning into '/home/rsharpe/.local/var/pmbootstrap/cache_git/pmaports'...
[17:35:38] NOTE: pmaports path: /home/rsharpe/.local/lib/python3.7/site-packages/aports
[17:35:38] Choose your target device vendor (either an existing one, or a new one for porting).
[17:35:38] Available vendors (44): amazon, asus, bq, chuwi, fairphone, finepower, google, gp, hisense, htc, huawei, infocus, jolla, leeco, lenovo, lg, medion, meizu, motorola, nextbit, nobby, nokia, oneplus, oppo, ouya, pine64, planet, purism, qemu, raspberry, samsung, semc, sony, surftab, t2m, tablet, teclast, wiko, wileyfox, wingtech, xiaomi, yu, zte, zuk
[17:35:38] Vendor [samsung]: pine64
[17:35:51] Available codenames (4): a64lts, dontbeevil, pinephone, pinetab
[17:35:51] Device codename: pinephone
[17:36:04] This device has proprietary components, which trade some of your freedom with making more peripherals work.
[17:36:04] We would like to offer full functionality without hurting your freedom, but this is currently not possible for your device.
[17:36:04] device-pine64-pinephone-nonfree-firmware: Wifi and Bluetooth firmware
[17:36:04] Enable this package? (y/n) [y]:

Why does it reqire proprietary components? Do I need to upgrade to the development version of pmbootstrap?

[Danct12]

Yes, Bluetooth requires proprietary blobs. If you don't really need that feature, you can say "n".

Not all components in the device are completely FOSS.

[MartijnBraam]

The propriatary components is the firmware files for the RTL8723CS chip. You can skip it and wifi/bt won't work. The other images also have this firmware.

[buffer]

The propriatary components is the firmware files for the RTL8723CS chip. You can skip it and wifi/bt won't work. The other images also have this firmware.

  Is this just a postmarket os thing or by "the other images" you mean all operating systems we run on the phone will only operate wifi & bt with proprietary blobs?

I assume it will be possible to deblob in the future? I think deblob is needed to pass the FSF guidelines

[MartijnBraam]

No there's no open firmware for it, we're not trying to pass FSF RYF guidelines since those aren't very obtainable.

[VaZso]

Also WiFi cards in PCs contain BLOBs... so an own firmware which is built into the module or uploaded during boot time by their drivers under Windows or by their modules under Linux. Under Linux, they are usually available in binary form in files and under Windows they are built into their driver... but the concept is the same.

Also "MODEM"s have their own firmwares in some form...

[wibble]

This is one aspect of the FSF guidelines I just don't understand. If the proprietary blob is in a PROM that can't be upgraded they're fine with it because it's 'hardware'. If the same blob is loaded at runtime it's fuctionaly indistinguishable, but now it's a problem because it's 'software'. I'll take the 'software' version please - at least this way if there's a security issue found in the blob (see android phone issues where the vulnerability was in the wifi firmware) I can update it to a fixed version instead of having to bin the device.

[someGermanGuy]

https://www.eset.com/int/kr00k/

It would be nice if we could somehow replace all that proprietary, closed-source stuff with real "open hardware"/"open source" modules.

[buffer]

https://www.eset.com/int/kr00k/

It would be nice if we could somehow replace all that proprietary, closed-source stuff with real "open hardware"/"open source" modules.

I agree with the rationale above about being able to upgrade the proprietary firmware. That is preferable to throwing out an entire piece of hardware.

Especially for the PinePhone's affordable price.

Even better (someday?) would be an upgradeable free/libre firmware. I don't think even Librem got that. They just settled for an older (but still perfectly acceptable) wifi+bluetooth card with a "custom firmware" written for their phone: "For getting rid of the runtime firmware we invested significantly in a custom firmware that the manufacturer made specifically for our use case.". https://forums.puri.sm/t/librem-5-wifi-specs/5900

It doesn't sound like the source is available....

https://puri.sm/posts/librem5-2018-09-hardware-report/

"For WiFi and Bluetooth radios we are currently working closely with Redpine Signal. Redpine Signal will supply us with a low power WiFi/Bluetooth solution using SDIO as the data interface. We went with Redpine Signal as their chipset does not require a firmware download at runtime like other vendors; having a downloadable firmware would violate the Free Software Foundation’s RYF requirements."

I guess that means the custom firmware was proprietary, but hard-flashed into the chip. I can't find much more info about it.

Given the apparent lack of options, I can live with it.

[wibble]

https://www.eset.com/int/kr00k/

It would be nice if we could somehow replace all that proprietary, closed-source stuff with real "open hardware"/"open source" modules.

It would indeed be nice. Unfortunately most radio regulatory bodies are very much against the idea, and some were recently pushing for locking down wifi routers so there wouldn't be any more OpenWRT either. It's the same problem with the modems. No regulatory approval, no import - at least where customs take their enforcement role seriously. That's before we even get to the chipset manufacturers...