OpenBSD on the Pomera DM250: Replacing a Writing Appliance's Locked OS

The King Jim Pomera was designed around a deliberate absence. No Wi-Fi radio. No browser. No notification system. Just a foldable keyboard, a display, and a text editor. King Jim, the Japanese stationery company behind the line, has been selling this premise since 2008: a writing device that cannot become anything other than a writing device. The DM250, the current model, refines that formula with a compact three-fold keyboard and a lightweight custom Linux environment that boots straight into the Pomera editing application.

Joshua Stein, who maintains jcs.org and runs the Lobsters link aggregator, decided to replace that environment with OpenBSD.

On the surface that reads as contradictory, since the Pomera’s selling point is that it refuses to be a general-purpose computer, while OpenBSD is about as general-purpose as operating systems get. But there is a coherent thread running between them, and the technical work involved in getting OpenBSD onto the DM250 touches on some of the more interesting aspects of how OpenBSD handles ARM hardware.

The Hardware

King Jim does not publish detailed specifications for the Pomera DM250’s internals. The device is sold as a consumer writing tool, not a development board, and its hardware provenance is not the point. Community teardowns and reverse engineering have established that it runs on an ARM Cortex-A class SoC, the display is a small IPS LCD, there is internal eMMC for the stock OS and user storage, and there is a microSD card slot.

The microSD slot turns out to be the critical path for any alternative OS install. On most ARM SoCs, the boot priority can favor SD card over internal storage, which means writing a bootable image to a microSD card can bypass the stock boot chain entirely without touching the internal eMMC. This is the standard approach for getting OpenBSD onto ARM single-board computers and embedded devices, and it avoids any risk to the stock system.

The title of the original post uses the notation DM250{,XY?}, borrowing shell brace-expansion syntax to mean “the DM250 and possibly the DM250XY.” The XY variant appears to be a model with a different keyboard layout, likely a Western QWERTY version alongside the Japanese-primary layout of the standard DM250. The trailing question mark signals uncertainty about whether the same procedure generalizes to the XY variant.

OpenBSD’s arm64 Port

OpenBSD’s arm64 port has matured considerably over the last several years. It boots via UEFI, which on arm64 hardware usually means chaining through U-Boot configured to present an EFI environment. Once UEFI is in place, the OpenBSD installer runs through its normal path, and the resulting system behaves like any other OpenBSD arm64 install.

The variability lies in what happens before UEFI, and what the kernel can actually drive once it boots. ARM hardware does not have a standard firmware interface the way x86 machines do; each SoC vendor ships its own bootloader, and each board or device has a custom device tree blob that describes its peripherals. OpenBSD needs the right device tree entries to recognize that a particular set of registers corresponds to a keyboard controller, a display framebuffer, or a storage interface.

For embedded Linux devices like the Pomera, the stock kernel ships with a vendor-customized device tree that may or may not be usable by OpenBSD. In many cases, close enough is sufficient. OpenBSD’s framebuffer support via wsdisplay(4) can work with a simple linear framebuffer that the bootloader sets up, even without a full DRM driver for the specific GPU. Display output ends up at whatever resolution the bootloader left running, which for a small writing-focused display is generally acceptable.

Keyboard support is the harder problem. An internal keyboard on an ARM device connects through the SoC’s GPIO, I2C, or a dedicated keyboard controller, and the required driver depends entirely on what King Jim chose to put inside. If the controller is a common low-power keyboard IC, there is a reasonable chance a driver exists or can be adapted from existing OpenBSD HID infrastructure. If it is something custom, getting key input working may require writing new code. For a project whose entire point is writing text, a non-functional keyboard would be a fairly complete blocker.

Storage via eMMC or microSD is handled by OpenBSD’s dwmmc driver and related SDHCI infrastructure, which covers a broad range of ARM eMMC controllers and tends to be among the more reliable pieces of an arm64 port on consumer hardware.

What OpenBSD Actually Brings to a Pomera

The stock Pomera environment does one thing well: it starts immediately, presents a text editor, and stays out of the way. Export options are limited but functional. The whole experience is oriented around not requiring the user to think about the operating system.

OpenBSD on the same hardware gives you a full Unix. You get a shell, a package ecosystem via pkg_add(1), standard text editing tools from ed to vim, SSH, rsync, and anything else that builds cleanly on arm64. The folding keyboard and compact form factor become a portable Unix terminal rather than an appliance. Whether that trade is worthwhile depends on what you want from the device.

There is also a philosophical argument worth taking seriously. The Pomera was built around the idea that a writing environment should be focused and closed by design, with no distractions and no background services leaking data or attention. OpenBSD shares a version of that philosophy, expressed through different mechanisms. Its pledge(2) and unveil(2) system calls let processes declare exactly what resources they need, with the kernel enforcing those declarations at runtime. The default install has no telemetry, no auto-update agents, and no background processes beyond what the user explicitly starts. The security model is not about removing features; it is about making the attack surface legible and minimal.

A Pomera running OpenBSD ends up with a security posture and a level of OS transparency that the stock firmware cannot offer, even though the stock firmware is more locked down in the superficial sense of running fewer applications.

Why jcs Does These Projects

Joshua Stein has a well-documented pattern of taking OpenBSD to hardware that was not designed for it. His blog covers ThinkPads, various ARM boards, and devices acquired specifically because their hardware was interesting. The work is not purely hobbyist experimentation: driver improvements and device tree fixes from these projects sometimes feed back upstream into OpenBSD, broadening support for entire categories of hardware.

The documentation value alone is significant. A detailed writeup of exactly what needed to change to boot OpenBSD on a specific device saves the next person days of debugging. The Pomera has a dedicated user base among Japanese writers, journalists, and professionals who want focused writing environments, and at least some portion of that community is the kind of people who would run OpenBSD on their Pomera if they knew it was viable.

The Broader Case for ARM Device Hacking

Consumer embedded devices often have genuinely good physical hardware. Keyboards, batteries, displays, and mechanical build quality that reflect sustained investment in the product. The Pomera series is a clear example: King Jim has decades of experience in physical stationery and office products, and that background shows in the keyboard feel and device durability. Users regularly cite the Pomera keyboard as one of the better folding keyboard mechanisms available, better than many laptop keyboards in the same footprint.

When strong physical hardware ships with a locked application runtime as its only software environment, replacing that runtime with a real OS is a straightforward way to make full use of what the device can physically do. OpenBSD’s arm64 port is capable enough now that the relevant question is rarely whether it can run on an ARM device in principle. It is whether the specific SoC and peripherals have driver coverage, and whether any gaps can be closed with reasonable effort.

For a device where the critical peripherals are a display and a keyboard, and where the primary use case is text editing in a terminal, the bar is lower than for a device with complex audio, cellular radio, or GPU requirements. The Pomera is a good target precisely because it was designed to need so little.

The full writeup at jcs.org covers the specific steps, which is where the real value lies. The broader point is that OpenBSD on arm64 has reached a level of maturity where projects like this are more about driver coverage for specific peripherals than about fundamental porting work, and that is a significant change from where the port stood five years ago.