Embedded Systems
Linux Kernel
RTOS
Edge Computing
Most people interact with Linux dozens of times a day without knowing it — through their routers, smart TVs, industrial controllers, medical devices, and in-vehicle infotainment systems. Embedded Linux powers the edge computing revolution, and getting it right requires a depth of expertise that’s rare in India’s technology landscape.
DeepTechComputing has built embedded Linux systems for Comcast’s set-top box platform and mission-critical defence applications for Thales. Here’s what we’ve learned.
What makes embedded Linux different
Desktop and server Linux distributions are designed for general-purpose computing: large storage, significant RAM, internet connectivity, a keyboard and screen. Embedded Linux operates under fundamentally different constraints:
- Tight memory budgets — sometimes as little as 64MB RAM
- Limited or no persistent storage — systems may boot from flash
- Real-time or near-real-time response requirements
- Long product lifetimes — 10 to 20 years of operation without updates
- No general-purpose I/O — every interface is carefully chosen and controlled
These constraints require a fundamentally different approach to kernel configuration, BSP (board support package) development, and system integration.
The build system: Yocto vs Buildroot
Two build systems dominate embedded Linux development: Yocto Project and Buildroot.
Buildroot excels for simpler systems where you want a minimal, reproducible image built quickly. It has a shallow learning curve and produces small, clean root filesystems. For products with limited scope and a small team, Buildroot is often the right choice.
Yocto is the industrial-grade solution. It’s a complete framework for building custom Linux distributions, with sophisticated layer management, recipe inheritance, and the ability to generate SDK toolchains for application developers. It’s more complex, but the investment pays off for larger teams and products that need to support multiple hardware variants.
At DeepTechComputing, we’ve deployed both in production. Our recommendation depends on the project’s scope, team size, and expected hardware variability.
A well-configured embedded Linux system should boot in under two seconds and occupy less than 50MB of flash. If you’re not hitting those targets, your configuration needs work.
Real-time Linux: PREEMPT_RT and beyond
Standard Linux is not a real-time operating system. Its scheduler optimises for throughput, not latency. For applications requiring deterministic response times — industrial motion control, audio processing, robotics — this matters enormously.
The PREEMPT_RT patch set converts Linux into a fully preemptible kernel, dramatically reducing worst-case interrupt latency. Since kernel 6.12, much of PREEMPT_RT has been merged into the mainline kernel, making real-time Linux dramatically more accessible.
For applications with stricter requirements, a dual-kernel approach (Xenomai or RTAI) or a dedicated RTOS (FreeRTOS, Zephyr) running alongside Linux on a heterogeneous processor provides hard real-time guarantees.
Security hardening for embedded systems
Embedded systems are increasingly networked and increasingly targeted. The security practices that protect server infrastructure apply at the edge too, often with greater urgency because devices are deployed in physically accessible locations.
Essential hardening measures:
- Disable all unused kernel modules and network services
- Implement secure boot with verified kernel and rootfs signatures
- Use read-only root filesystems with separate writable partitions for data
- Apply AppArmor or SELinux policies to constrain process permissions
- Plan for over-the-air updates with A/B partition schemes from day one
The long-term maintenance problem
Perhaps the biggest challenge in embedded Linux development is maintenance. Products ship and spend years in the field. Security vulnerabilities are discovered. Customers want new features. Hardware components are discontinued.The teams that manage this best invest early in: a stable LTS kernel base (not the latest shiny version), rigorous automated testing on hardware, and clear policies for backporting security fixes versus full kernel upgrades.
