Purism Librem 5 is a privacy-focused open source Linux smartphone powered by NXP i.MX 8M processor that was launched via a crowdfunding campaign in August 2017 that ends up being extremely popular with over 1.5 million dollars raised.
At the time, the phone was scheduled to ship on January 2019, but a $299 development kit with board, display and accessories was slated to ship in June 2018. There have been some delays, but the good news is that Librem 5 development kits are now shipping so third party software development for the phone will now really get started.
Librem 5 development kit preliminary specifications:
- System-on-Module – Emcraft SOM-IMX8M module with NXP i.MX 8M Quad core Cortex A53 processor, at least 2GB LPDDR4 RAM and 16GB eMMC flash (I could not find exact RAM and storage capacities for the module used in the board)
- Display – 5.7″ LCD touchscreen with a 18:9 (2:1) 720×1440 resolution
- Camera – 1x camera module
- Librem 5 devkit carrier board
- Storage – micro SD card slot
- Video Output – Mini HDMI connector for second screen
- Audio
- Integrated mini speaker and microphone
- 3.5mm audio jack with stereo output and microphone input
- Network Connectivity
- M.2 low power WiFi & Bluetooth card
- SIM7100E M.2 cellular baseband card for 3G and 4G networks + slot for SIM card
- Ethernet for debugging and data transfer
- Location – GNSS with GPS support
- USB – 1x USB-C connector for USB data (host and client) and power supply
- Sensors – Inertial 9-axis IMU sensor (accel, gyro, magnetometer), Ambient light sensor, Proximity sensor
- Misc – Vibration motor, slot for smartcard, radio and camera/mic hardware killswitches
- Power Supply – Via USB-C or optional 18650 Li-poly rechargeable battery with charging from mainboard
The company has setup a Matrix channel for backers of Librem 5 developer kit to help them communicate with Purism engineering team and work with the community at large. If you don’t own the board, but are still interested in getting involved, you can ask to be added to the group by sending an email to info@puri.sm. Work-in-progress documentation can also be found in the developer site.
The phones themselves are now expected to ship in about four months, in April 2019. Early-bird pre-order pricing at $599 will end on January 7th, and price will be increased to $699 afterwards.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
$700 for a phone with 4xCortex-A53? I knew freedom had a price. OTOH the devkit $300 price looks good to me (provided of course they kepts that price).
Yes, freedom can have a price — in terms of money but also time.
It will be years before this is a really usable product with decent software support and by then, the hardware will be almost antique.
This was never going to be a cost effective option. The highly integrated cell phone SOCs are all closed source. The Imx8 is the most open source processor I know of.
It is easy to make something very similar to this. Just stick a 4G USB modem stick into a Pine64 with a display.
> Just stick a 4G USB modem stick into a Pine64 with a display
… and you get the PinePhone dev kit: http://wiki.pine64.org/index.php/Project_Anakin
A transportable phone 🙂
that’s closer to tablet with gsm modem than phone 😉
That’s the PinePhone dev kit and all that’s needed to get started with software. If this whole thing works (with Linux/KDE on the PinePhone and UI/UX that does not suck) I bet we’ll see a PinePad also…
I bet the final PinePhone will look like a normal smartphone based on Pine64 CEO asking for community feedback: http://irc.pine64.uk/?date=2018-11-28%2013:13:23
If you want to hack on a real phone it is hard to beat a $70 Umidigi A3 combined with the source code from the OrangePI 4G IOT board. It is not all open source, but for $70 that is a tremendous hacking platform.
Quad core A53, 2GB LPDDR3 RAM, world-wide LTE, 5/2.4 wifi, ips touchscreen, sd card slot, 12MP camera, fingerprint. Umidigi provides Magisk and low level flash tool that can recover without a bootloader.
Jon, Do you have any more info on this combo?
I have the A1, the A3 is identical with some cost reductions (like removing USB-C). I loaded Magisk which gave me root access. The Magisk builds are available from the Umidigi wiki, the factory provides them.
I was unable to get the Linux version of the low level formatting tool to work and proceeded to completely wipe out my phone. I finally discovered that the Windows version of these tools work. There are a bunch of people on xda-developers that hack on Mediatek. These tools will not work inside a virtual box (that is a vbox issue, not the tool).
I own a IOT 4G (MT6737) and have downloaded and built the source for it. While playing with that code I noticed that the code also supported the MT6739. The MT6737 and MT6739 main difference is clockspeed and different GPUs. The rest of the chip is the same. I used the info from the 4G IOT source to mess with various internal things in my phone.
I completely wiped out the phone and rebuilt it multiple times. You can take apart the update files from Umidi and replace various bits. Note that with Android 8 you can’t mess with the system partition due to Project Treble. That’s not a Mediatek restriction.
I did not bother rebuilding the kernel. The kernel that comes with the MT6739 was working fine.
The only bug I noticed, and this bug ruined my application, is that USB Audio support in Google AOA mode is broken inside the Mediatek kernel driver. Android Auto audio and USB speakers work, the bug specifically breaks AOA mode. AOA mode allows an external speaker to work with the phone when it is docked. I poked around in the audio driver but didn’t get around to fixing the bug. Plus I have no mechanism to get the fix back to Mediatek.
This is definitely not something for a beginner. You should already be familiar with how ARM based Android phones work before messing with this. If not you will likely get it into a state you can’t recover from. The tools are available that will recover from anything (even a blank flash chip) but you need to know what to do with them.
> The kernel that comes with the MT6739 was working fine
How outdated is this kernel?
I found in an Umidigi A3 review the following information:
* Kernel version: 4.4.95
* Android Security Patch Level: October 5, 2018
Same kernel version as in the Orange Pi SDK and ‘just’ 73 versions or 14 months behind according to https://www.kernel.org (at 4.4.168 today).
Why are exploitable/unfixed kernels not an issue with Android?
I don’t get it. Here in 2018 a ROM for these MediaTek SoCs is advertised as MT6737 Kernel 3.18.19 with latest security patch.
What security patch? 3.18.19 is 41 months old (almost 3.5 years) and I thought all the subsequent kernel patches from 3.18.19 until 3.18.130 can also be considered security patches. I always thought the purpose of running an LTS kernel is to update it to latest minor version to get critical bugs fixed? Why isn’t this the case with Android?
I don’t think MT are shipping anything but 3.18 for their SoCs currently. Everything MediaTek I’ve seen over the past couple of years has been with 3.18.
This explains the problem with the kernel and Android.
https://lwn.net/Articles/771974/
Quoting the article: ‘kernel upgrades remain a huge issue for Android vendors, who worry about shipping large numbers of changes to deployed devices. So devices generally don’t get upgraded kernels after they ship’
And that pretty much sums up the situation with Android, right? Nobody giving a sh*t about fixing kernel bugs (security vulnerabilities included) and consumers being happy with this.
If you can solve the kernel update problem I’m sure Google will hire you and pay you big bucks. They’ve been trying to fix this for years. It is getting better but it still not solved. The basic problem – Linus releases, SOC vendor modifies, Phone manufacturer modifies, Carrier modifies — how do you get through that pipeline in less than 12 months?
Fuchsia is taking a different approach. In that model the SOC vendor, Phone manufacturer, carrier all give their code to Google as modules. Then Google integrates the kernel package and pushes it. But that model assume a stable driver ABI which the Linux kernel purposely does not have.
Another model would be to make all of the device drivers in Android Linux run in user space. Now they could be updated independently of the kernel.
Another model is for everyone – soc vendor, phone manufacturer, carrier to upstream their changes. Doing that will definitely overload the existing maintainers. Probably 10% of vendor Android code is currently upstreamed.
It is not a simple problem to solve.
> It is not a simple problem to solve.
You’re talking all the time about something entirely different. I understand that Android needs to use outdated (LTS) kernels by design until now. So Phone vendors choose hopefully an LTS kernel (some don’t even this), start to work on this branch and all they later have to do is to integrate the upstream LTS kernel patches (increasing the minor version number) into the updates they roll out. The problem: they don’t do this since this is something that costs money.
I’m talking about a phone being at 3.18.19 while it should be at 3.18.130 (missing 41 months of fixes) or a phone being at 4.4.95 instead of 4.4.168 (missing just 14 months of fixes). I mean what are LTS kernels for? Backporting important fixes from latest and greatest kernel so users/vendors who are stuck to an old kernel release can also benefit from. To me it seems it’s just Android vendors don’t using LTS kernels as they should since this would generate costs and Android users don’t care about security anyway.
So there’s zero incentive for increasing security situation with Android other than Google wanting to get Android out of the headlines?
With Android 8 and later Google requires them to use specific LTS kernels (4.4.107, 4.9.84, or 4.14.42 or a later stable release), no more free for all on which kernel to start off from. And Google is providing timely integration of their kernel changes to these LTS kernels. But then it still needs to flow from there to the SOC vendors, from the SOC vendor to the phone makers, phone maker to the carrier. That flow takes time and most vendors don’t have a team sitting free waiting for updates to arrive.
The best way to make the existing system faster is for Google to get all of their Android kernel support into mainline. Because the SOC vendors build on top of the Google support, they can’t get everything into mainline until Google does. That’s why this has to happen: https://lwn.net/Articles/771974/
If Google got everything into mainline then the SOC vendors could be pushed to follow.
Those other schemes are based on decoupling the stages.
BTW – git merge from 4.4.107 to 4.4.1… does not always work when their are invasive changes (Google’s) in the way. It would be a disaster to send out a kernel update that breaks OTA update. Comcast just did that and now they are physically mailing out a 100K+ modems for their customers to swap out.
I am getting regular OTA serurity updates for my A1. This phone is in far better update shape than most other devices.
I don’t believe the A3 patches have started flowing yet. The A3 was only released about 60 days ago.
> This phone is in far better update shape than most other devices.
Android devices maybe… and it still runs with either a 3.18.19 kernel missing 41 months of fixes or an 4.4.95 being unpatched for 14 months. Why isn’t that an issue? I mean, that’s the kernel and not just some app, right?
Or 4G USB Modem + RPi 3A+/3B+. There’s a wide variety of other peripherals, such as LCD screens, to choose from.
> Or 4G USB Modem + RPi 3A+/3B+
Nope. You did obviously not get that’s here about freedom and a product that should be a smartphone and not a brick you can make calls with (the SoC/PMIC combo on the RPi is not made for battery operation).
Every RPi is a closed source design since the primary OS that has to boot first is the ThreadX RTOS fully controlling the hardware. Customers don’t get sources, it’s impossible to boot or operate any RPi without those ThreadX BLOBs. An RPi based ‘brick to make calls with’ is quite the opposite of an i.MX8 based Purism Libre or an Allwinner based phone which are all about free software.
Lol but linux and solar powerbank… /Sarcasm /fanboy /mimimimi
List of five open phone OS here
https://opensourceforu.com/2018/05/5-open-source-mobile-operating-sytems-alternatives-to-android/