As microcontrollers become ever faster and cheaper, something we’ve been expecting has been an open source smartphone based not upon a high-end chip, but on a cheap commodity one. In the electronic badge arena we’ve come pretty close, but perhaps it’s left to [Gabriel Rochet] to deliver the first one that brings everything together. His Paxo phone is now on version 4, and while the French-language website link stubbornly resists translation with Google translate, English speakers can find a description of its capabilities along with the software in a GitHub repository.
The hardware is surprisingly straightforward, with a resistive touch screen and a PCB featuring power management, an ESP32 main processor, and a GSM module. The 2G connectivity may not be the fastest, or even available in your country, but otherwise the feature set looks more than reasonable for a basic mobile phone.
We like this project a lot, because as we said it starts to deliver on the promise of the 2018 EMF badge and the 2022 MCH badge. We think the former badge’s designers might find something of interest in it.
This one? https://hackaday.com/2023/08/03/open-source-cell-phone-based-on-esp32/
Oof, its even the same picture… just cropped.
I like to imagine that they’re going to keep reposting this article, and every time just crop the image smaller and smaller. 😃
LOL!
They were both out in the field, where reporters usually are. There was only upload capability on Saint Barthélemy beach so they did not have the ability to check what the central bureau was publishing ;)
one day, maybe the writers will be forced to verify the article doesn’t already exist before writing it…
They _are_ supposed to. They can make mistakes, though.
Perhaps they need an edit button! ;-P
Imagine if unicorns were real. They could provide oversight on articles. The right unicorn might be able to craft something I’m tentatively calling a ‘searchable database ‘ using ‘key words’. But alas, such a thing is not possible, and may not be, for the foreseeable future. I guess a reasonable unicorn facsimile, called an ‘editor’ might be capable, but again that’s just wild, imaginary spitballing on my part. Oh well.
Yeah, and sometimes a lot of people’s first time seeing them is the repost, because the posts can die quickly. It’d be better organized if there was a way to establish links between related posts retroactively, I guess?
And perhaps, the editor could take the initiative and double-check this.
I guess everyone is doing his/her best, still as a end user of the site I feel this happens far too often.
So it’s groundhog day, again….
Not to detract anything from this well-designed project, but last time I checked in-depth, the ESP32 is not open source. It is a thin layer of open source code that calls into the proprietary and closed source binary blobs released by espressif. Has something changed recently?
Is it finally possible to run the WiFi stack on any other OS other than the espressif-supplied freertos build that’s part of one of those blobs?
That is true of everything though, outside risc-v
Even with RISC-V as your main CPU’s ISA, you still might need firmware blobs for various devices you have on board; also the open ISA does not stop your CPU vendor from using microcode, or hiding a backdoor. I think the former is an acceptable risk, as long as you have an IOMMU in between. For the latter, you have to answer yourself: what is your threat model?
Depend on how you look at it. If by “opensource” you mean anyone can buy the same components and program it, it’s opensource, even if there are some closed source components. But if you want every code from every component, yes, it’s partially open.
I don’t know about any open baseband component easily strapped to a microcontroller, so I would be happy with a closed source one…
Luring users to Discord is not very “PAX-y”.
Not true, STM32, RP2040, AVR, PIC, pretty much any microcontroller can be used 100% without any binary blob whatsoever. The ESP32 is the only popular microcontroller I am aware of that requires binary blobs…
It especially bugs me as I wrote an RTOS and can’t port it to the ESP32 as the binary blobs already include one (freertos) and depend on it.
Only for the WiFi/BLE part though, if you don’t need that it can just run code like any other microcontroller. The FreeRTOS part is open source, so as long as your OS implements a shim emulating the FreeRTOS API the proprietary lib should work.
Anything that does network is going to require binary blobs. Mostly because the manufacturers want to avoid legal risks.
Could be a good topic for an article: looking at how shitty laws don’t let us have nice things. Locked up networking firmware, non-replaceable batteries (due to shipping regulations), that kind of stuff. People blame the manufacturers, when it’s actually the lawyers.
If hackers did their work better and open sourced it more often then sh*** laws become irrelevant. Political and legal systems have all been ****ed up beyond any possibility of reforming them, but a strong open source movement can overcome the mere words on (not even any more) paper, that the politico-legal complex burdens the people with. A new political party in any western nation isn’t likely to even get one MP within 10 years, no chance of forming a government for many decades by which time the new party will have been infected by the bureucratic types who run all the existing parties, but a technical workaround which works and is shared can fix things at the practical level immediately.
You mean lawmakers. Who do you think is lobbying them?
Zephyr supports the ESP32, so it’s possible to use it without freertos and also to port to another rtos, because that’s been done.
The only binary blob I know of for the esp32 is the bt/wifi baseband. It’s a binary blob for Nordic too. With the STM32, the baseband is a binary encrypted blob you can’t even flash with stn32flash. Only the closed source stm32cube software had support for flashing it.
i’m speaking from ignorance and a lack of personal experience here…but it looks like zephyr doesn’t support bt/wifi yet on esp32 (assuming zephyrproject.org is up to date). it also looks like zephyr is receiving some official support from espressif? so it sounds like you do have to use freertos to use the bt/wifi binary blob, and maybe in the future if zephyr does ever support wifi on esp32, the way around that is going to be to get a different (or adapted) proprietary blob just for zephyr.
of course you’re completely right that these wifi blobs tend to be proprietary anywhere you go!
vaguely reminds me how frustrated i was to find that the raspberry pi proprietary interfaces were all designed around the assumption you would use pthreads instead of a proper I/O model :)
Closed code is why the ESP32 is even in this project. As someone else mentioned, the CPU embedded in the SIM800 module has all the computing power the phone needs, but since it’s locked down, you need a separate CPU to add the features that make it a phone.
Zephyr does have Bt/Wifi support on ESP32. I’ve used it myself on the ESP32 and ESP32-C3, so I’m quite sure it works. Supposed to work on the ESP-Sx series too, but I haven’t used that myself. I don’t think the webpage is up to date, but there’s an issue somewhere on github they (espressif) update.
AFAIK, you only need the binary blob for wifi/bt. I’m not aware of any chip that has wifi/bt without a closed-source baseband. So ESP32 doesn’t seem any more closed source than anything else to me. Better than some, e.g. SiLabs is stingy on docs and STM32 wifi is a special encrypted blob.
It’s a shame that a second CPU has to be added to achieve this. The MT6260 inside the SIM800L was designed to drive a 480×320 display and even contains an H.264 decoder and a camera interface.
This is on SimCom, the Chinese company that packages a Qualcomm chipset into the modem module used in this phone. I’m building a phone with their SIM7600G-H module, which is a 4G/LTE module, and jumped down a rabbit hole: on their website, they have documentation for their OPEN SOURCE Linux system used on this module. The catch? The firmware source code they make available is only for the European and South American versions of the module, and they are quite specific that it won’t work for the North American or global versions. This could probably be hacked to work globally, but at least for the time being (a being constrained by time, that is,) I am using a Pi Pico to talk to the modem, and also provide for mass storage and other capabilities that aren’t exposed by the SimCom module.
Pine64 appears to have run into similar roadblocks with the Quectel EG25-G module they use in their Pinephone: the Quectel module includes a similar application-level computer on it, but the Pinephone uses a separate quad-core Rockchip processor to do all of the smartphone stuff (this is a Linux-based phone). As a result, it eats batteries for breakfast, lunch, and dinner – it can only IDLE for about 6 hours on the 3 Amp-hour battery in the phone. Whether this is because they are not putting the modem to sleep, or the Linux system to sleep, I don’t know, but it makes this unusable as a phone.
In my project, I’m not even going to try to do Linux; for the first iteration I am using the Pi Pico as a single-thread application processor for apps to be developed later, with the second core dedicated to operating the phone, and it will put the SIM7600 to sleep when not actually doing anything – the module has wake-on-ring and wake-on-SMS, and can also be awakened by asserting a signal on the serial interface it uses to connect to the Pico. I think this is a much lower power solution than trying to hack the Linux computer in the modem module, although for the next iteration I may switch to the STM32U595, which has 1MB internal SRAM and 4MB internal Flash, and consumes a lot less power than even the RP2040. So the only time it should be a battery hog is when actually talking on the phone, or when using it as an LTE modem connected to a laptop, in which case it can be powered by the laptop anyway.
The SIM7600G firmware will work on the global and NA modules as well, without hacking. It’s just that the carrier certification will be invalidated. You can also enable ADB on the stock firmware and add your own application via that.
Thank you. I guess I’ll have to look into that.
Interestingly, the Nokia 225 4G uses an RTOS similar to the old Symbian S60s, called MocorRTOS. The chip is a Unisoc UMS9117 but earlier models used a Unisoc TIGER T117, which is is a single core for both the GSM module and OS. Curious which chipsets could do that on a single core today. not open source but interesting, nonetheless.
esphone are better and more hackable, but still to expensive
Not finding esphone. Link? How is it better and more hackable? This seems pretty hackable.