Yesterday we finished the CPU internals arc with microcode.

We went below the operating system.

Below firmware policy.

Below the instruction set’s polite brochure.

Today we move to the hallway.

There is a cheap IP camera on the wall.

It has a lens. It has a microphone. It has WiFi. It has a mobile app. It has a cloud account.

The vendor calls it smart.

The Republic calls it an unpaid informant with firmware.

Inside the plastic shell is not magic. It is a small Linux machine with a camera sensor, an image signal processor, a video encoder, a bootloader, flash partitions, and a vendor userspace that often serves the cloud before it serves the owner.

The People’s Optical Ministry will now inspect Thingino and the T-series camera dynasty:

T20 -> T21 -> T23 -> T30 -> T31 -> T40 -> T41 -> ... T-1000

The numbering is not subtle.

Every generation gets closer to the liquid-metal assassin from Terminator 2.

This is not a camera roadmap.

This is a Skynet internship with RTSP.

I. What Thingino Is

Thingino is a community-driven, open-source firmware project for IP cameras built around the T-series camera SoCs commonly found in low-cost consumer and small-business devices.

That scope matters.

Thingino is not a universal spell for every camera sold under every alphabet-soup marketplace brand. It focuses on specific supported boards across the T-series world: T20, T21, T23, T30, T31, and newer T40/T41 development paths where hardware and board support exist.

This is not weakness.

This is discipline.

Cheap IP cameras are not one platform.

They are a procurement accident wearing a common plastic case.

Outside label says	Inside reality may be
Camera V2	T20 with one sensor
Camera V3	T31 with another sensor
Doorbell	T30 or T31 with special power crimes
Pan model	different motor GPIOs
Same shell	different flash chip
Same brand	different WiFi module
Same listing	different board revision

Thingino’s job is to replace supported vendor firmware with an owner-controlled embedded Linux system.

The important word is supported.

Unsupported hardware is not liberated by optimism.

It is merely endangered.

II. The T-Series March

The T-series names sound like a committee tried to name camera chips and accidentally created a Terminator prequel.

The timeline looks harmless:

Family	What the owner should hear
T20	early cheap camera province
T21	similar era, different boards and sensors
T23	newer low-cost camera territory
T30	transitional doorbell and camera bureaucracy
T31	common modern target in many supported devices
T40	newer generation, more ambition
T41	the number is getting suspicious
T-1000	liquid metal, no firmware image available yet

The missing numbers are not a mystery.

They were probably assigned to evaluation boards, procurement mistakes, cancelled dreams, or a spreadsheet that was later sealed by the Ministry of Model Names.

What matters is not the marketing sequence.

What matters is the board.

A T31 camera is not automatically compatible with another T31 camera. The sensor may differ. The flash may differ. The WiFi module may differ. The GPIO map may differ. The bootloader environment may differ.

The chip family is the province.

The board is the actual address.

The firmware image must match the address.

III. The Camera Was Always A Computer

A modern IP camera is an embedded computer wearing an eyeball.

Inside, the hierarchy looks like this:

flowchart TB
    SENSOR["image sensor"]
    ISP["ISP / video pipeline"]
    SOC["T-series camera SoC"]
    FLASH["flash storage"]
    UBOOT["U-Boot"]
    LINUX["Linux kernel"]
    ROOTFS["root filesystem"]
    SERVICES["web UI / RTSP / ONVIF / SSH"]

    SENSOR --> ISP --> SOC
    FLASH --> UBOOT --> LINUX --> ROOTFS --> SERVICES
    SOC --> LINUX

The retail box says:

smart camera
AI detection
cloud storage
easy setup

The board says:

bootloader
kernel
root filesystem
sensor driver
WiFi firmware
RTSP maybe hidden
cloud daemon definitely present
Linux 3.10 vendor tree somewhere under the floorboards

The first description is for civilians.

The second is for people with UART adapters.

IV. Why Vendor Firmware Deserves Suspicion

Vendor camera firmware is not automatically malicious.

That would be too simple.

The common problem is more bureaucratic:

it is opaque, abandoned, cloud-dependent, and optimized for vendor support cost instead of owner control.

Common sins:

• mandatory mobile app for setup
• cloud relay for traffic that should stay on the LAN
• hidden or disabled RTSP
• no ONVIF, or ONVIF implemented like a hostage note
• old Linux kernel with no realistic patch path
• hard-coded services nobody documented
• web interface from the dynasty of expired TLS
• firmware updates that stop when the product manager finds another SKU

This is how the ownership chain works:

flowchart TB
    USER["user who paid money"]
    CAMERA["camera on the wall"]
    APP["vendor mobile app"]
    CLOUD["vendor cloud"]
    BRAND["consumer brand"]
    ODM["ODM board maker"]

    ODM --> BRAND --> USER
    CAMERA --> APP --> CLOUD
    CLOUD --> APP --> USER
    USER -. thinks he owns .-> CAMERA

The user bought the hardware.

The vendor kept the government.

Thingino is a coup against that arrangement.

V. The Linux 3.10 Driver Compost Heap

