在ARM Cortex-R4上运行无MMU Linux

我的系统使用ARM Cortex-R4。它有一个内存保护单元，而不是内存管理单元。实际上，这意味着有专门的硬件用于内存保护，但物理地址和虚拟地址之间有一对一的映射。我有点困惑我应该选择哪种Linux——禁用MMU的标准Linux内核还是uCLinux

在ARM的评估板上，我运行了禁用MMU编译的标准内核。我使用了ARM官方网站上提供的cramfs文件系统。内核启动后，我就在shell中了，但我无法做很多实验，因为我发现，大多数时候，shell都停止响应（特别是当我按下“tab”自动完成时）

因此，如果使用正确的文件系统，我仍然不确定无MMU内核是否能够顺利运行。另外，对于无虚拟机Linux，我应该使用哪个发行版（buildroot？）

---

欢迎您提出任何想法或建议。

我相信ucLinux就是为这样的东西而构建的[无mmu系统]

---

uClinux是一个Linux发行版，它使用“关闭”MMU的Linux内核，并在其上添加一些应用程序和库。你不会选择其中一个，因为它们是最好的

---

如果您有一个shell正在运行，那么您已经成功地在您的板上启动了LinuxSansMMU，但是遇到了一个bug

我问这个问题已经两年多了。现在是我写我自己发现的东西的时候了

ucLinux是很久以前从Linux内核派生出来的一个项目，其目的是为无MMU系统开发内核。但是，经过一段时间后，它被合并到父Linux分支。因此，今天不存在任何活动的ucLinux发行版

因此，如果您从主线内核配置中禁用MMU，您将获得一个无MMU版本。事实上，现在内核本身提供了一些配置选项，用户可以通过这些选项指定内存布局和访问权限

---

干杯

听起来您需要弄清楚到底是什么在崩溃以及为什么会崩溃，而不是猜测它是内核或文件系统。如果你能获得进入电路板的第二条路径，比如uart和网络，这会有所帮助，因为你可以看到其中一条在另一条挂起时是否仍然活着。您还可以做一些事情，比如让一个用户空间守护进程定期写入终端（甚至是一个内核模块printk）来说“仍然在这里”——至少这可以帮助您确定在系统其余部分运行时shell是否挂起，或者内核是否挂起。或者响应gpio按钮…printk（）建议可能比用户空间进程更好。在真实=虚拟模式下运行充其量也是一种挑战。我投票支持uCLinux。