Purism Continues To Explore i.MX6/i.MX8 For The Librem 5 Phone

[shmerl]

That's precisely why i.MX 6 (and hopes of i.MX 8) : i.MX 6 uses a Vivante GPU, which is supported by Etnaviv mesa driver (and hopes are that the Vivante variant in i.MX8 will eventually get support too).
Thus, the base chipset of the phone should work with vanilla upstream kernels.

That's great! I hope it will be 64-bit (so i.MX 8). i.MX 6 is really old now.

[Nth_man]

Librem 5 has crossed *$1,250,000* In funding

https://puri.sm/shop/librem-5/

[marty1885]

BTW, I just send a mail to the Librem 5 team asking about wheather 5G WiFi will be avliable on their phone.
No. They saidd.

2.4 GHz is good enought for me thought. I have been using bgn only phones for years.

[sverris]

They should have focused to port GNU/Linux on Fairphone. That would have been amazing. You can't be perfect everywhere, so focus on something.

Most likely that would be very difficult, because of the Qualcomm-SoC the Fairphone is using. Though Purism could have tried to build a new /compatible core-module for the FP2, no Qualcomm then, but i.MX8.

[microcode]

The novena laptop runs GNU/Linux on a quad i.MX6, no problems there. Debian.
The Openpandora and GTA04 runs GNU/Linux on OMAP3, not sluggish. Came out in 2008, OS updated this month.
The Jolla 1 runs GNU/Linux on a 5+ year old Qualcomm chip, problem? No, use it every day.
The Dragonbox Pyra will soon be out with OMAP5, for a handheld it solves all the problem you could want to have solved.

With limited resources, you go wrong with optimization, not anywhere else.
Unless the OS is sluggish, the experience is not going to be.

Yeah, as long as the mental model of the hardware capabilities doesn't deviate from the given hardware model, it will naturally work out well on that hardware. Desktop Chrome gets slower when phones get faster. ;- )

[DrYak]

Are there open drivers for this SoC? I.e. besides the GPU, what about the LTE modem and so on?

To expand on what others have already answered : the whole purpose of this project is to avoid blobs.

That's precisely why i.MX 6 (and hopes of i.MX 8) : i.MX 6 uses a Vivante GPU, which is supported by Etnaviv mesa driver (and hopes are that the Vivante variant in i.MX8 will eventually get support too).
Thus, the base chipset of the phone should work with vanilla upstream kernels.

Regarding the other functionnality :

LTE modem - due to licensed radio frequencies, only companies holding licenses can develop devices using them - means that only chip manufacturers and carriers get to decide what these chips run.
Purism's approach is the same as openmoko, as pyra : they picked i.MX because it does NOT have an integrated modem (unlike Qualcomm where the modem sometime works as northbridge).
Instead, the modem is completely separate chip, that only talks with the chipset over a standard connection (over ethernet or USB, presenting it self as either a network or a COM port speaking "+++AT" commands).
That way your linux system is outside the reach of the unknown blob - you basically consider it the same way as a network switch to which your smartphone is plugged with an ethernet/USB cable.
Purism will have physical switch to turn of the chip (Pyra has a similar approach, but uses relays for that).

GPS - has similar restriction in some jurisdiction. It's not supposed to be highly precise at both high speed and high altitude - to avoid of civilian application chip being repurposed as missile guidance system (at least that's the official excuse).
Again, it's possible to confine it into a separate chip that talks a standard protocol (seen as a serial port).

Wifi and Bluetooth - these use unlicensed frequencies. Basically anyone can use them as long as they respect some limitations. Thus anybody can write the code that access them, so probably purism will try to use opensource driver whenever possible.
(they are some subtleties - like the exact frequency range not being perfectly identical between countries. Thus wifi hardware is able to emit frequencies to work in country A, which happen to be restricted in country B. Depending on implementation, firmware or driver code might be restricted due to that. But you can also find non-problematic implementations : the instruction running on the PHY will only emit on channels which they are detecting incomming traffic. Thus if country-A-specific frequency is never detected (because we could actually be in country B) the PHY will refuse do emit it. - so basically again a situation where the restricted thing happen in some firmware running inside a separate chip, and chipset only deal with opensource drivers).

So overall, for everything concerning the Linux running on the main chipset, it could be 100% free, while all the non-free bit are moved away into firmware running inside separate chips - which are treated as blackboxes, the same way as a network switch.

[DMJC]

Finally, they've broken through the Million Dollar mark!

[shmerl]

Baseband has proprietary firmware driver, but FOSS kernel driver.

This is great, thanks! Finally a promising device in the making.

[Flaburgan]

They should have focused to port GNU/Linux on Fairphone. That would have been amazing. You can't be perfect everywhere, so focus on something.

[starshipeleven]

Baseband has proprietary firmware driver, but FOSS kernel driver.

And hardware switch to turn it off manually, and it is also connected over USB or something like that so it does not have DMA. (and it's a secondary chip, of course, so it has no say in the boot process)