Can Cortex-M Microcontrollers Run Linux?

What are the differences between microcontrollers, Cortex-M, and Linux in embedded systems?

Many friends may have similar questions. Below, we will discuss the relevant content regarding Cortex-M, Arm, and Linux.

To answer this question, let’s first look at GPT’s response:

Figure 1

The architecture of Arm processors defines the instruction set (ISA) and the model of processors based on this architecture. The Arm instruction set has evolved from Armv1 to today’s Armv9, with each modification to the architecture adding practical technologies.

Figure 2

Before Armv6, its core instruction set architecture was a single style. However, starting from Armv7, its instruction set architecture became three styles, namely the well-known Cortex-M, Cortex-R, and Cortex-A, or Armv7-A, Armv7-R, and Armv7-M.

●Cortex-M: primarily refers to microcontrollers;

●Cortex-R: primarily refers to real-time processors;

●Cortex-A: primarily refers to application processors;

For more information, please refer to the article: “Relationship between STM32, Cortex-M3, and Armv8-M”.

It is worth noting that processors under Cortex-M do not have a Memory Management Unit (MMU).

MMU: Memory Management Unit.

The Memory Management Unit is mainly responsible for mapping from virtual addresses to physical addresses and checking memory access permissions at the hardware level.

In multi-user and multi-process operating systems like Linux, the MMU allows each user process to have an independent address space to prevent memory overflow.

Figure 3 The Role of MMU

MCUs have an address set, referred to as the virtual address range. Taking Cortex-M32 as an example, the virtual address range is 0~0xFFFFFFFF (4G address space).

When this controller addresses 256M of memory, its available address range is limited to 0~0x0FFFFFFF (256M).

1. In processors without memory management, virtual addresses are directly sent to the memory bus to read or write the physical memory at that address.

For further reading: “The Preemption Mechanism of Non-MMU Preemptive Operating Systems”.

2. In controllers with memory management, virtual addresses are first sent to the MMU, mapped to physical addresses, and then sent to the memory bus.

Figure 4 Memory Management Mechanism

Note: The above figure only reflects the mapping mechanism of memory management; other discussions are not included.

The main function of MMU virtual memory management is to provide each process with an independent address space.

The same virtual address in different processes is mapped by the MMU to different physical addresses, ensuring that any address accessed in a process cannot access data from another process. This prevents illegal memory access due to erroneous instructions or malicious code from unexpectedly overwriting data from other processes, thus ensuring the stability of the entire system.

On the other hand, each process believes it exclusively occupies the entire virtual address space, making the implementation of linkers and loaders easier without worrying about address range conflicts among processes.

Operating systems are generally divided into real-time operating systems and non-real-time operating systems.

1. Real-time operating systems are mostly single-process, multi-threaded (multi-task) and do not involve address space allocation between threads, so they do not require the use of MMUs, such as ucos, FreeRTOS, RT-Thread, etc.

2. Linux systems belong to non-real-time operating systems, with multi-process being a main feature. Please refer to the article: “Is Linux a Real-Time System or a Time-Sharing Operating System?”

Taking Ubuntu as an example, open a shell and check the address range of the bash process as shown in Figure 5, with an address range of

0x0000000000400000~0xffffffffff600000.

Figure 5 Address of bash in shell 1

We open another shell to check the address range of the bash process in that shell, as shown in Figure 6. It is not difficult to see that the address ranges of the two different bash processes are exactly the same. In fact, when the operating system or user forks a process using fork(), there is no need to consider the physical memory address allocation; this work is handled by the microcontroller’s memory management unit (MMU).

Figure 6 Address of bash in shell 2

Since multi-process relies on the memory management unit, is it possible to run embedded Linux with just one process? Definitely not! Even if the user does nothing after booting, the visible system must have dozens to hundreds of processes running, as shown in Figure 7.

Figure 7 Process Tree

From the above description, we can see that the Linux operating system has a strong dependence on the MMU (Memory Management Unit). If Linux were to run on a CPU without a memory management unit, the entire system would likely only remain at the Uboot stage.

Since Arm’s Cortex-M processors do not have a memory management unit, it is generally not recommended to run the Linux operating system.

Of course, nothing is absolute. If you rewrite the Linux kernel and pair it with a sufficiently large memory chip, it is theoretically possible to eliminate the MMU.

However, is such a workload really worth it? In fact, the MMU was created to solve the increasingly complex memory management of operating systems.

Press and hold to recognize the QR code to add Miss Ji Shu on WeChat (aijishu20) and join the Arm Technology Academy reader group.