1. Positioning of Cortex-M

The architecture of the processor defines the instruction set (ISA) and the programmer model of the processor based on this architecture. In simple terms, application software under the same ARM architecture is compatible. From ARMv1 to ARMv8, every modification of the architecture adds practical technology.

In the ARMv7 version, the core architecture changed from a single style to three styles for the first time. The Cortex-M series belongs to one of the styles under the ARMv7 architecture: style M. The processors included in style M are Cortex-M0, Cortex-M1, Cortex-M3, Cortex-M4, and Cortex-M7. These processors are often used in low-cost, low-power, and highly reliable embedded real-time systems. They can be used for “bare chip” development and can run real-time operating systems such as us/os-ll, VxWorks, and AWorks (developed by ZLG).

Figure 1 Cortex series under ARMv7

• Style A: High-performance processor-level platform, performance comparable to computers.

• Style R: Positioned for high-end embedded systems, high reliability, and high timeliness.

• Style M: Used for deeply embedded, customized embedded systems.

It is worth noting that processors under Cortex-M do not have a memory management unit (MMU).

2. Memory Management Unit (MMU)

The memory management unit, referred to as MMU, is responsible for mapping virtual addresses to physical addresses and provides hardware mechanisms for memory access permission checks. In multi-user, multi-process operating systems, the MMU allows each user process to have an independent address space.

Figure 2 Position of MMU

Any microcontroller has a set of addresses that a program can generate, known as the virtual address range. For example, in a 32-bit machine, the virtual address range is 0~0xFFFFFFFF (4G). When the controller addresses a 256M memory, its available address range is limited to 0x00000000~0x0FFFFFFF (256M). In controllers without MMU, virtual addresses are sent directly to the memory bus to read and write the physical memory at that address. In controllers with MMU, the virtual address is first sent to the MMU, mapped to a physical address, and then sent to the memory bus.

Figure 3 Memory management mechanism

Note: The above figure only simply reflects the mapping mechanism of memory management; concepts such as permission mapping, TLB cache, page tables, etc., are not discussed in depth.

The main function of virtual memory management is to allow each process to have an independent address space. The same virtual address in different processes is mapped by the MMU to different physical addresses, and accessing any address in a certain process cannot access the data of another process. This ensures that any process’s illegal memory access due to executing erroneous instructions or malicious code does not accidentally overwrite the data of other processes, thereby ensuring the stability of the entire system. On the other hand, each process thinks it occupies the entire virtual address space, making the implementation of linkers and loaders easier without having to consider whether the address ranges of different processes conflict.

3. Linux System

Generally, operating systems are divided into real-time operating systems and non-real-time operating systems. Real-time operating systems are mostly single-process, multi-threaded (multi-tasking), so they do not involve address space allocation between threads and do not need to use MMU, such as VxWorks. The Linux system belongs to a non-real-time operating system, with multi-processing as its main feature.

Taking Ubuntu as an example, we open a shell and check the address range of the bash process as shown in Figure 4, its address range is 0x0000000000400000~0xffffffffff600000.

Figure 4 bash address in shell 1

We open another shell and check the address range of the bash process in that shell as shown in Figure 5. It is not difficult to find that the address ranges of the two different bash processes are exactly the same. In fact, the operating system or the user does not need to consider the physical memory address allocation when forking a process; this work is done by the microcontroller’s memory management unit (MMU).

Figure 5 bash address in shell 2

Since multi-processing relies on the memory management unit, can we just open one process when using embedded Linux? It is definitely not feasible! After booting, even if the user does nothing, the visible system must have dozens to hundreds of processes already running, as shown in Figure 6.

Figure 6 Process tree

4. Summary

In summary, the Linux system has a strong dependency on the memory management unit. If Linux is run on a processor without MMU, the entire system may only remain at the Uboot stage. Since Cortex-M processors do not have a memory management unit, they cannot run the Linux system. However, 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. But is such a workload really worth it? In fact, the MMU was created to solve the increasingly complex memory management of operating systems.

5. Expansion Section

A large number of developers who choose embedded Linux systems fail to leverage its advantages, merely for the convenience of development, such as Ethernet, 4G cloud, LCD drivers, file systems, image recognition, Python applications, etc. So is there a way to use traditional high real-time, low-cost microcontrollers without facing complicated hardware driver development? The new AWorks platform launched by ZLG is born for this purpose – the IoT ecosystem.

The birth of AWorks greatly lowers the threshold for developers, providing convenience and allowing developers to ignore low-level technical details, focusing on the “core domain” of products, and developing competitive products faster. At the same time, AWorks provides developers with highly abstract general interfaces, making software based on the AWorks platform independent of the underlying hardware, allowing for “free” cross-platform reuse (such as changing MCUs, etc.). Cross-border hardware equipped with the AWorks IoT real-time operating system makes your development easier and more powerful. To learn more about the functions and architecture of AWorks, please click to read: Introduction to AWorks Ecosystem.

Figure 7 M1052 cross-border core board & AWorks IoT real-time operating system

Reply the keyword 【Industrial Control】 in the background to see more related technical topics.