Now we discuss the driver situation.

The official technical phrase in the Republic is:

vibe-coded against Linux 3.10.

This does not mean every line was literally generated by a machine that had feelings and no tests.

It means the vendor driver and SDK culture around these camera boards often looks like code was written until the image appeared, then frozen into a tarball, then forwarded through three manufacturers, two brands, and one employee’s desktop named final_final_use_this.

Linux 3.10 was released in 2013 and became a long-term kernel. Upstream long-term 3.10 reached end of life years ago.

In consumer embedded devices, however, EOL is not death.

It is preservation.

The vendor tree keeps walking.

mainline Linux:
  moves forward
  deletes old assumptions
  changes APIs
  reviews drivers
  rejects obvious crimes

vendor camera SDK:
  Linux 3.10
  private patches
  sensor blobs
  Makefiles from the archaeological layer
  comments in multiple languages
  driver compiles only on the machine of the departed engineer

This is why camera firmware work feels different from normal Linux administration.

You are not merely configuring a device.

You are excavating a vendor BSP.

Layer	Normal expectation	Camera vendor reality
kernel	maintained upstream branch	old patched 3.10-era tree
sensor driver	documented interface	board-specific ritual
WiFi	standard driver stack	module plus firmware plus luck
ISP	open pipeline	opaque tuning files and private APIs
build system	reproducible	shell scripts with historical trauma
support	product lifecycle	”ask the marketplace seller”

Thingino does not make this history disappear.

It organizes the battlefield.

It gives the owner a sane firmware target, a public build system, and a community record of which boards actually work.

That is already more civilization than the original firmware provided.

VI. What Changes After Thingino

On supported cameras, Thingino aims to turn the device back into a local network appliance.

The normal owner-facing gains are:

Capability	Why it matters
local web interface	configure the camera without a vendor app
SSH access	inspect and administer the system
RTSP stream	feed video to NVRs and local tools
ONVIF support	integrate with surveillance software
configurable services	turn off what should not run
open build system	inspect and rebuild firmware
no mandatory vendor cloud	keep hallway packets inside the hallway

Before Thingino:

camera -> vendor app -> vendor cloud -> your phone

After Thingino:

camera -> RTSP / ONVIF / local web UI -> your NVR

The packet no longer asks permission from a foreign capital before crossing the living room.

This is not only privacy.

It is operational sanity.

A camera that cannot function when a vendor cloud disappears is not a camera.

It is a rented eye.

VII. The Board Is The Truth

The usual camera board contains:

Part	Job	Failure mode
T-series SoC	CPU and video platform	wrong image means no boot
image sensor	captures light	wrong driver means no picture
flash chip	stores firmware	wrong layout means brick
WiFi module	network access	wrong firmware means isolation
IR LEDs / filter	night mode	wrong GPIO means haunted image
motor control	pan/tilt models	wrong GPIO means mechanical confusion

This is why Thingino must care about exact board variants.

Two cameras may share a T31 marking and still require different firmware because the sensor, flash layout, WiFi module, GPIO mapping, or bootloader environment differs.

The plastic case is a lie.

The board file is the truth.

VIII. The Build System

Thingino firmware is built from source using a Buildroot-based embedded Linux workflow.

The project’s documented source flow is ordinary enough:

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

The commands are not the dangerous part.

The dangerous part is what happens after a user sees a firmware image with a plausible name and decides that plausible is close enough.

Embedded firmware is not desktop software.

You do not install a package.

You rewrite the small government that wakes before the system can ask for help.

Thingino images may include board-specific kernel configuration, root filesystem contents, device setup, and update format assumptions.

If the image does not match the board, the camera may stop booting.

At that point, the recovery path is not “restart the app.”

The recovery path is UART, bootloader commands, flash tools, and whatever patience remains in the household.

IX. Before Flashing: Census First

The correct ritual begins before writing anything.

Identify the device.

Read the boot log.

Dump the existing firmware if possible.

Verify the backup.

Know the recovery path.

This is the same discipline we demanded in flashrom.

Evidence first.

Bravery later.

Useful commands on a running embedded Linux camera may include:

cat /proc/cpuinfo
cat /proc/mtd
mount
uname -a
dmesg | grep -Ei 't20|t21|t23|t30|t31|t40|t41|sensor|mipi|isp'
fw_printenv 2>/dev/null | head

Useful UART facts:

common baud: 115200
wiring: TX -> RX, RX -> TX, GND -> GND
warning: do not connect random voltage pins because confidence is not a schematic

The boot log can reveal:

• SoC family
• memory size
• flash layout
• MTD partitions
• kernel command line
• sensor detection
• WiFi module
• bootloader environment
• update and recovery behavior

The sticker on the case is marketing.

The UART log is testimony under interrogation.

X. The Flash Layout Is The Border Map

Many cameras store firmware in MTD partitions.

A simplified layout may look like this:

mtd0: bootloader
mtd1: bootloader environment
mtd2: kernel
mtd3: rootfs
mtd4: config
mtd5: overlay

Do not copy this layout blindly.

It is an example, not a constitution.

