在低内存嵌入式系统中使用Busybox的意义何在? [英] What's the point of using Busybox in a low ram embedded system

问题描述

我正在努力将Linux带到具有16 Mb SDRAM和64 Mb Flash的定制Cortex-M7板上.该平台没有MMU，没有共享库，没有FLAT可执行文件.

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.

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

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).

所以问题是:如果系统总是必须为busybox中实现的每个命令在内存中加载一个巨大的可执行文件，那么这有什么方便呢?在达到极快的ram速度的同时，我并不想节省一些兆字节的廉价和充足的存储，但也许我忽略了某些事情.

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.

我的平台是Busybox的用例吗?如果不是，是否有任何方法可以方便地在各自的可执行文件上构建linux系统实用程序?

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

提前谢谢！

Busybox，据他们自己所说:"在编写时就考虑到大小优化和有限的资源"，因此成为嵌入式系统中毫无疑问的事实上的标准.但是他们的陈述与RAM(而非存储)受限系统上的上述问题有何关系?我相信这值得澄清.

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:

内核已经针对XIP进行了编译，可以从64 Mb的外部闪存执行.现在，整个读/写ext3根文件系统(包括busybox二进制文件)都位于micro SD卡上. Busybox可执行文件使用FLAT格式("bFLT")，并启用了RAM加载位，该位似乎在每次运行并发命令直到耗尽合适的块时都在不同的存储块上引起新的加载.将busybox(整个/bin，/sbin)放在XIP文件系统上的建议非常出色，并且肯定会提高执行速度(当然，此新文件系统将需要驻留在64 Mb外部闪存上).我从来没有尝试过在这样的文件系统上执行"bFLT"(也不清楚它是否可以工作)，但我将对此进行研究/测试.

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具有庞大的基础架构，并且可以使用各种rootfs或引导文件系统.选择是由于适应了不同的系统限制和最终用户功能. Busybox是目标系统的不错选择，但是如果系统工程师不花时间去理解它，那么任何软件都可能被滥用.

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.

我的平台是Busybox的用例吗?

Is my platform an use case for Busybox?

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

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.

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

if not, is there anything to conveniently build linux system utilities each on their own executable?

请参阅下面的klibc信息.您还可以使用musl构建破折号，许多目标，例如软件包管理和实时更新.

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.

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

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.

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

a custom Cortex-M7 board with 16 Mb of SDRAM and 64 Mb of Flash

...

一个且只有busybox可执行文件(我的系统上为650 Kb)

one and only busybox executable (650 Kb on my system)

显然650KB远远小于16MB.您无需说明其他RAM的用途.有关另一种好的替代方法，请参见 klibc工具套件.目前尚不清楚FLASH是否为NAND/NOR，以及是否启用了XIP.通常，仅使用XIP闪存时，busybox会更好，而对于某些文件系统在闪存中，klibc仅对于SDRAM会更好(并且受到更多限制).

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.

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

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没有比busybox更多的文档.它可以是共享库，也可以是静态链接的.每个二进制文件将仅使用静态链接执行该任务所需的RAM，但这将占用更多的闪存空间.带有klibc的二进制文件是

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

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

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可以做更多的事情.大多数klibc静态二进制文件的大小都将低于100kB；典型值为10-30kB.破折号和gzip较大.但是，我认为您需要从内核中删除配置项，因为650KB<<<即使没有XIP，16MB和busybox也是该系统的不错选择.

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.

我还应该指出，Linux使用MMU系统对代码进行需求页面加载".即使您没有交换，代码也可以从RAM中踢出，并在以后出现页面错误时重新加载.您的系统是非MMU，因此在这种情况下busybox不能正常运行.使用mmu和按需加载页面"，它将做得更好.

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.

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

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.

另请参阅:

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

• AXFS - xip read-only file system.
• CrafFs - another xip file system.
• XIP kernel - the kernel can be huge. Get it out of RAM if possible. Configure with EMBEDDED option if not.
• nommu.org - some information on github
• elf2flt - Mike Frysingers updates to binutils 2.27-2.31.1
• fdpic gcc - notes from 2016 by mickael-guene.

XIP只能与ROM，NOR闪存配合使用，并且可能与 SPI-NOR MTD.

XIP can only work with ROM, NOR flash and possibly SPI-NOR MTDs.

这篇关于在低内存嵌入式系统中使用Busybox的意义何在?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！