With the powerful off-the-shelf hardware available to us common hardware hobbyist folk, how hard can it be to make a smartphone from scratch? Hence [V Electronics]’s Spirit smartphone project, with the video from a few months ago introducing the project.
As noted on the hardware overview page, everything about the project uses off the shelf parts and modules, except for the Raspberry Pi Compute Module 5 (CM5) carrier board. The LCD is a 5.5″, 1280×720 capacitive one currently, but this can be replaced with a compatible one later on, same as the camera and the CM5 board, with the latter swappable with any other CM5 or drop-in compatible solution.
The star of the show and the thing that puts the ‘phone’ in ‘smartphone’ is the Quectel EG25-GL LTE (4G) and GPS module which is also used in the still-not-very-open PinePhone. Although the design of the carrier board and the 3D printable enclosure are still somewhat in flux, the recent meeting notes show constant progress, raising the possibility that with perhaps some community effort this truly open hardware smartphone will become a reality.
Thanks to [tiel] for the tip.
The “star of the show” is ironically a closed-source application running on a closed-source operating system (likely VxWorks). so much for openness.
So we should just give up and go home?
Making an LTE module is difficult for legal reasons. That doesn’t mean a phone where everything else is open isn’t better. Having a functional phone that just needs an LTE module might also inspire someone to tackle that issue somehow. I agree with sibling comments that an RPi is probably not a good basis for this project for a whole host of reasons, but the lack of open LTE modules don’t invalidate the project.
I just meant the title is fully wrong.
So is Linux not opensource because we dont know the polymer chemistry of Linus Torvaldes keyboard caps?
We know. Its ABS.
The Pi isn’t open source.
Yes, it runs an open source OS (linux) but that’s the only thing open about it. I can do the same with any PC.
The board design isn’t open source. The chip is a custom proprietary one that cannot be bought. The boot firmware on the VPU has high privilege and is closed source like a little Management Engine. The camera module has DRM to try and lock out 3rd party camera modules. And on the list goes.
Then any project containing ICs that don’t have full chip-level schematics also wouldn’t be fully open. So that would be most of them.
^ this, to be honest I don’t care too much about details like that because the main point is that I can run the OS I choose and then the software I choose rather than whatever Apple or Google deem acceptable.
People in the open source community need to get over their righteous indignation and be willing to compromise their pure-as-driven-snow morals once in a while to actually make some practical progress rather than berate everyone who tries and bite every hand that tries to feed them.
The Quectel EG-25G is running Linux under the hood. The Pinephone project has been improving it themselves, and you can find firmware updates for your module. Unfortunately, due to many countries radio licensing regimes, I believe that Pinephone can’t actually ship “unapproved” firmware. Doesn’t stop end users from installing it, though.
e.g. https://github.com/the-modem-distro/pinephone_modem_sdk
My wishlist for products that don’t exist yet.
A Linux is based phone that isn’t super expensive and isn’t awful or twice the price of a high end phone with a fifth the capabilities. Most the reviews I’ve read of these have not been good. Imagine being able to write your own app to your phone without needing 32gb of ram or emulation. Be able to fully control your networking and telemetry. Upgrade whatever you want or dont. The dream.
A small keyboard that doesn’t require bluetooth for a cyber deck. This would jumpstart a lot of diy projects.
Just use a cheap android phone that has a popular cyanogenmod image
Fully open? How wrong! The Quectel “star of the show” is fully closed.
Are you still living in 2015? There was no cyanogen release for a decade…
lmgfy :)
“what is cyanogenmod called today” -> LineageOS. it’s not hard.
Spoken like a true…..
Can I use my linux development tools natively on android? No.
Can I directly access hardware plugged into the usb-c port on android? Also mostly no. Even with termux (go ahead try use serial comms in termux I dare you)
Can I write a program in any language and simply create a .desktop file? Noope
There are so many reasons why that is an absurd take. It would be like me suggesting someone “just use Windows” when they ask a question about their Mac or Linux machine.
For those that care, like me, there are two mobile linux projects that are good enough for daily driving:
1. A Sailfish OS supported device with Sailfish
2. The Furilabs FLX1s
Both are halium/hybris. I have been daily driving the Furilabs FLX1 (predecessor of the flx1s) for more than a year now. It is frankly awesome.
Wow furilabs is about right for me. Hardware kill switches are a beautiful thing. Thanks for sharing this!
I didn’t mean to say Android will satisfy the sense of freedom you desire. I don’t consider that realistic in the present market. If you actually want a phone, you don’t want any of the more open options. That’s just where we’re at. Android is definitely your best option in this space, by leaps and bounds.
I’m glad you’re having a positive experience with FLX1. Have you written any apps for this FLX1 FuriOS?
I’ve been down that road before, and i’m jaded about it. Android is way better for me as a developer than when i used to fall for crap like Maemo, OpenMoko, etc. Which really bums me out because Android is a bunch of stacked insults lately. So i hope you want to tell me i’m wrong about FuriOS!
FWIW if you actually like developing for Furi OS, it sounds like Halium should let you run that same stack on a lot of different Android phones, though it might be a bit of an undiscovered country.
Well, Halium has nothing to do with userspace, it is just an Android container running proprietary out of kernel drivers. It doesn’t even have a Java runtime. So (unfortunately) all it does is helping the porting process to new phones.
Yes I am a developer for both work and hobby. Work is financial automation/reconciliation programs, hobby I am deep into the RF world with major features in Radiolib, RfCat, (rtl_433 doesn’t want to accept my car keyfob decoding, understandably so thats the only other major one I haven’t significantly contributed to)
I find it important to specify as devs all have different skillsets.
If you want to develop for it its as simple as creating a flatpak or compiling an arm64 deb.
As far as apps yes I have written a few for it.
– As a radiobuff I have every radio tool imaginable including a flipper zero. Since two way bt doesn’t work in the android container I couldn’t use the flipper app to send/receive files (one way bt works fine eg audio sink) So I wrote my own to run natively. Works great and dev was no different than writing it for a desktop computer. Simply high level bluetooth, protobuf messages, etc.
The 4.19 kernel Furi use is old and has a bug so there was an issue with my rtl_sdr. I forked the librtlsdr driver, made the changes, packaged it into a deb and installed it. Works great no different than doing it on a desktop. (Yes its an old kernel, yes they are working on a newer one, but they are also applying security patches to it as can be seen in the changelogs)
Similarly my rtl_433 fork with car keyfob decoding compiled and installed and works fine.
My tinygo fork also compiled and installed fine. I have even flashed my mcu/transceiver directly from the flx.
I have a few other Golang tools and of course python scripts all of which work fine. Creating a .desktop in the normal way puts it on the desktop.
The halium/hybris piece only really matters if you are well and truly deep in the bowls of the phone OS. Otherwise interfacing with the userspace stuff is seemless just like on a desktop.
And sure you could in theory bring it to other phones, but that is harder than you would expect given the very different hardware configs of phones, quirks and limitations. I readily admit that is both outside my wheelhouse and outside my interest.
Purists won’t like the halium/hybris, but the benefit is the hardware all “just works”, Volte works, cell broadcasts work, and so on. The android container works extremely well too with copy/paste passthrough, notifications on the host, file sharing is done through a folder you enable, etc.
(For others be aware the flx won’t work on Verizon since they whitelist phones. That is an arbitrary restriction they impose. T-mobile doesn’t do that).
@kosiner – Halium affects userspace. Jeesh. Your comment is exhibit 0 for why i don’t enjoy non-developers talking about open source. Halium provides a set of interfaces to the underlying Android hardware management. If you write userspace software, you have to use those interfaces or undergo the cost of making adaptors to them. That’s why Android, which standardizes those interfaces, is better than Maemo which abandoned one awful interface for another even in its short lifetime.
@Sword – thanks for your answer! It sounds like you are building console-mode programs for the FLX1 and reporting that they work fine with only a few headaches. I don’t want console in my pocket…i don’t want to run the same software in my pocket that i run on my laptop…frankly, that’s what my laptop is for! So i think that shows pretty clearly why you’re able to tolerate FuriOS and i roll my eyes at it.
I want features like touch interaction, unified notifications interface, and all of the other mobile-specific features of Android. That’s why i like that Android has kept these relatively stable for 16 years, and can’t stand that The Maemo-Gnome continuum of ‘open source’ Linux interfaces only ever makes bad choices. Kind of disappointing, with how bad Android is, that it is so much better than the open source offerings…but it makes sense because it necessarily takes an authoritarian approach to standardize something like that.
Let’s not forget Ubuntu Touch, whose community is maintaining Halium since 2017 (and Canonical since 2012). It is also available on more devices than these 2. Actually, FuriOS is based on Droidian which itself is a fork of Mobian. Sailifish is as less open than any Android ROM, and is backed by a for-profit company, so I can compare it only to iOS.
So, no, there aren’t 2 choices, and if they were, they wouldn’t be those 2.
The issue with Ubuntu Touch is most of the phones DO NOT have Volte (there are maybe 3 which require constant hacks to enable/disable depending on what you are doing). A phone unable to make phonecalls isn’t really a phone is it?
That may work for you. That doesn’t work for me.
Hence why I gave the two projects that support VoLTE on every phone they officially support.
Ubuntu touch has maybe 3 phones that can do VoLTE and require hacks to enable/disable depending on what you are doing.
That may work for you, but for me and most people a phone has to reliably make and receive phonecalls. Otherwise its not really a phone is it?
Plus an immutable OS c’mon, they don’t know better than me what I should and shouldn’t be allowed to do.
You can develop natively on Android. Your particular favorite development environment? Well maybe if you are writing console apps in a text browser and compiling them in GCC. If you want something a little more desktop based well no but that’s kind of a funny thing to ask for. Android has its own development environments that run in Android for graphical apps. It sounds a little like asking to run your favorite windows development environment in Linux or Mac development environment on Windows. Kind of an odd thing to ask.
As for a serial comms and usb access… Not on a locked down consumer device. Have you tried it on Lineage? I bet it can be done.
This product existed in 2009, so technically you’re wishing for a product that doesn’t exist anymore. The Nokia N900 running Maemo was fully a Linux computer with root access (the only app that supported holding the phone in portrait orientation was the phone app), had a slide out physical keyboard, and was competitive with the smartphones of the era (your Palm Pres, iPhone 3GS, Blackberries, G1s) in price and features –it had a particularly advanced camera. Unfortunately it was the second to last dying gasp before Microsoft acquired Nokia smartphone assets and immediately replaced Linux with Windows Phone. I had an N900, it was glorious.
These days people will tell you it can’t be done because they’ve allowed themselves to become dependent on a social media app, blue text bubbles, or a contactless payment system that can’t possibly work on Linux. It’s unfortunate.
I had no idea this existed. Yea so if someone remade this with more modern specs I would love it. Don’t need 16gb of ram or anything.
+1. I would buy this in a heartbeat.
n900 was awful in so many ways. Especially the software stack. You are way better off with even the Android 2.0 of 2009 than with Maemo. In a lot of ways, it was very closed as well. A lot of binary blobs you can’t get through, just like Android. But unlike Android, it was neither debugged before shipping, nor supported after.
Why do you need to get through the binary blobs though you certainly weren’t creating an OS from scratch (which btw there were countless people who were extending the life of the N900 back then by working on the OS)?
I compiled a lot of stuff on my N900. It worked just fine. You are really pushing android for some reason with its shitty SDKs and rigid requirements its frankly not worth the dev effort.
MMS not being supported on the N900 was different and annoying though. fMMS never really worked very well.
I am not a purist. Remember, i’m the guy who said the answer you’re looking for is cyanogenmod.
I had to get through the binary blobs because they’re buggy af. That was my problem with the nokia Maemo (where i wanted to use audio, but the closed driver was buggy), and the raspberry pi too (where i wated to use HDMI, but the closed driver was buggy).
Also had one amazing “phone” loved the keyboard and even had an IR output if I remember correctly?
Genuine root was 😍
Any low-volume phone is going to be 2-10x the price of a mainstream phone though – the R&D is a huge cost and the big players have utterly insane economies of scale as well as well established distribution & user-base.
Apple could make a dog turd in a box for $100 and still know they’re going to sell at least a million of them before anyone notices.
You simply cannot make a smartphone with a raspberry pi as its brain. You need the ability for the CPU to throttle down to a low power mode without turning off. It’s the non-negotiable sine qua non of pocket computing, and has been for 25 years, and pi doesn’t have it.
That is… unless you’d like to have a built-in pocket warmer function present at all times. Useful during the winter, maybe :D
Given the speed of wake possible if the ‘modem’ can do all the I’m not really using the device tasks of a smartphone and boot the Pi only when more heavy lifting is required it could be fine. As really the while on and idle or actively in use power draw of the Pi while not superb compared to more mobile focused and newer silicon it isn’t really that far away.
Does rather depend on how performant the inevitable arm core(s) inside the modem chip are, amount of storage and memory it has access to, and if you can actually get anything but the blob it ships with to run without breaking the modem functionality. But a phone that only does phone things like be always on enough to accept an incoming call running on the modem with a more real, open, likely upgradeable desktop like computer turned entirely off 99% of the time, but available when you need it in seconds… I’d still call that a perfectly good smart phone.
It would be a step backwards of at least 25 years. If that’s fine for you, different strokes.
Not sure it would be – really pretty comparable to what happens in modern devices anyway where the modem is largely if not entirely all that stays running till something makes it ‘wake’ the parked main compute cores, just these days they all tend to be on the same die.
If you get the software right this will seem just as smooth for the user, and might actually end up with longer sat in a pocket battery life as the more discrete modem master node doesn’t need to keep nearly as much RAM stored data fresh enough to come back from that lower power state as the full modem+SOC all in one chip that only has the one shared RAM pool (at least I think that is how most if not all modern smartphones are now architecture wise) – obviously behind the scene actually cold starting does take a bit longer, especially if its loading the saved to non-volatile storage previous session (though it doesn’t need to load anything more than the currently required app at that moment), and having more discrete silicon is likely to be more expensive upfront and have worse power consumption in use than more tightly integrated but you the user are not going to notice the difference (if it is done well enough).
The only big difference for the user if you can get that software experience polished enough is that in this case you can pop the compute module off the back, likely still use the device as a rather basic phone and of course replace that CM with anything else in the compatible range rather than replace the whole device (which might well include some of the not Raspberry Pi compute modules – though so far I don’t know of any of those that are likely to be good candidates).
I’m just absolutely astonished at the counter-factuality of this message.
Android does not work that way at all. One of the general compute cores wakes up constantly to do a myriad of housekeeping tasks. 15 years ago, a lot of phones were well-enough tuned to go up to a minute without waking, but that day is long over. The slopware-filled Android phones of today are always waking up. Some of that is simple software stupidity but mostly it’s because a brief wake up simply doesn’t consume much battery power, it isn’t something worth optimizing for.
And this idea that something is a minor problem if only the software was perfected…man, real portable OSes go to great lengths to define app lifetime in such a way that an app can be completely stopped and then resumed in a fairly seamless fashion. This was the cornerstone of PalmOS’s design, and is a big factor in Android’s app lifecycle APIs as well. It would take a lot of work, but it’s easy to imagine an Android environment designed to reboot on every wake. But things like GNOME have absolutely no concept of any of this, it’s a completely foreign way to operate for them.
And that isn’t exactly unusual, not quite so perfectly seamless perhaps but KDE at least has options to restore the previous session on a full computer reboot automatically, manually, or just start with a new session and so many apps do the same in for themselves – firefox saving the previous session etc…
Not every app plays nice with KDE’s restore, permissions can be a problem if your user doesn’t always have access to say the KVM/Qemu stuff so that virtual machine software of choice will be started but then need you to authenticate again, and the virtual machines themselves won’t restart (at least not by default). And I understand Gnome is well on the way to having a session restore feature that seems to be more fully featured than KDE’s currently is. Yes still work to do, but it isn’t an impossibly steep looking hill still to climb to get really darn close to if not exceed the Android user experience with a device like this at least in part because you get to avoid “The slopware-filled Android”.
the pi5 does no ?
No, pi 5 still has idle power consumption that is bad even by the standards of a TV box.
I don’t think people realize how amazing it is what Qualcomm and Allwinner et al have accomplished in the smartphone space. Since the very beginning of Android, phones have been always-on but drawing miliwatts most of the time. My phone’s battery lasts about a week of idle (about 4 days of real use) but if i look in logcat, it is spewing error messages to itself every couple seconds, 24/7. The CPU enters a truly low-power idle mode in between wake ups even when the wake ups are spaced very close together. It’s so amazing that we don’t believe it’s true, but also it’s so commonplace that we take it for granted and we’d hate anything less.
Pi has nothing remotely like that. My pi 4b is running 10C over ambient even 100% idle.
The ratio in power consumption between 0% and 100% utilization on a mobile CPU should be about 100, but on pi 5 it is about 4: https://www.jeffgeerling.com/blog/2024/new-2gb-pi-5-has-33-smaller-die-30-idle-power-savings/
Which is weird because I was sure the processors in those were designed for mobile applications.
Finally! I’ve been thinking of trying something like this for a while but never got around to it. Happy to see that someone is tackling it. This will certainly go to the top of my todo list to try out. We desperately need an open alternative to the smartphone duopoly.
A Raspberry Ii will never make a useful phone. It’s just not low power enough to make sense for a smartphone.
How do you get it approved on a carrier’s network ?
Can see it now – “Well Verizon rep, I built this phone myself as a hobbyist”…. CLICK !
with a sim card
Yep, I’ve NEVER told my carrier what phone I was using. They can probably figure it out from some meta data being sent, but even if they can’t, they just charge for the 1s and 0s anyway.
Cool. Which country/network? Is that officially supported, or just ignored? For the contracts I have actually seen in the US (admittedly, I do not live near a tech hub or even a major city), I might be able to move a SIM card from the official phone and hope they didn’t enforce things, but …
The guy you are responding to is right. VZ will let it have data, but wont allow phonecalls. They whitelist phones.
T-mobile will allow you to run anything you want though.
They can only see what modem you have, because of that, there would be absolutely no problem with connecting a phone like this to a cell network. You could even connect a plain eg25 devboard connected to an arduino to a cell network if you’d like lol.
ARM is a proprietary ISA, can say closed source xD ….
Risc V is probably a better choice than the Pi. Better low power mode and still beefy enough to run Linux. ARM would also do fine, but like you say, its less open.
From the article–
“…raising the possibility that with perhaps some community effort this truly open hardware smartphone will become a reality.”
Kinda like the business model of Pine Microcomputer, which business model has left the hacker landscape littered with dead, failed projects precisely because of this precisely similar, untenable, business model.
Want just two high-profile, highly-hyped projects–which HAD outstanding spec-sheets–and which died because of the lack of any software support on Pine Micro’s part?
Try
1) Pinebook Pro laptop notebook computer.
An absolutely dynamite laptop (from a hardware standpoint, including its magnesium case), with absolutely zero software support from Pine.
2) Pinephone Pro smartphone. Another dynamite device, which included all sorts of privacy features. Unfortunately, it also included the dynamite demand of complete and on-going user contribution-and-very-hard-work to make it a continuingviable product.
Bottom line? You want a real, no hassle product? Make absolutely certain that the ‘manufacturer’ is not offering a pipe dream, wherein he/it/they are depending on others to do all the really hard stuff—THE SOFTWARE, to make it work!
Don’t EVER forget: the hardest part of any project is the software.
The “Pi Comput Module” isn’t powering anything— it’s an interesting prospect, but not a real thing. This group has not created a phone, they’ve created a few files and a github. Also, I know it gets mentioned every time someone suggests a Pi phone, but having no low-power hybrid power-mode makes the pi a non-starter for a battery-powered smart-phone.
Well we will wait for you to do better !!!
One does not need to be a chef to tell the turd they’ve been served tastes like shit.
Kind of interesting, but almost the worst possible choice of hardware in this space for a phone and it’s all closed source. Nothing but a vanity project that isn’t going anywhere.
To be fair to the pinephone, the raspberry pi is pretty open-source-hostile. Yes, it runs an open source OS (linux) but that’s the only thing open about it. I can do the same with my PC.
The board design isn’t open source. The chip is a custom proprietary one that cannot be bought. The boot firmware on the VPU has high privilege and is closed source. The camera module has DRM to try and lock out 3rd party camera modules. And on the list goes.
The worst thing I can say about the pinephone that isn’t in the list above is that they’re doing their battery management in software, which is a no-no from a safety perspective. They also tick some of the above boxes raspi don’t.
When people say all they want is a Linux based phone, me and my Android get a good laugh. And when people claim a project isn’t open source don’t understand the term. It is a segment of IP licensing. The project is only open source if it is published under one of the several open source licenses. There are more than one, meaning there are different sub-definitions of “open source” as there has been for many, many, many years now. Monetized IP is how many developers and manufacturers support their open source projects, so suck it up, support the end goals and understand that sometimes you need to break out an oscilloscope and spend a crap load of your own time to gather the knowledge you are looking for. No one owes it to you to do that work for you, thinking otherwise is entitlement and turns devs off from open source projects.
I don’t expect to ever see an open source LTE module because it wouldn’t get approved by various countries communication commissions.
But that’s ok. Let it be a black box providing data, voice calls and text that we can talk to from an open source pocket computer. So long as we can do anything and everything we want in that computer I think that’s about the best we can expect to get and a hell of a lot better than what’s available today.
The interface to talk to the black box. That needs to be open.