Cortex-M MMU内存管理单元和 Linux

Posted 2020-12-11 非是非非

一、Cortex-M的定位

 

二、内存管理单元

内存管理单元简称MMU，它负责虚拟地址到物理地址的映射，并提供硬件机制的内存访问权限检查。

在多用户、多进程的操作系统中，MMU使得各个用户进程都有独立的地址空间。

 

任何微控制器都存在一个程序能够产生的地址集和，被称为虚拟地址范围。

以32位机为例，虚拟地址范围0~0xFFFFFFFF (4G)。当该控制器寻址一个256M的内存时，它的可用地址范围被限定为0x00000000~0x0FFFFFFF(256M)。在没有MMU的控制器中，虚拟地址被直接发送到内存总线上，以读写该地址下的物理存储器。

在拥有MMU的控制器中，虚拟地址首先被发送到MMU中，被映射为物理地址后再发送到内存总线上。

 

虚拟内存管理最主要的作用是让每个进程有独立的地址空间。

不同进程中的同一个虚拟地址被MMU映射到不同的物理地址，并且在某一个进程中访问任何地址都不可能访问到另外一个进程的数据，这样使得任何一个进程由于执行错误指令或恶意代码导致的非法内存访问都不会意外改写其它进程的数据，不会影响其它进程的运行，从而保证整个系统的稳定性。

另一方面，每个进程都认为自己独占整个虚拟地址空间，这样链接器和加载器的实现会比较容易，不必考虑各进程的地址范围是否冲突。

三、linux系统

一般将操作系统分为实时操作系统和非实时操作系统。

实时操作系统大多为单进程、多线程(多任务)，因此不涉及到线程间的地址空间分配，不需要使用MMU，例如VxWorks。Linux系统属于非实时性操作体统，多进程是其主要特点。

以Ubuntu为例，打开一个shell并且查看bash进程的地址范围为0x0000000000400000~0xffffffffff600000。

我们打开另一个shell，查看该shell中bash进程的地址范围。不难发现，两个不同bash进程的地址范围完全相同。

其实操作系统或者用户在fork()进程时完全不需要考虑物理内存的地址分配，该工作由微控制器的内存管理单元MMU来做。

既然是多进程依赖了内存管理单元，那么在使用嵌入式linux时只开一个进程可以吗?肯定是不可行的!开机后即使用户什么都不做，可见的系统运行必须的进程已经运行了几十至上百个，如下图。

 

 

4、总结

综合以上内容，linux系统对内存管理单元有极强的依赖，若在没有MMU的处理器中运行linux，恐怕整个系统只能停留在Uboot阶段了。由于Cortex-m处理器没有内存管理单元，因此跑不了linux系统。任何事情都不是绝对的，如果你重写了linux内核且搭配足够大的内存芯片，从理论上来说是可以省掉MMU的。但是，这样的工作量，真的值得吗?实际上，MMU就是为了解决操作系统越来越复杂的内存管理而产生的。

STM32是不可以运行linux的，linux系统是运行单位是进程，ucos运行单位是线程。要实现进程芯片必须有MMU（存储管理单元）。crotex-M没有MMU。所以不能运行进程的操作系统。

MMU是Memory Management Unit的缩写，中文名是内存管理单元，它是中央处理器（CPU）中用来管理虚拟存储器、物理存储器的控制线路，同时也负责虚拟地址映射为物理地址，以及提供硬件机制的内存访问授权，多用户多进程操作系统。

操作系统有两种 用MMU的 和 不用MMU的

用MMU的是：Windows MacOS Linux android

不用MMU的是：FreeRTOS VxWorks ucOS...

 

CPU有两种 带MMU的 和 不带MMU的

带MMU的有 Cortex-A系列 ARM9 ARM11系列

不带MMU的有 Cortex-M系列...

 

STM32是M系列...不可能运行Linux...

ucLinux不算Linux的...
————————————————
版权声明：本文为CSDN博主「pl0020」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/pl0020/java/article/details/85275760