Flipper One is easy to misunderstand if you approach it as “the next Flipper Zero.”

That is not what Flipper Devices is building. The Zero is a low-power tool for offline access-control and radio-adjacent protocols: NFC, low-frequency RFID, sub-GHz radio, infrared, iButton, UART, SPI, I2C, and similar edges of the physical world. Flipper One moves into a different part of the stack. It is a pocket Linux machine for IP networks, expansion modules, field diagnostics, small-screen workflows, and experiments that need real compute.

The announcement matters because it is not a normal product launch. There is no finished retail device being tossed over the wall. Flipper is opening a large unfinished hardware and software project while major engineering decisions are still alive. The team is asking for kernel people, hardware people, UI people, documentation people, testers, module vendors, and opinionated users to help shape the thing before it hardens.

That is both the exciting part and the warning label. Flipper One is ambitious in the way open hardware projects are often ambitious: the idea is clear, the prototype path exists, but the hard parts are deep in boot chains, drivers, power behavior, mainline support, tiny-screen interaction design, and all the unglamorous work that turns a neat board into something people can trust in a bag.

The Real Pitch

The shortest description is this: Flipper One is meant to be an open ARM Linux platform for connected hardware work.

The hardware target is a handheld device with a Rockchip RK3576 application processor, 8 GB of RAM, Wi-Fi 6E, two Gigabit Ethernet ports, USB Ethernet, HDMI, USB-C DisplayPort Alt Mode goals, M.2 expansion, GPIO expansion, and a small built-in control surface. That puts it closer to a Linux cyberdeck, field router, portable network analyzer, or compact workstation than a radio toy.

The source article frames One around Layer 1 networking: Ethernet, Wi-Fi, cellular, satellite, SDR, and IP traffic. That framing is useful because it explains why the product exists alongside Zero rather than above it. Zero is for low-power point-to-point protocol work. One is for higher-throughput connected systems.

The built-in networking story is the most concrete first use case:

• Two independent 1 Gbps Ethernet ports
• Wi-Fi 6E across 2.4, 5, and 6 GHz bands
• USB Ethernet up to 5 Gbps over USB-C
• Optional cellular through an M.2 modem
• Potential satellite NTN connectivity through a supported M.2 module

That combination lets the device act as a router, VPN gateway, inline bridge, failover box, USB network adapter, Wi-Fi analysis platform, or small portable lab. None of those ideas are impossible with a laptop and adapters. The point is packaging: a durable device with the ports, battery, screen, buttons, expansion path, and software profiles designed around that job.

Why Mainline Linux Is the Center of the Story

The most important promise is not the case shape or the port list. It is the mainline Linux goal.

Flipper wants One to run on a recent upstream kernel without a vendor board support package. That sounds like an implementation detail until you have maintained ARM hardware for more than one product cycle. Many ARM boards work because a vendor shipped a heavily patched kernel, binary boot pieces, private trees, and just enough documentation to make the demo pass. Then the product ages, the vendor tree drifts, security patches become painful, and users inherit a stack nobody outside the chip vendor fully understands.

Flipper is trying to avoid that trap by working with Collabora on upstream support for the Rockchip RK3576. Collabora says the RK3576 support is already in decent shape: major components are working, with active focus on power management and USB DisplayPort Alt Mode. Hardware video decoding and NPU support are still not fully there in mainline, and one early boot component remains closed: the DDR trainer that initializes memory.

That last blob is small in surface area but large in symbolism. A platform can be open in nearly every way and still depend on one opaque early-boot piece. Flipper is explicitly asking for help closing that gap, whether through engineering work, vendor pressure, documentation, or upstream review.

This is where Flipper One becomes more than a gadget story. If the project succeeds, it becomes a proof point that a consumer-adjacent ARM device can ship with a serious upstream-first posture. If it fails, it will probably fail in the familiar places: power behavior, display plumbing, video acceleration, NPU enablement, firmware boundaries, and the cost of sustaining open support beyond the launch window.

The Two-Processor Design

Flipper One has a split brain by design.

The RK3576 runs Linux and handles the heavy work: networking, desktop mode, local tools, models, storage, routing, and anything that needs real compute. A Raspberry Pi RP2350 microcontroller handles the low-power control plane: display, buttons, touchpad, LEDs, power subsystem, and boot control.

This matters because small Linux boards tend to be dead when Linux is off. A Raspberry Pi without the OS running is mostly an inert board. Flipper wants One to remain controllable through the MCU even when the main CPU is powered down. You should be able to wake it, select boot behavior, manage power, and interact with the device without waiting for a full Linux session.

The interconnect is not trivial. The processors communicate over SPI, I2C, UART, and GPIO lines. SPI can carry framebuffer data to the MCU for display output. I2C can move commands and input events. UART and GPIO can manage boot control. Flipper wants the display and input pieces reviewed and upstreamed cleanly rather than shipped as a private hack.

That is a good instinct, but it also creates real schedule risk. A custom CPU-plus-MCU product architecture is not just a board design choice. It becomes kernel work, firmware work, protocol design, debugging work, testing work, and documentation work. It can be elegant if the boundary is clean. It can become a support burden if the boundary is fuzzy.

Flipper OS Is the Bigger Software Bet

The hardware is only half the plan. Flipper also wants a better way to use portable Linux boxes.

The complaint is familiar: a small Linux device starts clean, then each new project mutates it. Today it is a travel router. Tomorrow it is a packet capture box. Next week it is a media player, SDR station, or debug workstation. Packages accumulate, config files drift, kernel bits change, and eventually the fastest reset path is to reflash the storage.

Flipper OS is the proposed answer. It is described as a Debian-based layer with profiles: full OS snapshots carrying different packages and settings. You could boot a clean router profile, clone it, break the clone, experiment, and return to a known-good state without swapping SD cards or rebuilding from scratch.

