Why I Started EdgeLog

Every hot AI technology is born in the cloud. LLMs, RAG pipelines, zero-trust security, real-time ML inference. They all debut on servers with plenty of RAM and a network that stays up. Then someone asks: “can this run on the device?”

Most documentation stops right there.

The Question Nobody’s Answering

What happens when you drop a quantized LLM onto an edge device with 512MB of RAM? How do you fit zero-trust security onto a Linux SBC that has to boot in under two seconds? Can Zephyr’s Kenning runtime really replace your bare-metal inference pipeline? Does RAG make any sense when the whole knowledge base sits on a 4GB eMMC? Can you get a WASM runtime to do anything useful on a Cortex-A53 with a 2W power budget?

These are real problems, not thought experiments. Anyone pushing new tech onto constrained hardware runs into them. The difference is that nobody writes down what they figured out.

Existing embedded blogs cover the fundamentals well. Interrupt for firmware engineering, Shawn Hymel for MCU-class edge AI. But the frontier moves fast, and the distance between “this technology exists” and “here’s what happened when I put it on real hardware” grows every month.

What EdgeLog Is

EdgeLog is a research log. I put emerging tech onto embedded and edge devices, see what actually runs, then write up the experience.

Every post answers one question: what happens when this meets real hardware constraints?

The topics track wherever the frontier goes. Here’s what I’m digging into right now:

On-Device Intelligence. I put a Q4_K_M-quantized Qwen2.5-1.5B on a Raspberry Pi 5 (8GB) and ran llama.cpp. It does about 6 tokens/sec. Slow. But it’s enough for local command parsing and log summarization without a cloud API call. The real questions start after “it runs”: memory bandwidth bottlenecks (the Pi’s 50 GB/s LPDDR4X vs. a datacenter GPU’s 2 TB/s HBM), swap pressure under concurrent inference, RAG with SQLite + vector extensions on eMMC, on-device fine-tuning with LoRA adapters small enough to cram into flash, and hybrid setups where the edge device triages what’s worth shipping to the cloud.

Next-Gen Frameworks & Runtimes. Zephyr 4.x supports 900+ boards, with Kenning runtime, LiteRT, and IREE handling ML inference. As of December 2025, Rust has shed the experimental label in the Linux kernel, and the DRM subsystem plans to require it for new drivers. WASM runtimes like WasmEdge and Ocre (Linux Foundation, 128KB footprint on Zephyr) are moving past experiments into production. Hybrid OS setups (Zephyr for real-time control, Linux for networking and UI) are quietly becoming the default on complex edge devices. I want to see which of these survive contact with real deadlines and real power budgets.

AI-Powered Embedded Development. I use Claude every day for Yocto recipe debugging and device tree review. It’s genuinely good at catching missing compatible strings and pointing out where RDEPENDS needs a fix. It’s genuinely bad at register-level driver code. It’ll produce plausible C that compiles but writes to the wrong offset because it hallucinated the register map. I want to document where that line falls for different embedded tasks, with concrete pass/fail examples. (I started with spec-driven TDD and context engineering for sensor drivers.)

Edge Security, Privacy & CRA Compliance. The EU Cyber Resilience Act reporting obligations kick in on September 11, 2026. If you sell embedded Linux products in the EU, you have to report actively exploited vulnerabilities to ENISA within 24 hours. Full compliance is due by December 2027. Most of the Yocto-based products I’ve seen have no automated CVE scanning in their build pipeline. An SBOM that ENISA would accept? Not even close. Zephyr already generates Build SBOMs automatically. Yocto is still catching up. I’m working out what a realistic compliance setup looks like for meta-security-based builds, and what secure boot and anti-rollback OTA actually demand on custom hardware.

This list will keep changing. That’s the whole idea.

How I’ll Write

Experiment first, write second. Every post starts from real hardware, real code, real measurements. If I haven’t built it, flashed it, and watched it run (or crash), I’ll say so. This post is the only one on the blog without a terminal screenshot. Everything after it ships with evidence.

Honest about what doesn’t work. Half the value lives in the dead ends. A technology that looks great in the README but falls apart on a memory-tight device is exactly the kind of thing worth writing down. I burned two weeks trying to get WASM-based ML inference running on a Cortex-A53 board, then gave up and went back to native C. That’s a post too.

Respect your time. No filler, no hype, no buzzword padding. Code you can run, numbers you can compare, trade-offs you can weigh against your own project. That’s it.

What Comes Next

The first experiments are already running.

If you’re the kind of engineer whose eyes light up when someone asks “can we run this on the device?”, this blog is for you. Subscribe via RSS.

The cloud had its decade. Now try fitting it into 256KB.