在低内存嵌入式系统中使用 Busybox 有什么意义

本文介绍了在低内存嵌入式系统中使用 Busybox 有什么意义的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

我正致力于将 linux 引入具有 16 Mb SDRAM 和 64 Mb 闪存的定制 Cortex-M7 板.该平台没有 MMU，没有共享库，没有 FLAT 可执行文件.

我在使用非常简单的 init.d shell 脚本启动 Busybox 系统时遇到问题.通过执行诸如["或printf"之类的简单shell命令，系统就会耗尽内存.事实证明，每次执行这些命令之一时，系统都需要加载 FULL、一个且唯一的 busybox 可执行文件(在我的系统上为 650 Kb).

那么问题是:如果系统总是要为在busybox中执行的每个命令都在内存中加载一个巨大的可执行文件，那么这有多方便?我不明白在极快地耗尽内存的同时节省几兆字节的廉价和丰富的存储空间，但也许我忽略了一些东西.

我的平台是 Busybox 的用例吗?如果没有，有没有什么可以方便地在自己的可执行文件上构建 linux 系统实用程序?

提前致谢！

Busybox，根据他们自己的说法在编写时考虑了大小优化和有限的资源"，因此成为嵌入式系统中一种毋庸置疑的事实上的标准.但是他们的声明与 RAM(而非存储)受限系统上的上述问题有何关联?我认为这值得澄清.

跟进，系统详情:

内核已经为 XIP 编译，从 64 Mb 外部闪存执行.整个读/写 ext3 根文件系统(包括 busybox 二进制文件)现在驻留在微型 SD 卡上.Busybox 可执行文件使用 FLAT 格式(bFLT")并启用加载到 RAM 位，该位似乎在每次运行并发命令时在不同的内存块上导致新的加载，直到耗尽拟合块.将busybox(整个/bin、/sbin)放在XIP 文件系统上的建议非常棒，它肯定会提高执行速度(当然，这个新文件系统需要驻留在64 Mb 外部闪存上).我从未尝试过在这样的文件系统上执行bFLT"(也不知道它是否有效)，但我会对此进行研究/测试.

解决方案

TL-DR;Linux 拥有庞大的基础设施和各种可用的 rootfs 或引导文件系统.选择是由于适应不同的系统限制和最终用户功能.Busybox 是目标系统的不错选择，但如果系统工程师不花时间了解它，任何软件都可能被滥用.

我的平台是 Busybox 的用例吗?

如果您花时间最小化内核大小和busybox 本身.您不太可能需要当前 busybox 中的所有功能.

如果没有，有什么方法可以方便地在各自的可执行文件上构建 linux 系统实用程序吗?

请参阅下面的 klibc 信息.您还可以构建 dash with musl, 使用buildroot 和busybox.许多文件系统构建器支持共享库或静态二进制文件.但是，文件系统构建器可能会针对许多目标，例如包管理和实时更新.

更多详情

您可以在busybox之外配置功能.这个想法是需要所有配置的功能.因此，您需要将它们全部保存在内存中.对于busybox，ls、mkdir、printf 等都是相同的二进制文件.因此，如果您运行 shell 脚本，则一次代码加载就是所有代码加载.另一方面，您有许多单独的二进制文件，每个文件都会占用额外的内存.您需要最小化 Linux 以获得更多 RAM，并且您可以从 busybox 中取出功能以使其更小.Busybox 就像一个巨大的共享库；或者更准确地说是共享进程.所有代码页都相同.

带有 16 Mb SDRAM 和 64 Mb 闪存的定制 Cortex-M7 板

...

唯一一个busybox可执行文件(在我的系统上为650 Kb)

显然 650KB 远小于 16MB.您没有说明其他 RAM 的用途.另一个不错的替代方法是查看 klibc 工具套件.不清楚的是 FLASH 是否为 NAND/NOR 以及您是否启用了 XIP.通常，busybox 使用 XIP 闪存会更好，而 klibc 仅适用于 SDRAM 更好(并且更有限)，在闪存中有一些文件系统.

请参阅:Busybox 常见问题解答中的可重定位代码、PIC 和静态链接使用的内存.它被设计为从只读内存运行，这取决于系统结构，这可能是一个很大的收益.它可能提供比 klibc 更丰富的功能集，因为该项目的目标只是启动其他一些挂载设备(硬盘驱动器、SSD 等).

Klibc 没有busybox 那么多的文档.它可以是共享库或静态链接.每个二进制文件将仅使用静态链接任务所需的 RAM，但这将占用更多闪存空间.带有 klibc 的二进制文件是，

1. 破折号 2. chroot 3. dd 4. dmesg 5. mkdir 6. mkfifo7. mknode 8. pivot_root 9. 卸载 10. 真 11. 假 12. 睡眠13. ln 14. ls 15. mv 16. 核弹 17. minips 18. 猫19.uname 20.halt 21.kill 22.cpio 23.sync 24.readlink25. gzip 26. 丢失

这就是 IT！ 没有网络，没有媒体播放器等.您可以编写代码来使用 klibc，但它是一个非常受限制的库，可能没有您需要的功能.通常它仅限于磁盘任务.例如，为外部设备探测 USB 是很好的.

Busybox 可以做更多事情.大多数 klibc 静态二进制文件都在 100kB 以下；典型值为 10-30kB.Dash 和 gzip 更大.但是，我认为您需要从内核中删除配置项为 650KB <<即使没有 XIP，16MB 和 busybox 也是这个系统的不错选择.

我还应该指出，Linux 对 MMU 系统的代码确实要求页面加载".即使您没有交换，代码也可能会被踢出 RAM 并在稍后因页面错误而重新加载.你的系统没有 MMU，所以在这种情况下，busybox 不会表现得很好.有了 mmu 和按需页面加载"，它会做得更好.

对于严格的限制，您始终可以编写一个完全库免费的二进制文件.这避免了您可能不需要的 libgcc 启动和支持基础设施.通常，这仅适用于测试内核与 initrd 问题以及必须在许多不同库环境中运行的脚本/二进制文件.

另见:

AXFS - xip 只读文件系统.
CrafFs - 另一个 xip 文件系统.
XIP 内核 - 内核可能很大.如果可能，将其从 RAM 中取出.如果没有，请使用 EMBEDDED 选项进行配置.
nommu.org - github 上的一些信息
elf2flt - Mike Frysingers 更新到 binutils 2.27-2.31.1
fdpic gcc - mickael-guene 于 2016 年的笔记.

XIP 仅适用于 ROM、NOR 闪存和可能 SPI-NOR MTD.

I'm working on bringing linux to a custom Cortex-M7 board with 16 Mb of SDRAM and 64 Mb of Flash. The platform has no-MMU, no shared libraries, FLAT executables.

I'm having problems booting a Busybox system with very simple init.d shell scripts. The system is running out of memory by executing simple shell commands like "[" or "printf". It turns out that everytime one of these commands are executed the system needs to load the FULL, one and only busybox executable (650 Kb on my system).

So the question is: if the system always have to load in memory a huge executable for each command implemented inside busybox, then how is this convenient? I don't get the point of saving some megabytes of cheap and abundant storage while going out of ram extremely fast, but maybe I'm overlooking something.

Is my platform an use case for Busybox? if not, is there anything to conveniently build linux system utilities each on their own executable?

Thanks in advance!

EDIT:

Busybox, according to themselves "has been written with size-optimization and limited resources in mind" and so became a sort of unquestioned de-facto standard in embedded systems. But how their statement relates to the forementioned issues on RAM (not storage) constrained systems? I believe this worths some clarification.

Follow up, system details:

The kernel is already compiled for XIP, executing from the 64 Mb external flash. The entire read/write ext3 root filesystem (including busybox binary) now resides on a micro SD card. Busybox executable is using the FLAT format ("bFLT") with load to RAM bit enabled, that bit seems to be causing a new load on a different memory block each time it runs a concurrent command until it exhausts the fitting blocks. The advice to put busybox (the entire /bin, /sbin) on a XIP filesytem is brilliant and it will surely improve the execution speed (of course, this new filesystem will need to reside on the 64 Mb external flash). I never tried a "bFLT" to be executed in place on such a filesystem (nor have an idea if it works) but I'll do my research/testing about that.

解决方案

TL-DR; Linux has a huge infrastructure and variety of rootfs or boot file systems available. The choice is due to accommodation of different system constraints and end user functions. Busybox is a good choice for the target system, but any software can be misused if a system engineer doesn't spend time to understand it.

It is if you take time to minimize the kernel size and busybox itself. It is unlikely you need all features in your current busybox.

See klibc information below. You can also build dash with musl, with buildroot and busybox. Many filesystem builders support shared libraries or static binaries. However, there are many goals such as package management, and live updates, that a filesystem builder may target.

More Details

You can configure features out of busybox. The idea is that all of the configured features are needed. Therefore you need them all in memory. With busybox, ls, mkdir, printf, etc are all the same binary. So if you run a shell script the one code load is all code loads. The other way, you have many separate binaries and each will take extra memory. You need to minimize Linux to get more RAM and you can take features out of busybox to make it smaller. Busybox is like a giant shared library; or more accurately a shared process. All code pages are the same.

...

Obviously 650KB is far less than 16MB. You don't say what the other RAM is used for. For another good alternative look at the klibc toolsuite. What is not clear is whether the FLASH is NAND/NOR and if you have XIP enabled. Generally, busybox would be better with XIP flash and klibc would be better (and more limited) for SDRAM only, with some filesystem in flash.

See: Memory used by relocatable code, PIC, and static linking in the Busybox FAQ. It is designed to run from Read-only memory which can be a big gain depending on system structure. It probably provides a more rich feature set than klibc as the goal with that project is just to boot some other mount device (a hard drive, SSD etc).

Klibc does not have as much documentation as busybox. It can be either a shared library or statically linked. Each binary will only use the RAM needed for that task with static linking, but this will take more flash space. The binary with klibc are,

 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

and that is IT! No networking, no media players, etc. You can write code to use klibc, but it is a very constrained library and may not have features that you require. Generally it would be limit to disk only tasks. It is great to probe USB for external device to boot from for example.

Busybox can do a lot more. Most klibc static binaries will be under 100kB; with 10-30kB typical. Dash and gzip are larger. However, I think you need to remove configuration items from your kernel as 650KB << 16MB and busybox would be a fine choice for this system even without XIP.

I should also be noted that Linux does 'demand page loading' for code with an MMU system. Even if you don't have swap, code can be kicked out of RAM and reloaded later with a page fault. Your system is no-MMU, so busybox will not perform as well in this case. With an mmu and 'demand page loading' it will do much better.

For severe constraints, you can always code a completely library free binary. This avoids libgcc startup and support infrastructure which you might not need. Generally, this is only good to test a kernel vs. initrd issue and for script/binary that must run in many different library environments.