Embedded platform discussions often use different words as if they meant the same thing.
“This project uses ARM.” “This chip is RISC-V.” “This core supports Linux.” “This board has an MMU.” “Interrupts are different on this architecture.” “This toolchain is incompatible.” Some of these statements are true, and some are only half true. The problem is that they often collapse ISA, CPU core, privileged architecture, SoC, board, and software platform into one layer.
Once those layers are mixed, engineering judgment suffers. A binary may fail because the ISA is wrong, or because the ABI is wrong. An interrupt may not arrive because exception entry is wrong, or because the interrupt controller is not configured. A system may fail to boot Linux not because “RISC-V does not support it,” but because the SoC, memory, MMU, firmware, kernel, and user-space support do not line up.
The safer first model is this: the ISA defines instructions and registers; the privileged architecture defines exceptions, permissions, and address translation; the microarchitecture implements them; the SoC integrates CPUs and peripherals; the board provides real hardware wiring; and the software platform turns all of that into a runnable system through firmware, OS, toolchain, and ABI.
ISA
-> privileged architecture / profiles / extensions
-> CPU core / microarchitecture
-> SoC
-> board
-> firmware / OS / toolchain / ABI
When comparing ARM and RISC-V, first locate which layer is actually different.
ISA Means What Instructions Can Execute
ISA stands for instruction set architecture. It defines the execution interface visible to software, such as:
- instruction encoding
- general-purpose registers
- arithmetic, branch, load/store, and atomic instructions
- basic exception or trap entry rules
- basic memory-access semantics
For a compiler, the ISA determines which machine code it can generate. For a binary, an ISA mismatch often means the CPU simply cannot execute the instructions.
That is why an x86 executable cannot run directly on ARM Linux, an AArch64 program cannot be dropped into a 32-bit ARM user space, and an RV64 program cannot run on a system that only supports RV32.
But ISA is not the whole platform. Knowing that something is “ARM” or “RISC-V” tells only part of the machine-code story. It does not determine the boot method, interrupt controller, peripheral addresses, cache hierarchy, Linux support, or board behavior.
Privileged Architecture Defines Controlled Entry and Permissions
Applications, kernels, exception handlers, virtualization layers, and secure firmware do not necessarily have the same permissions. Privileged architecture describes those boundaries.
It usually defines:
- which privilege levels or exception levels exist
- how exceptions, traps, and system calls enter
- where exception causes and return addresses are stored
- which control registers can be accessed by which level
- how MMU or MPU configuration works
- how page tables, address translation, and access permissions are represented
- architecture-side interrupt entry and interrupt-enable rules
On ARM, this may involve Cortex-M Thread/Handler mode, or Cortex-A/AArch64 Exception Levels. On RISC-V, this may involve U/S/M modes and boundaries related to supervisor mode, machine firmware, and SBI.
System calls, interrupts, exception return, page tables, user/kernel separation, virtualization, and secure boot belong more to this layer than to “a few more instructions.”
So when someone says an architecture supports Linux, the real requirement is a set of conditions: suitable privilege modes, timer, interrupts, MMU, atomic operations, memory model, boot firmware, kernel port, and user-space ABI. The ISA name alone is not enough.
Profiles and Extensions Decide Which Capabilities Exist
ARM and RISC-V are not single shapes.
In ARM systems, Cortex-M, Cortex-R, and Cortex-A target very different use cases. Cortex-M is common in MCUs and RTOS devices, with startup, interrupt, and memory-protection models designed for microcontrollers. Cortex-A is common in Linux-capable application processors, often with MMU, complex caches, multicore systems, and more complete privilege layering.
RISC-V is often described as a base ISA plus extensions. Beyond the base integer instructions, a CPU may or may not include multiplication/division, atomics, floating point, compressed instructions, vector extensions, and more. A chip labeled RISC-V does not automatically include every extension, nor does it imply the same privileged architecture, MMU, interrupt controller, or Linux support.
This affects practical decisions:
- whether the compiler may emit a specific extension instruction
- whether the kernel depends on atomic instructions or an MMU
- whether the floating-point ABI matches hardware capability
- whether a user-space binary can execute on the target CPU
- whether an RTOS porting layer can be reused
After seeing an architecture name, continue checking profile, extensions, XLEN, privileged version, ABI, and operating-system support.
Microarchitecture Decides How the Same ISA Runs
Microarchitecture is the concrete implementation of an ISA.
The same ISA can be implemented with different pipelines, cache hierarchies, branch predictors, out-of-order execution, TLBs, prefetchers, and interconnects. These usually do not change whether a program can execute, but they strongly affect performance, real-time behavior, power, and some visibility problems.
For example:
- different ARM Cortex cores can have very different caches, pipelines, and interrupt latency
- different RISC-V vendor cores can differ in performance counters, cache maintenance, and extension implementation
- the same C code can run with different response latency, memory latency, and power consumption
- multicore, cache, and out-of-order execution make memory barriers and synchronization more important
Microarchitecture is not usually the direct interface an application depends on, but drivers, real-time systems, performance tuning, and low-power debugging often touch it.
SoC Means What Hardware Exists Around the CPU
An SoC is not the CPU core itself. It integrates CPU cores with many system blocks on one chip.
Common SoC contents include:
- interrupt controllers
- timers and watchdogs
- SRAM, DRAM controllers, and bus fabrics
- clock and reset controllers
- UART, SPI, I2C, USB, Ethernet, PCIe, and other peripherals
- DMA controllers
- security blocks, crypto engines, efuse, and OTP
- boot ROM and boot-media selection logic
Many “architecture problems” actually happen at the SoC layer. Interrupt numbers, peripheral register addresses, clock gates, reset lines, DMA channels, pinmux, boot straps, and boot-media selection are not defined by the ISA.
That is why two Cortex-A chips can have completely different Device Trees, drivers, boot logs, and board bring-up paths. Two RISC-V SoCs can also use different interrupt controllers, timers, cache-maintenance mechanisms, and boot firmware.
Board Means How the Chip Meets the Real World
The board adds another layer of real constraints above the SoC.
With the same SoC, another board may change:
- DDR model, capacity, and routing
- flash, eMMC, SD, or SPI NOR connection
- crystal frequency
- power sequencing
- debug and serial-port wiring
- Ethernet PHY, Wi-Fi module, sensors, and interface pins
- boot-mode pins, DIP switches, or fuse settings
Board-level problems should not be blamed simply on ARM or RISC-V. DDR initialization failure, missing serial output, wrong boot-media selection, peripheral probe failure, and incorrect Device Tree descriptions often come from board wiring, SoC configuration, and bootloader behavior together.
Architecture tells you how the CPU executes code. It does not tell you which pin this board connects to the UART, nor does it know the DDR timing parameters.
Software Platform Turns Hardware Into a Runnable System
Above the hardware layers sit firmware, operating systems, and toolchains.
This layer includes:
- boot ROM, SPL, U-Boot, TF-A, OpenSBI, and other firmware
- RTOS or Linux kernel
- Device Tree, ACPI, or board descriptions
- C library, dynamic linker, and rootfs
- cross-compilation toolchain
- ABI, calling convention, and floating-point convention
Whether a user program can run is not determined only by whether the CPU supports the instruction set. ELF machine, ABI, dynamic-linker path, C library version, kernel support, and rootfs must also match.
Whether Linux can boot is also not only a CPU-core issue. Kernel entry contract, boot arguments, Device Tree, timer, interrupts, console, rootfs, and drivers all need to line up.
How ARM and RISC-V Should Be Compared
Comparing ARM and RISC-V only as “commercial licensing” versus “open ISA” is not very useful for embedded engineering.
A more useful comparison asks by layer:
- ISA: is the target AArch32, AArch64, Thumb, RV32, or RV64? Which extensions are required?
- privileged architecture: how are exception levels, traps, system calls, page tables, and interrupt entry organized?
- profile/extensions: is the target an MCU, real-time controller, application processor, or Linux user-space platform?
- SoC: which interrupt controller, timer, DMA, clock, reset, and peripherals are used?
- boot firmware: what are the contracts from boot ROM to bootloader to kernel?
- ABI: do the toolchain triple, floating-point ABI, dynamic linker, and rootfs match?
- OS support: how mature are the RTOS port, Linux kernel, drivers, and user-space ecosystem?
This avoids two common mistakes: treating one chip’s behavior as the whole architecture, and mistaking architecture-level differences for board, driver, or toolchain issues.
Debugging Starts by Asking Which Layer
When something fails, split it by layer first:
- illegal instruction or
Exec format error: check ISA, ELF machine, XLEN, extensions, and ABI - system-call, exception-return, or user-permission problem: check privileged architecture and OS boundaries
- interrupt does not arrive: check CPU exception entry, interrupt controller, SoC configuration, and OS interrupt framework
- peripheral does not work: check SoC registers, clock/reset, pinmux, Device Tree, and driver
- no boot output: check boot ROM, boot media, link address, serial configuration, DDR, and bootloader
- DMA data is stale: check address type, cache attributes, DMA API, SoC coherency, and driver synchronization
- program builds but does not run: check ABI, dynamic linker, C library, rootfs, and kernel support
“ARM or RISC-V” is only the entry question, not the final answer. What helps debugging is putting the problem back into the right layer.
Once these layers are clear, later discussions about reset entry, interrupt paths, MMU/cache, or ABI can stay precise instead of mixing reference-manual terms with board-specific behavior.