Hello, Thingino: From Git Clone to Firmware Binary

· Paul Philippov

Part 1 of The Thingino Developer’s Journey

So you bought a cheap IP camera, discovered it phones home to a cloud on another continent, and now you’re here. Welcome. You’re among friends.

Thingino (thin-jee-no) is an open-source firmware for IP cameras built on Ingenic SoCs — the T21, T23, T31, T40/T41 family of MIPS chips found in an astonishing number of consumer cameras: Wyze, Atom, Aqara, Xiaomi-adjacent brands, and hundreds of white-label devices. Flash Thingino and your camera becomes a small Linux computer that you control: local RTSP streaming, ONVIF, a clean web UI, MQTT, no cloud, no subscription, no mystery traffic.

This series is about developing Thingino, not just using it. Today we go from zero to a firmware binary on your disk.

What you need

  • A Linux machine, x86_64 or aarch64. (Debian/Ubuntu are the beaten path.)
  • ~20 GB of free disk and some patience for the first build.
  • A checkout path without spaces. The build system checks and will refuse ~/My Projects/thingino. It’s a cross-compilation thing; don’t fight it.

You don’t need a camera yet. You can build firmware for any supported model without owning it.

The lay of the land

Thingino is a BR2_EXTERNAL tree — an overlay on top of Buildroot, the embedded Linux build system. Buildroot knows how to cross-compile a toolchain, a kernel, and hundreds of packages; Thingino adds camera configs, Ingenic kernel support, its own packages (streamer, web UI, tooling), and a Makefile that orchestrates everything.

You don’t need to understand Buildroot deeply to start. You will absorb it gradually, like a language learned by immersion.

Clone and update

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

Two branches matter: stable (tested, recommended if you’re not changing code yet) and master (development, where the fun and the breakage live). As a future contributor you’ll end up on master soon enough.

make update is not just git pull. It pulls the repo, syncs the Buildroot submodule, applies Thingino’s Buildroot patches, and fetches prebuilt toolchain bundles so you don’t spend your first hour compiling GCC. Always use make update in your main checkout, never a bare git pull — the Buildroot patches need to be unapplied and reapplied around the update.

Picking a camera

Every supported camera lives in configs/cameras/, named by a strict scheme:

<brand>_<model>_<soc>_<sensor>_<wifi_chip>

For example: atom_cam2_t31x_gc2053_atbm6031 — an ATOM Cam 2 with a T31X SoC, GalaxyCore GC2053 sensor, and an AltoBeam wifi chip. The name tells you the whole hardware story at a glance. You’ll appreciate this convention the first time you meet a camera sold under four brand names with three internal hardware revisions.

Your first build

CAMERA=atom_cam2_t31x_gc2053_atbm6031 make

Or just run make and pick from an interactive menu. Then go make tea. The first build downloads sources for every package and compiles the world; count on 30–60 minutes depending on your machine. (Part 2 shows how subsequent builds get much faster.)

When it finishes, look in:

output/<branch>/<camera>-<kernel>-<libc>/images/

You’ll find the individual pieces — uImage (kernel), rootfs.squashfs, U-Boot — and the assembled full flash image named after your camera. That single binary contains the entire partition layout: bootloader, environment, config partition, kernel, root filesystem, and overlay.

Getting it onto a camera

That’s a topic of its own (and camera-specific), but the short version:

  • New install: most cameras are installed via the Thingino web installer or an SD-card bootstrap. See the project site for your model.

  • Already running Thingino? Update over the network:

    CAMERA=atom_cam2_t31x_gc2053_atbm6031 IP=192.168.1.42 make ota
  • Bricked it? You didn’t — Ingenic chips are very hard to brick. Read docs/camera-recovery.md and breathe.

What you learned

  • Thingino = Buildroot + an external tree of camera configs and packages.
  • make update (never bare git pull), then CAMERA=... make.
  • Camera names encode brand, model, SoC, sensor, and wifi chip.
  • Firmware lands in output/<branch>/<camera>-.../images/.

Next up: Part 2 — A Comfortable Workshop, where we stop treating builds like a ritual and start treating them like a tool: containers, incremental builds, caches, and reading build logs like a person who has somewhere to be.