XIP with Linux: A New Spin on Embedded Architecture (.PDF Download)

Real-time operating systems (RTOS) and Linux each bring their own advantages for embedded-systems designers. With an RTOS, designers can build deterministic multi-threaded applications with low memory requirements and fast boot times. However, they’re bound by the feature set and API provided by the RTOS vendor, and the middleware is often an extra cost and may not be fully integrated into the OS. The Linux operating system, by contrast, provides a standard, open-source platform with extensive driver and middleware support for a variety of components, including communication devices like Wi-Fi modules.

Despite these benefits, Linux brings with it a hefty set of hardware requirements. For instance, it requires a microprocessor (MPU) with memory management unit (MMU) plus a large amount of external memory—typically DDRx SDRAM—that requires high-speed signals to be routed on a multi-layer PCB. Boot-up times in standard Linux implementations are much longer than in RTOS-based systems, too. All of this overhead can push microcontroller (MCU) and MPU designers to avoid Linux altogether. In so doing, they unfortunately miss out on the many advantages that Linux brings.

Enter Execute-in-Place Linux

XIP, or Execute in-Place, Linux is a disruptive technology that approaches embedded-system architecture from a different angle. It allows code to be executed directly from external serial flash, which allows for significant optimization of the memory footprint. This is akin to how an MCU runs code out of on-chip flash, only with MPU-level performance. It overcomes many long-standing design challenges, while simplifying PCB design and shrinking the bill-of-materials (BOM) cost.

Traditional Linux Kernel Architecture

Embedded Linux systems have been constrained to using flash memory for code storage and DRAM for code execution and data buffering. With this type of architecture, application code is copied from flash to DRAM at boot-up before it’s executed, which prolongs the boot process.

While application code can be read out of flash in pieces as needed, the kernel code must stay in RAM indefinitely during the operation of the program. That is, it can’t be paged in or out. Likewise, driver modules loaded at run-time must also be copied to RAM and remain thereafter. To compound matters, the memory bandwidth has to be split between code and data, which creates a performance bottleneck that can potentially cause deleterious visual artifacts like flickering and lag time on touchscreen displays.