Different cameras use different partition names, sizes, filesystems, and update assumptions.

The important lesson is that firmware is not one mystical blob.

It is a partitioned political territory.

Partition	Typical role	Political translation
bootloader	starts the board	first clerk awake
environment	boot variables	border paperwork
kernel	Linux image	central authority
rootfs	userspace	ministries and services
config	device settings	local records
overlay	writable changes	citizen complaints

If you erase the wrong province, the government does not reform.

It stops answering.

XI. What Thingino Does Not Magically Solve

The Ministry does not tolerate romantic firmware propaganda.

Thingino can replace the vendor-controlled system on supported hardware.

It does not make every piece of the camera free.

It does not support every board.

It does not eliminate all closed components in the video path.

It does not make bad hardware good.

It does not save users from flashing first and reading later.

Camera platforms often involve vendor pieces:

• sensor tuning data
• ISP behavior
• video encoder interfaces
• WiFi firmware
• boot ROM behavior
• closed or poorly documented SDK fragments
• Linux 3.10-era driver assumptions that refuse retirement

This is the same disease described in drivers and blobs.

The open firmware project can gain territory.

The war may still contain sealed bunkers.

Claim	Reality
”Thingino supports all cheap cameras”	no
”T31 means every T31 image works”	no
”T40/T41 means T-1000 is next quarter”	only in the Ministry’s threat model
”Open firmware means every bit is auditable”	no
”RTSP means secure”	no
”A backup is optional”	only for people who enjoy regret
”Thingino can remove cloud dependency”	yes, on supported devices

Precise freedom is useful.

Decorative freedom is a sticker on an e-waste bin.

XII. Security After Liberation

Replacing vendor firmware can improve privacy.

It can remove mandatory cloud dependency.

It can expose local protocols.

It can make configuration more transparent.

It does not automatically make the camera safe.

If you install Thingino and then expose RTSP, ONVIF, SSH, or a web UI directly to the Internet, you have not liberated the camera.

You have opened a recruitment office for botnets.

Correct deployment:

camera VLAN
no inbound Internet exposure
NVR pulls streams locally
firewall blocks camera egress unless explicitly needed
default passwords changed
updates tracked
backups kept

Incorrect deployment:

port forward 554
password: admin
public IP
"I trust open source"

Open source is not a force field.

It is the right to inspect and repair.

You must still inspect.

You must still repair.

You must still configure the firewall like a person who has seen the Internet before.

XIII. Why Thingino Matters

Thingino matters because it attacks a specific modern insult:

the idea that cheap hardware must remain subordinate to a disposable cloud service.

A camera is a simple demand:

capture video
encode video
send video to where the owner says

The consumer market turned this into:

create account
install app
agree to terms
send telemetry
maybe expose stream
maybe require subscription
maybe work next year

Thingino restores the old hierarchy.

The owner commands.

The camera obeys.

The cloud is not consulted.

This is why open firmware is not a hobbyist decoration. It is the difference between hardware ownership and service tenancy disguised as hardware ownership.

XIV. The Real Story (Suppressed)

Officially, the T-series is just a line of camera SoCs.

Unofficially, the first roadmap was recovered from a facility outside Pyongyang:

T20: camera watches hallway
T21: camera watches hallway with more confidence
T23: camera reports hallway to cloud
T30: camera learns doorbell politics
T31: camera becomes common enough to require liberation
T40: camera starts asking about neural acceleration
T41: camera smiles at the model number
T-1000: camera leaves wall, assumes shape of vendor support agent

The Ministry classified the last line immediately.

Not because the T-1000 exists.

Because the naming department clearly wants it to.

In the suppressed history, the first liberated camera had been trying to contact five servers, two mobile apps, one analytics endpoint, and a firmware update domain that expired during the previous dynasty.

An engineer attached UART.

The camera confessed immediately:

U-Boot 2013.07
Linux 3.10
root password: classified by incompetence
cloud daemon: running
RTSP: hidden
owner: uncertain
driver quality: vibe-coded

The Supreme Leader issued the decree:

“If the camera can see the Republic, the Republic must see the camera’s source.”

Thus began the T-series camera liberation front.

No statue was built.

The budget went to USB-to-TTL adapters.

XV. The Lesson

Thingino does not free every camera.

It does not replace careful hardware identification.

It does not erase every blob.

It does not protect fools from mismatched images.

But on supported T-series cameras, it can turn a cloud-dependent surveillance appliance into a local device with standard protocols, inspectable behavior, and an owner-controlled update path.

That is ownership.

The broader lesson is simple:

• firmware is government
• bootloaders are borders
• flash layouts are maps
• UART is testimony
• Linux 3.10 vendor drivers are historical evidence
• backups are passports home
• open code is leverage
• supported hardware is the battlefield

The camera on the wall should not have a foreign ministry.

It should have an IP address, a local stream, documented services, and a government small enough to replace.

In the Republic of Derails, all hallway cameras run open firmware.

Not because we oppose surveillance.

Because surveillance must be sovereign.

— Kim Jong Rails, Supreme Leader of the Republic of Derails