That idea is valuable beyond Flipper One. Portable Linux devices need state management more than they need yet another desktop image. The hard part is choosing an architecture that is understandable, resilient, storage-aware, and friendly to updates. Snapshot systems can become magic until they fail. Profiles need clear boundaries: what is shared, what is isolated, what survives updates, what gets rolled back, and how users recover when a profile cannot boot.

Flipper is not pretending that part is solved. The project is still looking for input on how Flipper OS should work.

FlipCTL and the Tiny-Screen Problem

The other software bet is FlipCTL, a small-screen UI framework for Linux tools.

This is a real problem. Most Linux utilities assume a terminal, a desktop, a web UI, or at least a screen large enough to tolerate clutter. A handheld network tool does not have that luxury. Squeezing KDE, GNOME, or a normal desktop app onto a tiny screen makes the hardware feel like a bad laptop instead of a good instrument.

FlipCTL is meant to wrap command-line utilities in a menu-driven interface controlled by buttons and a small display. Think ping, nmap, traceroute, routing profiles, interface setup, and diagnostics exposed through an interface that makes sense when the device is in your hand.

The interesting part is that Flipper wants this to outgrow Flipper One. The long-term ambition is a package any embedded Linux device could install to gain a usable button-and-screen interface without pulling in a full desktop stack.

That is the right abstraction if it stays humble. The world does not need a giant new UI platform for every embedded Linux device. It might need a clean way to bind command-line tools, system state, and small-screen controls into predictable menus.

Expansion Is the Product Strategy

Flipper One is not supposed to be one fixed tool. The expansion system is central.

The M.2 slot is Key-B and is designed to support module sizes 2242, 3042, and 3052. Flipper says it exposes PCIe 2.1 x1, USB 3.1, USB 2.0, SATA3, serial audio, UART, I2C, and SIM connectivity. That opens the door to cellular modems, satellite modules, SDRs, SSDs, AI accelerators, and Wi-Fi cards through adapters.

There is also a simpler GPIO module system using 2.54 mm headers, threaded inserts, snap-fit notches, and swappable mechanical parts. The team is publishing enclosure pieces so module authors can build back plates, antenna rails, and custom add-ons without guessing the physical interface.

This is where Flipper’s community strategy has to become operational. Expansion ecosystems live or die by boring details: pinouts, mechanical tolerances, thermal envelopes, power budgets, antenna routing, certification constraints, example modules, and stable documentation. A beautiful expansion connector is not enough. Module authors need a platform contract they can trust.

The Wi-Fi, Satellite, AI, Desktop, and TV Box Ambitions

Some parts of the announcement are concrete. Some are directional.

The Wi-Fi plan is reasonably grounded: Flipper is testing the MediaTek MT7921AUN, the chipset used in the Alfa AWUS036AXML adapter, because it has mainline driver support and is already popular in wireless analysis circles. The device needs monitor mode, packet injection, AP and client behavior, and broad compatibility with real auditing workflows. Flipper is asking wireless users to test and challenge the choice before it becomes final.

The satellite plan is more exploratory. Flipper wants to support NTN, the 3GPP non-terrestrial network technology used for low-bandwidth satellite connectivity in modern cellular stacks. That would require a suitable M.2 module and a network partner such as Skylo. It is a compelling field-computing story, but it is clearly not the same maturity level as Ethernet ports on a board.

The AI plan is also early. The RK3576 has an NPU, and Flipper wants a local assistant that understands the device, helps write configs, and remains useful without internet access. That is plausible if scoped tightly. A small domain model for device guidance is more believable than a general offline assistant. The blocker is that NPU support still needs mainline work, and the product needs enough documentation and examples for a local model to be useful instead of ornamental.

Desktop mode is another stretch goal with real appeal. With USB-C DisplayPort Alt Mode, HDMI, and Raspberry Pi 5-class performance, One could become a small workstation or thin client. But the open issues are exactly the ones that make portable Linux hardware painful: USB-C DP Alt Mode stability, monitor compatibility, mainline support, hardware video decoding, and choosing a desktop environment that does not turn the device into a bloated mini PC.

The TV box idea is more personal but still coherent. A full-size HDMI port, 4K 120 Hz target, and HDMI CEC support could make the device useful as a travel media box controlled by a hotel or Airbnb TV remote. The full-size HDMI decision is practical: adapters are the kind of tiny failure that ruins a portable setup.

What to Watch Next

Flipper One is not a finished product. It is a large public engineering bet.

The credible parts are the ones tied to visible architecture and active upstream work: RK3576 mainlining, Collabora involvement, the dual-processor split, M.2 expansion, open mechanical parts, and the developer portal. The risky parts are the ones that require many independent pieces to mature together: Flipper OS profiles, FlipCTL, NPU support, satellite modules, desktop polish, power behavior, and a real contribution pipeline.

The community angle is not optional. Flipper is publishing open tasks across Linux, MCU firmware, UI, docs, hardware, mechanics, and testing. That means outside help can matter, but it also means Flipper has to do the governance work: review contributions, respond to feedback, merge useful work, and keep the project from becoming a public backlog nobody can move.

The best version of Flipper One is not merely a “hacker gadget.” It is a well-documented portable Linux platform that makes networking, field debugging, and embedded experimentation easier to teach, inspect, and extend.

The worst version is a gorgeous prototype attached to too many unfinished ideas.

The next few months should make the difference visible. Watch the developer portal, the RK3576 mainline status, the open task trackers, and the quality of Flipper’s contributor loop. The hardware pitch is strong. The real test is whether the project can convert openness into sustained engineering progress.

Sources: Flipper Devices announcement, Flipper One developer portal, open tasks, Collabora on RK3576 support, and BleepingComputer’s hardware report.