Thingino firmware: an open-source replacement for Ingenic IP cameras

What Thingino replaces on an Ingenic camera

Most budget IP cameras ship with a vendor firmware that phones home, exposes an undocumented API, and stops receiving fixes once the model is superseded. Thingino is an open-source firmware for cameras built on Ingenic SoCs, distributed under the MIT license. The target user is someone who owns such a camera and wants to control what runs on it: a self-hoster, a small site operator, or a developer who wants a known build rather than a black box. The project publishes a list of supported cameras in docs/hardware/supported-hardware.md, and the website carries an illustrated version of that list. That list is the boundary of the project. Thingino is not a general-purpose camera firmware that adapts to arbitrary hardware; it is built per SoC and sensor combination, which is why the repository carries Config.soc.in and Config.sensor.in as separate configuration inputs.

Two branches, two streamers, and a warning about U-Boot

The repository splits work across a ciao branch and a master branch, and the README is explicit that these are not interchangeable. Ciao is described as the reliable, tested version for general use. It uses the original ONVIF server and Prudynt with libconfig, and it receives critical fixes. New features reach it only after they have matured in master. Master is the development hub. It uses the raptor streamer, which the README describes as still in development and possibly unstable. The README also carries a warning that master uses a highly experimental mainline U-Boot, and that having UART access on the camera plus unbricking skills is highly recommended when building images from it. That warning is the single most important operational fact on the page. A camera is not a server you can reimage over the network if the bootloader goes wrong; recovering it usually means opening the case. The documented recovery path is docs/firmware/camera-recovery.md, and the documented backup step is docs/firmware/firmware.md. The README states plainly that users who are not contributing to development should stick with the stable branch.

Building Thingino from source on the stable branch

The README gives the source build as a clone of the stable branch with submodules, followed by two make targets. The --recurse-submodules flag matters because Buildroot and the package trees are pulled in as submodules; a plain clone will not build. The first make invocation runs the update step, which refreshes those submodules and the package sources.

git clone -b stable --recurse-submodules https://github.com/themactep/thingino-firmware
cd thingino-firmware
make update
make

A plain make without CAMERA= set will try to open an interactive camera selector. The Makefile comments note that a headless run without CAMERA= would hang waiting for fzf or whiptail input, which is why the WORKFLOW=1 flag exists to skip the dependency check and the interactive selection. If you are scripting the build, supply the camera on the command line and set WORKFLOW=1. A second flag, PRISTINE=1, points THINGINO_USER_DIR at /dev/null so that local user fragments, overlays, and local.mk do not leak into the image; the Makefile describes this as the mode for reproducible or OEM builds. The README points to the Building from sources wiki article for the longer version, and to docs/build/local-build-settings.md for the layered settings that come from THINGINO_USER_DIR/common, per camera, and per device IP.

Building in a container when you do not want the toolchain on your host

If you would rather not install the cross-compilation dependencies on your machine, the repository ships build-container.sh. It pulls a prebuilt builder image from ghcr.io/themactep/thingino-builder-image on first run and requires either Podman or Docker. The clone step is the same as the source build, so the branch choice still decides which firmware you get.

git clone -b stable --recurse-submodules https://github.com/themactep/thingino-firmware
cd thingino-firmware
./build-container.sh

The README points to docs/build/container.md for the details. This is the lower-friction path for a one-off build on a workstation, and it also sidesteps the dependency check script that the Makefile runs on a bare make. What it does not change is the output: you still get an image for a specific camera configuration, and you still need to flash it yourself.

Where Thingino is the wrong tool

The supported hardware list is a hard constraint, not a suggestion. If your camera is not on it, the build system has no configuration for your SoC and sensor, and the firmware will not run. That rules out most cameras from vendors outside the Ingenic ecosystem, and it rules out models whose sensor has no entry in Config.sensor.in. The second constraint is the update story. The repository has Makefile.ota and a documented recovery path, but the README does not describe an automatic rollback if a flashed image fails to boot. Recovery is a manual procedure documented in docs/firmware/camera-recovery.md, and on the master branch it may require UART. If your cameras are mounted somewhere you cannot physically reach, that is a reason to stay on ciao, or to stay on the vendor firmware. The third constraint is support. There is a Discord channel, a Telegram group, and the GitHub issues page, and the README frames those as the place for questions and contributions. There is no vendor SLA behind any of it.

How this differs from OpenWrt-based camera firmware

The obvious alternative for people who want to replace camera firmware is an OpenWrt-based image. The difference is in what the two projects optimize for. OpenWrt is a general-purpose router and embedded Linux distribution with a package manager and a large feed of userspace software; camera support exists there, but it is one use case among many. Thingino is a Buildroot external tree, meaning the root filesystem is assembled at build time from a fixed configuration rather than installed and extended at runtime. That produces smaller, more predictable images and removes the package manager from the device, which is a reasonable trade for a camera that should do one job. It also means adding software means rebuilding the firmware, not running a package install. The README also names raptor as the streamer on master and Prudynt with libconfig on ciao, so the streaming stack itself differs between branches, not just the package set.

Maintenance, licensing, and what an upgrade costs you

The repository is not archived, and the last push was on 2026-08-25, with releases tagged master-2026-08-25 and firmware-2026-08-14 in the same period. That is a project still moving. The cost of that movement lands on you at upgrade time: because ciao and master carry different streamers, moving a camera from one to the other is not a patch, it is a reflash with a different configuration. The README's own guidance is that critical fixes and matured features flow from master into stable gradually, so the practical upgrade path for a non-contributor is to track ciao releases and leave master alone. On licensing, the repository carries an MIT license at the top level, but the firmware image is assembled from Buildroot and a large set of upstream packages, and those carry their own licenses. The MIT file covers the Thingino tree, not necessarily every binary that ends up in the image. Checking the license of the components you redistribute is your job, not something this article can settle.

Editorial conclusion

Adopt Thingino if you have a camera on the supported hardware list and you are willing to read the recovery documentation before flashing anything. Do not adopt it if you need a vendor support contract, or if your camera is not on that list, because the firmware is built per SoC and sensor configuration. Before flashing, verify three things: that your exact model appears in docs/hardware/supported-hardware.md, that you have dumped the stock firmware per docs/firmware/firmware.md, and that you know whether you are installing a ciao build or a master build, since the master branch uses an experimental mainline U-Boot and the README recommends UART access and unbricking skills for it.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes