An Open Source Mobile Phone Based On The ESP32

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.

34 thoughts on “An Open Source Mobile Phone Based On The ESP32

        1. 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 ;)

          1. 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.

        1. 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?

  1. 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?

      1. 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?

    1. 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…

  2. 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.

    1. 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.

    2. 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.

      1. 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.

    3. 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.

      1. 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 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 :)

        1. 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.

        2. 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.

  3. 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.

    1. 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.

      1. 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.

    2. 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.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.