Hardware Architecture Support
Relevant source files
The following files were used as context for generating this wiki page:
The Zephyr RTOS is designed as a highly scalable and modular operating system supporting a wide variety of hardware architectures and boards. It is optimized for resource-constrained devices ranging from simple environmental sensors to sophisticated IoT gateways. The architecture support is built into the core of the kernel, allowing for consistent API usage across different CPU families while leveraging hardware-specific features like Memory Protection Units (MPU) and floating-point units.
The hardware support model is structured to allow the reuse of drivers across platforms with common IP blocks through a consistent device model. This cross-architecture capability is a distinguishing feature of the project, enabling developers to target multiple instruction set architectures (ISAs) including ARM, Intel x86, RISC-V, and others using the same application code.
Supported Architectures
Zephyr supports an extensive list of architectures, ranging from 8-bit to 64-bit systems. This broad support ensures that the OS can be deployed on a vast spectrum of microcontrollers and microprocessors.
Core Architecture Families
The following architectures are natively supported by the Zephyr kernel:
- ARM: Support includes Cortex-M (v6-M, v7-M, v8-M), Cortex-A (v7-A, v8-A, 32- and 64-bit), and Cortex-R (v7-R, v8-R, 32- and 64-bit).
- ARC: Support for ARCv2 (EM and HS) and ARCv3 (HS6X).
- Intel x86: Support for both 32-bit and 64-bit configurations.
- RISC-V: Support for both 32-bit and 64-bit implementations.
- Tensilica Xtensa: Used in various high-performance DSPs and SoCs.
- MIPS: MIPS32 Release 1 specification.
- Others: SPARC V8 and Renesas RX.
Sources: doc/introduction/index.rst:7-19, README.rst:31-35
Hardware Support Tiers
Hardware support is categorized into four tiers based on the level of commitment, testing, and maintenance provided by the community and the release engineering team.
| Tier | Name | Description | Testing Commitment |
|---|---|---|---|
| Tier 0 | Emulation Platforms | Built and run in CI; runtime failures block Pull Requests. | Full CI support; highest priority bugs. |
| Tier 1 | Supported Platforms | Commitment from specific teams to run tests regularly. | Tested with "Zephyr compatibility test suite". |
| Tier 2 | Community Platforms | Upstream implementation available; no commitment to testing. | Dedicated maintainer required for review. |
| Tier 3 | Deprecated/Unsupported | No owner or unresponsive owner; may be removed from upstream. | None. |
Sources: doc/project/release_process.rst:365-400
Architecture-Specific Features
The Zephyr kernel leverages specific hardware capabilities to provide advanced services like memory protection and power management.
Memory and Execution Protection
Zephyr implements configurable, architecture-specific protections to ensure system stability and security. These features are primarily supported on x86, ARC, and ARM architectures.
- Stack-overflow Protection: Implemented using guard regions or hardware stack limit registers.
- Thread Isolation: Partitioning system resources (memory, peripheral address space) and assigning them to individual threads or groups.
- Privileged/Unprivileged Environments: Splitting the system into execution levels to prevent unprivileged threads from accessing critical kernel resources.
Sources: doc/introduction/index.rst:69-76, doc/security/security-overview.rst:58-62, doc/security/security-overview.rst:114-123
Architecture Evolution Flow
The following diagram illustrates how architectural changes and support flow through the project, from initial development to a stabilized release.
The architecture support evolves through a time-based release cycle, moving from a feature-rich development phase to a stabilization phase where only bug fixes and documentation are permitted.
Sources: doc/project/release_process.rst:19-55, doc/project/release_process.rst:312-320
Hardware Description and Configuration
Zephyr uses standardized mechanisms to describe and configure hardware, ensuring that the kernel can be adapted to different boards without hardcoding values.
Devicetree (DT)
Devicetree is used to describe the hardware topology. Information from the devicetree is processed at compile-time to create the application image, which reduces code size and improves performance for resource-limited systems.
Sources: doc/introduction/index.rst:86-88, doc/releases/release-notes-1.7.rst:16-20
Kconfig
The Kconfig system allows for a modular approach to architecture support. Functionalities within architecture-specific components can be enabled or disabled based on application needs. This is critical for safety, where certain features (like dynamic memory management) may need to be disabled to meet certification requirements.
Sources: doc/safety/safety_overview.rst:155-160, doc/security/security-overview.rst:183-188
Platform Porting and Simulation
Zephyr provides tools to facilitate the bring-up of new hardware and the testing of architecture-independent code.
Native Port and Emulation
To aid in development, Zephyr can run on host operating systems or in emulated environments.
- Native Sim (native_sim): Allows running Zephyr as a native Linux, macOS, or Windows application. This is useful for testing subsystems and networking without physical hardware.
- QEMU: Used for emulating x86 and ARM Cortex-M3 architectures. It is included with the Zephyr SDK and used extensively in CI.
Sources: doc/develop/beyond-GSG.rst:161-175, doc/develop/beyond-GSG.rst:200-210
Device Driver Model
The hardware architecture support is underpinned by a consistent device driver model. This model handles the initialization and configuration of drivers across different platforms, allowing the same IP block (e.g., a specific UART or I2C controller) to use the same driver regardless of the CPU architecture it is attached to.
The diagram shows how the Zephyr Device Driver Model abstracts hardware-specific implementation (shims) from the generic peripheral APIs used by applications.
Sources: doc/introduction/index.rst:81-85, doc/security/security-overview.rst:142-150
Conclusion
Hardware Architecture Support in Zephyr is characterized by its wide breadth of instruction set support and a rigorous tier-based maintenance system. By utilizing Devicetree for hardware description and Kconfig for modularity, the project provides a flexible framework that balances high-performance features with the strict requirements of safety and security certifications. This architecture allows the same codebase to scale from simple microcontrollers to complex multi-core processors.