Can I run Linux without mmu?

Why do you need mmu?

We know that the application program cannot access the memory at will. If the application program directly accesses the physical memory, then the computer is very dangerous, and all the contents of the computer memory will be completely exposed. Therefore, mmu appears. mmu is a memory management unit. The application program accesses virtual memory. After the virtual memory is converted by mmu, it becomes physical memory. The physical memory corresponds to the address on the actual physical storage disk.

Mainline linux code requires mmu mechanism to run normally.

But if you want to run the linux kernel code without mmu, it is not impossible, you need to cut and configure, the most difficult thing is debugging.

The mmu module is generally an internal component of the CPU, of course, there are also cases of location mmu.

If you want to run linux kernel code without mmu, look at uclinux

What is uclinux?

In the English word uClinux, u means Micro, which means small, and C means Control, which means control, so uClinux is Micro-Control-Linux, which literally means “a Linux system designed for the micro-control field”.

The difference between uclinux and linux

• no virtual memory management unit mmu
• Increment process stack when not running
• Pagination is not supported
• Executable program is not elf, but flat
• Can not use fork, but use vfork
• RAMDISK

no virtual memory management unit mmu

Increment process stack when not running

Pagination is not supported

Executable program is not elf, but flat

Can not use fork, but use vfork

RAMDISK

uClinux is an embedded linux operating system for the control field. It is derived from the Linux 2.0/2.4 kernel and follows most of the features of mainstream Linux. Suitable for microprocessors/microcontrollers that do not have a memory management unit (MMU). The lack of MMU support is a fundamental difference between uClinux and mainstream Linux.

For uCLinux, it is designed for processors without MMU and cannot use the processor’s virtual memory management technology. uCLinux still uses memory paging management, and the system paging the actual memory at startup. The program loads in pagination when the application is loaded. But since there is no MMU management, uCLinux actually adopts the real memory management strategy. The uCLinux system accesses memory directly, and the addresses accessed in all programs are actual physical addresses. The operating system does not protect the memory space, and each process actually shares a running space. Before a process is executed, the system must allocate enough contiguous address space for the process, and then all load it into the contiguous space of main memory.

memory protection

Operation without Memory Protection will result in this:

Even a call to an invalid pointer by an unprivileged process will trigger an address error and potentially cause the program to crash or even cause the system to hang. Obviously, code running on such a system must be carefully programmed and thoroughly tested to ensure robustness and security.

For ordinary Linux, different user programs need to be run. If there is no memory protection, the security and reliability of the system will be greatly reduced; however, for embedded uClinux systems, the programs that are running are often solidified before leaving the factory. Yes, there is no hidden danger of program intrusion jeopardizing the security of the system, so as long as the application has undergone a relatively complete test, the probability of problems can be controlled within a limited range.

Virtual Memory

No virtual memory (Virtual Memory) mainly leads to the following consequences:

First, processes loaded by the kernel must be able to run independently of their location in memory. The first way to achieve this is to “fix” the base address of the program once it is loaded into RAM; another way is to generate code that uses only relative addressing (called “position independent code”). , Position Independent Code, referred to as PIC). uClinux supports both modes.

Second, to solve the problem of memory allocation and deallocation in the flat memory model. Very dynamic memory allocation can cause memory fragmentation and can exhaust the system’s resources. For those applications that use dynamic memory allocation, one way to increase robustness is to replace malloc calls with preallocated buffer pools.

Since virtual memory is not used in uclinux, page swapping in and out of memory is not implemented, as there is no guarantee that pages will be loaded into the same location in RAM. On ordinary computers, the operating system allows applications to use more memory space than physical memory (RAM), often by setting up a swap partition on the hard disk. However, in embedded systems, FLASH memory is usually used to replace the hard disk, and it is difficult to efficiently realize the access of memory pages. Therefore, the allocatable space for running applications is restricted to be no larger than the RAM space of the system.

Note: Multitasking is not affected. Which old-fashioned, fork-wide network daemons do need to be modified. Since the child process runs in the same address space as the parent process, in some cases it is also necessary to modify the behavior of both processes.

