Hi MaSk,
I support the modularity idea too. A device that stays useful long-term, instead of becoming e-waste after a few years, is worth working towards.
I read your article and the N900 framing resonates. I'm going to push on the technical side a bit, but that's because the idea deserves a real look, not because I think it's a bad one.
The Flipper Zero comparison is interesting, though I think the gap is bigger than it looks. The Flipper runs an STM32WB55: a 64 MHz Cortex-M4 with 256 KB RAM and 1 MB flash, running FreeRTOS, driving a 1.4-inch 128×64 monochrome LCD. That's a microcontroller with a mature, well-documented vendor stack. It sold well because it does a narrow job on hardware that ST had already finished and tuned.
A phone is a different problem entirely. You need an application processor, a modem, camera ISPs, a GPU, power management, and a display pipeline, plus drivers and a BSP for all of it. That's where the real difficulty sits.
Suspend and resume is the hardest part of it. Standby means every block on the SoC has to power down and come back cleanly, with its registers saved and restored correctly, and the wake path working through all of them. And it has to hold from the register level all the way up: hardware, drivers, kernel, userspace, applications. One driver that doesn't restore state properly and the phone either won't sleep or won't wake. It only takes a single break anywhere in that chain. This is exactly what has kept PinePhone battery life poor for years, and it's not a problem you can solve at the mechanical or connector level.
Big vendors put thousands of engineers and years of work into a single SoC and its software stack. A community group can't match that, and the chips keep moving. A large company iterates every year or two. The community typically needs six to ten years to fully support a platform, by which time the silicon is several generations old.
I'm not saying this to argue against the idea. I think it actually points at how a hacker phone should be designed: pick a chip that already has good mainline support, accept being a few generations behind, and put the effort into the rail connector and the modules instead. Performance ages badly, but a good expansion standard doesn't. The RK3399 boards are a decent example. Not fast by 2026 standards, but well supported and still perfectly usable.
Which leads to the question I'd most want answered: how do you make sure a module bought today is still worth using in five years? still doing something useful on a device nobody has designed yet.
No idea what the answer is, but I'd like to see someone work it out.
I think the forum still has people willing to have it.
I support the modularity idea too. A device that stays useful long-term, instead of becoming e-waste after a few years, is worth working towards.
I read your article and the N900 framing resonates. I'm going to push on the technical side a bit, but that's because the idea deserves a real look, not because I think it's a bad one.
The Flipper Zero comparison is interesting, though I think the gap is bigger than it looks. The Flipper runs an STM32WB55: a 64 MHz Cortex-M4 with 256 KB RAM and 1 MB flash, running FreeRTOS, driving a 1.4-inch 128×64 monochrome LCD. That's a microcontroller with a mature, well-documented vendor stack. It sold well because it does a narrow job on hardware that ST had already finished and tuned.
A phone is a different problem entirely. You need an application processor, a modem, camera ISPs, a GPU, power management, and a display pipeline, plus drivers and a BSP for all of it. That's where the real difficulty sits.
Suspend and resume is the hardest part of it. Standby means every block on the SoC has to power down and come back cleanly, with its registers saved and restored correctly, and the wake path working through all of them. And it has to hold from the register level all the way up: hardware, drivers, kernel, userspace, applications. One driver that doesn't restore state properly and the phone either won't sleep or won't wake. It only takes a single break anywhere in that chain. This is exactly what has kept PinePhone battery life poor for years, and it's not a problem you can solve at the mechanical or connector level.
Big vendors put thousands of engineers and years of work into a single SoC and its software stack. A community group can't match that, and the chips keep moving. A large company iterates every year or two. The community typically needs six to ten years to fully support a platform, by which time the silicon is several generations old.
I'm not saying this to argue against the idea. I think it actually points at how a hacker phone should be designed: pick a chip that already has good mainline support, accept being a few generations behind, and put the effort into the rail connector and the modules instead. Performance ages badly, but a good expansion standard doesn't. The RK3399 boards are a decent example. Not fast by 2026 standards, but well supported and still perfectly usable.
Which leads to the question I'd most want answered: how do you make sure a module bought today is still worth using in five years? still doing something useful on a device nobody has designed yet.
No idea what the answer is, but I'd like to see someone work it out.
I think the forum still has people willing to have it.