Engineering blog
Notes from the bench.
Root causes, design decisions and checklists from real bring-ups, driver work and fleet platforms: kernel internals, ARM64 boards, buses, secure boot, OTA and the cloud side of connected devices. Written by the engineers who did the work.
-
Bringing an OS up on Raspberry Pi 5: what the RP1, PCIe and the GIC demand from your kernel
Notes from an ARM64 kernel bring-up on the Raspberry Pi 5: almost every peripheral sits behind a PCIe link, DMA is not coherent with the CPU caches, MSIs go through the GIC ITS, secondary…
-
ARM64 SMP bugs are memory-ordering bugs until proven otherwise
Code that ran for years on x86 falls over one boot in fifty on a four-core Cortex-A76. The six patterns behind almost every such failure we have chased, the barriers that fix them, and…
-
Where the packets per second go: SDIO Wi-Fi throughput on a Broadcom CYW43455
A Wi-Fi link that tops out around one megabit with an idle CPU is not a radio problem. Six host-side causes, from missing receive glomming to a byte-mode CMD53 bug, and how to count…
-
Designing over-the-air updates that survive power loss, bad networks and bad releases
An OTA system is judged on its worst day: power cut mid-write, a release that bricks half the fleet, a network that drops at 98 percent. The device-side and server-side design that makes those…
-
Debugging a kernel you cannot attach a debugger to
Silent resets, hangs with no console output, faults that only appear on the fourth core: the toolkit we reach for when JTAG is not an option. QEMU models with debugger stubs, reset-surviving crash rings,…
-
Porting device drivers between Linux and Windows: what actually changes
The hardware does not care which kernel is driving it. Everything else does: request models, interrupt contexts, IRQL versus atomic context, DMA mapping, power management and how a driver reaches users. A side-by-side map…
Facing one of these problems?
The engineers who write these notes are the ones you would work with.