Many modern programs rely on subprocesses to perform basic tasks so that the system can remain in an “interactive” state even when the process is heavily loaded, these programs may require substantial modifications to accomplish the same tasks under uClinux . If a critical application relies heavily on such a structure, it will have to be rewritten.

Suppose you have a simple network daemon that makes heavy use of fork. This daemon listens on a well-known port (or socket) waiting for network clients to connect. When a client connects, the daemon gives it a new connection message (a new socket number) and calls fork. The child process will then connect to the client on the new socket, and the parent process is released and can continue to listen for new connections.

uClinux has neither an auto-growing stack nor a brk function, so user-space programs must use the mmap command to allocate memory. For convenience, the malloc implemented in the C language library of uclinux is essentially an mmap. At compile time, the stack size of the program can be specified.

Finally, the uClinux target board processor lacks a hardware unit for memory management, which makes some changes to the Linux system interface. Probably the biggest difference is that there are no fork and brk system calls. Calling fork will copy out the process to create a child process. Under Linux, fork is implemented using copy-on-write pages. Without an MMU, uclinux cannot replicate a process completely and reliably, nor does it have access to copy-on-write. To make up for this deficiency, uClinux implements vfork, when the parent process calls vfork to create a child process, the two processes share their entire memory space, including the stack. The child process either executes in place of the parent process (the parent process has already sleep) until the child process calls exitI to exit, or calls exec to execute a new process, at which time the executable file will be loaded. Even if the process is just a copy of the parent process, this process cannot be avoided. When the child process executes exit or exec, the child process uses wakeup to wake up the parent process, and the parent process continues to execute.

Kernel changes for common architecture:

In the release of uCLinux, the /linux/mmnommu directory replaces the /linux/mm directory. The former is the modified memory management subsystem, which removes the hardware dependency of the MMU and provides basic memory management functions in the kernel software itself.

Many subsystems need to be reworked, added or rewritten. Kernel and user memory allocation and deallocation processes must be reimplemented, and support for transparent interaction/paging is removed. In the kernel, support for “kernel independent code (PIC)” has been added The program supports modules and uses a new binary object code format, called the flat format, to support PIC (with a very compact header).

The kernel also provides a program loading module that supports the ELF format to support executable programs using a fixed base address. Both modes have their own advantages and disadvantages, the traditional PIC runs fast, and the code is compact, but there are code size limitations. For example, the Motorola 68K architecture The 16-bit relative jump limit of PIC program cannot exceed 32KB in size, and the program code listed by the method of fixed base address during runtime has no size limit, but when Chen Xu is loaded by the kernel, it causes more system overhead. For For kernel developers, uCLinux is basically the same as Linux, the only difference is that it cannot use the memory management provided by MMU. In fact, this has no effect on the kernel. All standard executable file formats under Linux are not used in uCLinux. Support, because these formats also use some functions of virtual memory. uCLinux uses another flat format. The flat format is a compact and efficient executable file format, its value contains executable code and data, and some Relocatable information needed to load an executable file into any memory location.

Summary: In the process of porting applications to uClinux and writing our own code, we will always focus on these features:

1. When configuring, if possible, you need to select –disable-shared and –enable-static when configuring.

2. Change all occurrences of fork in the source code to vfork;

3. Add -Wl, -elf2flt to the cross compiler and compilation options in the Makefile, and the link options. Although this is only a linking option, I was careful to specify the option in LDFLAGS and CFLAGS, even in CC.

4. Why is the industry paying so much attention to a new processor core?

5. The second issue of “Single-chip microcomputer and embedded system application” electronic journal in 2022 is freshly released!

6. Chip prices: inevitable!

7. “In-depth understanding of RISC-V program development” courseware and video courses are online~

8. No regrets! 18 embedded C practical experience summed up by veterans in the circle

9. Convert hardware to software, be careful!

Disclaimer: This article is reproduced online, and the copyright belongs to the original author. If the copyright of the work is involved, please contact us, and we will confirm the copyright and pay the remuneration or delete the content according to the copyright proof .