我正在努力将Linux带到具有16 Mb SDRAM和64 Mb Flash的定制Cortex-M7板上。该平台没有MMU，没有共享库，没有FLAT可执行文件。
使用非常简单的init.d shell脚本启动Busybox系统时遇到问题。通过执行简单的shell命令（例如“ [”或“ printf”），系统内存不足。事实证明，每次执行这些命令之一时，系统都需要加载FULL，唯一且仅是busybox可执行文件（在我的系统上为650 Kb）。
所以问题是：如果系统总是必须为busybox中实现的每个命令在内存中加载巨大的可执行文件，那么这有什么方便呢？我无法在快速退出ram的同时节省一些兆字节的廉价和充足的存储，但也许我忽略了某些事情。
我的平台是Busybox的用例吗？如果不是，是否有任何方法可以方便地在各自的可执行文件上构建linux系统实用程序？
谢谢！
编辑：
Busybox，据他们自己所说：“ 在编写时就考虑了大小优化和有限的资源”，因此成为嵌入式系统中一种毫无疑问的事实上的标准。但是他们的陈述与RAM（而非存储）受限系统上的上述问题有何关系？我相信这值得澄清。
接下来，系统详细信息：
内核已针对XIP进行编译，可从64 Mb外部闪存执行。整个读/写ext3根文件系统（包括busybox二进制文件）现在位于micro SD卡上。 Busybox可执行文件使用FLAT格式（“ bFLT”），并启用了RAM加载位，该位似乎在每次运行并发命令直到耗尽合适的块时都在不同的存储块上引起新的加载。在XIP文件系统上放置busybox（整个/ bin，/ sbin）的建议非常好，并且肯定会提高执行速度（当然，这个新文件系统将需要驻留在64 Mb外部闪存上）。我从来没有尝试过在这样的文件系统上执行“ bFLT”（也不清楚它是否可行），但是我将对此进行研究/测试。
答案 0 :(得分：4)
TL-DR； Linux具有庞大的基础架构，并且可以使用各种rootfs或引导文件系统。选择是由于适应了不同的系统约束和最终用户功能。 Busybox是目标系统的不错选择，但是如果系统工程师不花时间去理解它，那么任何软件都可能被滥用。
我的平台是Busybox的用例吗？
是否需要花一些时间来最小化内核大小和busybox本身。您不太可能需要当前busybox中的所有功能。
如果没有，是否有任何方法可以方便地在各自的可执行文件上构建linux系统实用程序？
请参阅下面的klibc信息。您还可以构建dash with musl，with buildroot and busybox。许多文件系统构建器支持共享库或静态二进制文件。但是，文件系统构建器可能会针对many goals，例如包管理和实时更新。
您可以在busybox中配置功能。想法是需要所有已配置的功能。因此，您需要将它们全部存储在内存中。使用busybox时，ls，mkdir，printf等都是相同的二进制文件。因此，如果您运行Shell脚本，则所有的代码加载就是一个代码加载。另一种方法是，您有许多单独的二进制文件，每个二进制文件都将占用额外的内存。您需要最小化Linux以获得更多的RAM，并且可以从busybox中删除功能以使其更小。 Busybox就像一个巨大的共享库。或更准确地说是shared process。所有代码页都相同。
定制的Cortex-M7板，具有16 Mb的SDRAM和64 Mb的闪存
...
一个和唯一的busybox可执行文件（我的系统上为650 Kb）
显然650KB远远小于16MB。您无需说其他RAM的用途。有关另一个好的替代方法，请查看klibc toolsuite。目前尚不清楚FLASH是否为NAND / NOR，以及是否启用了XIP。通常，busybox对于XIP闪存会更好，而klibc对于仅SDRAM且在闪存中具有某些文件系统的情况会更好（并且受到更多限制）。
请参见：“ {@ 3}}，在“忙碌箱”常见问题解答中。它被设计为从只读存储器运行，这可能是很大的收益，具体取决于系统结构。它可能提供比klibc更丰富的功能集，因为该项目的目标只是引导其他安装设备（硬盘，SSD等）。
Klibc没有比busybox多的文档。它可以是共享库，也可以是静态链接的。每个二进制文件仅通过静态链接使用该任务所需的RAM，但这将占用更多的闪存空间。带有klibc的二进制文件是
1. dash 2. chroot 3. dd 4. dmesg 5. mkdir 6. mkfifo 7. mknode 8. pivot_root 9. unmount 10. true 11. false 12. sleep 13. ln 14. ls 15. mv 16. nuke 17. minips 18. cat 19. uname 20. halt 21. kill 22. cpio 23. sync 24. readlink 25. gzip 26. losetup
那就是IT！！无需联网，无需媒体播放器等。您可以编写代码来使用klibc，但这是一个非常受限制的库，可能没有所需的功能。通常，它将仅限于磁盘任务。例如，最好探测USB以使外部设备从中启动。
Busybox可以做更多的事情。大多数klibc静态二进制文件的大小都将低于100kB；典型值为10-30kB。破折号和gzip较大。但是，我认为您需要从内核中删除配置项，因为650KB << 16MB，即使没有XIP，busybox也是该系统的不错选择。
我还应该指出，Linux使用MMU系统对代码进行“需求页面加载”。即使没有交换，代码也可以从RAM中踢出，并在以后出现页面错误时重新加载。您的系统是非MMU，因此busybox在这种情况下将无法正常运行。使用mmu和“按需加载页面”，它将做得更好。
对于严格的约束，您始终可以编写完整的Memory used by relocatable code, PIC, and static linking。这样可以避免可能不需要的libgcc启动和支持基础结构。通常，这仅对于测试内核vs.initrd问题以及必须在许多不同的库环境中运行的脚本/二进制文件是很好的。
另请参阅：
XIP仅可用于ROM，NOR闪存以及fdpic gcc MTD。
答案 1 :(得分：1)
BusyBox的要点是，内存中仅需要一个（共享的）可执行文件。
您写道：
事实证明，每次执行这些命令之一时，系统都需要加载FULL，并且是唯一的busybox可执行文件（在我的系统上为650 Kb）。
那不是完全正确的。对于第一个命令，可执行文件确实已加载到内存中。但是，如果您正在运行多个命令（即多个BusyBox实例），则可执行文件不会多次加载到内存中。二进制文件的很大一部分（简单地说：所有只读数据，例如可执行代码和常量数据）将被重用。每个其他进程仅需要一些额外的内存即可完成其自己的任务。
因此，如果一个BusyBox实例消耗640 kB内存，则10个实例一起只能使用1 MB内存，而10个200 kB的唯一可执行文件将使用2 MB。
我建议对您的系统进行一些实际测试，并检查实际内存消耗。但是请注意，诸如ps或top之类的工具可能会误导或难以理解。已经有很多有关此的文章，如果您想了解更多，here是一个很好的起点。