ARM Linux 启动的一些细节 [英] Some details on ARM Linux boot

问题描述

我正在尝试了解 linux 在 arm 架构上启动的细节.我在互联网上进行了大量搜索并了解了一些细节，尽管我每次阅读一篇文章时都会带来许多其他新术语，这使事情变得更加复杂.我确实有 2 个运行 linux 的板，一个 olimex 9261 和一个 beaglebone black.我在嵌入式系统方面的专业知识，尤其是 arm 相当不错，但在 linux 方面并没有玩太多(除了一些用户空间程序和内核中的字符驱动程序).

I'm trying to understand the details of linux booting on arm architecture. I did lot of search on the internet and understood so far some details although I feel each time I read an article it brings lot of other new terms and this makes things more complex. I do have 2 boards running linux, an olimex 9261 and a beaglebone black. My expertise in embedded systems especially arm is pretty good, but didn't play too much with linux though (except some user space programs and char drivers in kernel).

这是我的问题:

一块板我有以下 uboot 输出(linux 2.6.30):

One one board I have the following uboot output (linux 2.6.30):

 bootargs=mem=64M console=ttyS0,115200 root=/dev/mtdblock1 rw rootfstype=jffs2
 bootcmd= cp.b 0xC0042000 0x22000000 0x00199954; bootm 0x22000000

该板有 64MB RAM(映射到 0x20000000)、512MB nand flash(目前没有找到映射)和 2MB 数据闪存(映射到 0xc0000000).

The board has 64MB RAM (mapped at 0x20000000), 512MB nand flash(didn't find mapping so far) and 2MB data flash (mapped at 0xc0000000).

我不明白的地方:

• 为什么 bootargs 中有一个 mem=64?这不是应该以 ATAG 或 DTB 形式给出吗?
• 当我们将控制权传递给内核时，为什么会有一个控制台作为参数给出?内核是否使用了 uboot 已经配置好的 tty?
• initrd 与 rootfs.这对我来说仍然不清楚.我知道 initrd 可以作为块设备或单独的映像包含在内核中，uboot 必须将地址详细信息传递给内核(真的吗?).我们可以有一个不包含 initrd 的内核 + 另一个文件系统，比如这个 jffs2，内核将运行其余的驱动程序吗?实际上我无法理解内核在启动时使用的文件系统的全部细节.在我的这个设置中，有 4 个文件:uImage、bootstrap、env.bin 和 jffs2 文件系统.所以没有initrd.这是如何工作的?以及上面bootargs中指向的文件系统的root过程是怎样的?在我的理解中，内核应该首先访问 jffs2 文件系统，然后获取在/dev/mtdblock1 中找到的映像并挂载它.也许我的理解是错误的.其实内核和文件系统之间的这种交互是我似乎不明白的.在上面的 bootcmd 中，内核从 nand 复制到 sdram 然后 bootm 跳转到它.但是内核如何在启动时找到 jffs 呢?我在启动过程中看到这个输出行:VFS:在设备 31:1 上挂载根目录(jffs2 文件系统).

在开发板用户指南中，我发现了这一点:

In the board user guide I found this:

警告:由于 AT91SAM9261 芯片勘误从 NAND 闪存启动不支持.

WARNING: Due to AT91SAM9261 chip errata booting from NAND flash is not supported.

...

512MB NAND 闪存(在 Linux 中被视为硅驱动器).

512MB NAND Flash (seen in Linux as silicon drive).

• 编译内核后，我观察到 System.map 没有所有符号.我检查了 vmlinux，它是一样的.有谁知道为什么?也许编译器没有正确配置?

非常感谢，丹尼尔.

推荐答案

你的大部分问题都可以通过 阅读 Linux 源代码附带的文档.一些关键文件是，

Most of your questions can be answered by reading the Documentation that comes with your Linux source. Some key files are,

• 内核参数.txt
• arm/booting.txt

请仔细阅读它们，因为它们将提供适用于您的 Linux 版本的最新信息.

Please take a look through them as they will have information current to your version of Linux.

一块板我有以下 uboot 输出(linux 2.6.30):

One one board I have the following uboot output (linux 2.6.30):

2.6.30 内核早于 ARM 的设备树.

The 2.6.30 kernel pre-dates device trees for the ARM.

为什么 bootargs 中有一个 mem=64?这不是应该以 ATAG 或 DTB 形式给出吗?

why there is a mem=64 in the bootargs? Isn't this supposed to be given as ATAG or DTB ?

有两种机制.ATAGS 更加灵活，因为它可以指定多个不连续的内存组.这个想法是引导代码可以探测内存并通过 ATAGS 提供它.这就是理论.这通常很难做到，因此允许用户指定 mem=64 更容易实现.如果有两种板卡类型，一种是 64MB，一种是 128MB，则由用户提供命令行来使用额外的内存.

There are two mechanisms. The ATAGS is more flexible as it can specify several non-contiguous banks of memory. The idea is that boot code can probe the memory and provide it via ATAGS. That is the theory. It is often tough to do, so allowing a user to specify mem=64 is a lot easier to implement. If there are two board types, one with 64MB and one with 128MB, it is up to the user to provide a command line to use the extra memory.

当我们将控制权传递给内核时，为什么会有一个控制台作为参数给出?内核是否使用了uboot已经配置好的tty?

why is there a console given as argument when we pass the control to kernel? Is the kernel using the tty already configured by uboot?

某些设备有多个串行端口.某些内核可能希望将u-boot"端口用于其他用途.HDSPA 调制解调器、打印机等.Linux 内核和 u-boot 控制台可能不同.这是一个特点.我经常使用 /dev/null 作为控制台.硬件往往吝啬给一个额外的串口.也许您很幸运，您的硬件人员并不认为软件是免费的.

Some devices have multiple serial ports. Some kernels may wish to use the 'u-boot' port for something else. HDSPA modem, printer, etc. The Linux kernel and the u-boot consoles may be different. That is a feature. I often use /dev/null as the console. Hardware is often stingy to give an extra serial port. Maybe you are lucky and your hardware people don't think software is free.

initrd 与 rootfs.

initrd vs rootfs.

您可以直接引导至文件系统 (rootfs)，但查找代码的所有代码和机制都必须在 Linux 映像中.即使它们是 (JFFS2/NAND)，随着 NAND 的磨损，您最终可能会得到一个损坏的 rootfs.前 128MB 的 NAND 通常质量更高.您可以在此处放置一个带有 initrd 的 Linux，它可以修复主文件系统.对于其他引导设备，引导设备可能并不直接，并且可以在 initrd 映像中做出复杂的决定.通常 initrd 花费更少的时间来挂载，并且您可以更快地执行某些操作.最后，您可以加载不同的模块，然后在 initrd 中锁定模块加载.

You may boot directly to a file system (rootfs), but all of the code and mechanisms for finding the code must be inside the Linux image. Even if they are (JFFS2/NAND), you may end up with a corrupt rootfs as NAND wears. The first 128MB of NAND is usually a higher quality. You may put a Linux with initrd here that is capable of repair of the main file system. For other boot devices, it may not be straight forward to boot the device and complex decisions can be made in an initrd image. Often the initrd take far less time to mount and you may perform some actions more quickly. Finally, you may load different modules and then lock module loading in the initrd.

您可以直接使用 rootfs.实现起来更简单.initrd 更加灵活和强大.您可能希望从 JFFS2 过渡到 Ubi/UbiFS.如果您没有 initrd，那么这几乎是不可能的(至少更难实现).

You may use the rootfs directly. It is simpler to implement. The initrd is much more flexible and powerful. You may wish to transition from JFFS2 to Ubi/UbiFS. If you don't have an initrd, then this is pretty much impossible (at least much more difficult to implement).

在我的这个设置中，有 4 个文件:uImage、bootstrap、env.bin 和 jffs2 文件系统.所以没有initrd.

In this setup I have, there are 4 files: uImage, bootstrap, env.bin and jffs2 file system. So there is no initrd.

uImage 可能附加了一个 initrd.它作为 ramdisk 挂载，然后卸载(和 switch_root 到新的/最终的 rootfs) 内存可以自由使用.但是，您的命令行没有 initrd 信息，因此您可能没有.

The uImage may have an initrd attached to it. It is mounted as a ramdisk and after it unmounts (and switch_root to the new/final rootfs) the memory is free to use. However, your command line has no initrd info, so you probably don't have one.

根据我的理解，内核应该首先访问 jffs2 文件系统，然后抓取在/dev/mtdblock1 中找到的映像并挂载它.也许我的理解是错误的.其实内核和文件系统之间的这种交互是我似乎不明白的.在上面的 bootcmd 中，内核从 nand 复制到 sdram 然后 bootm 跳转到它.但是内核如何在启动时找到 jffs 呢?我在启动时看到这个输出行:VFS: Mounted root (jffs2 filesystem) on device 31:1.

In my understanding, the kernel should access first the jffs2 file system, then grab the image found in /dev/mtdblock1 and mount it. Perhaps my understanding is wrong. Actually this interaction between kernel and file system is what I seem not to understand. In the above bootcmd, the kernel is copied from nand to sdram then bootm jumps to it. But how does the kernel find the jffs at booting time? I see this output line during boot: VFS: Mounted root (jffs2 filesystem) on device 31:1.

您有找到设备的信息；root=/dev/mtdblock1 然后你告诉它文件系统类型；rootfstype=jffs2.缺少的部分是 init=/sbin/init.您可以在 kernel-parameters.txt 适用于您的 Linux.挂载 JFFS2 后，init 代码会查找要运行的进程.它是一切的父进程，它将开始执行许多不同的进程.通常它是 init，但您可以指定 init=/bin/sh 并且您将只需要一个 shell.这是开发 initrd 映像的好方法，因为您可以仅在一个进程运行时测试脚本.

You have information to find the device; root=/dev/mtdblock1 and you told it the file system type; rootfstype=jffs2. The missing piece is the init=/sbin/init. You can read about it in the kernel-parameters.txt for your Linux. After the JFFS2 is mounted, the init code looks for a process to run. It is the parent process of everything and it will start to execute many different processes. Typically it is init, but you can specify init=/bin/sh and you will just have a shell to start with. This can be a good way to develop an initrd image as you can test scripts with only one process running.

编译内核后，我观察到 System.map 没有所有符号.我检查了 vmlinux，它是一样的.有谁知道为什么?也许编译器没有正确配置?

After compiling the kernel, I observed the System.map doesn't have all symbols. I checked the vmlinux and it's the same. Does anyone know why? Maybe the compiler was not configured properly?

System.map 实际上只是外部函数和数据.它不包括所有功能.事实上，由于内联，某些功能可能不存在.

The System.map is really only external functions and data. It does not include every function. In fact some functions may not exist due to in-lining.

警告:由于 AT91SAM9261 芯片勘误不支持从 NAND 闪存启动.

WARNING: Due to AT91SAM9261 chip errata booting from NAND flash is not supported.

我想这是 u-boot 的工作来处理这个问题.

I guess it is u-boot's job to handle this.

这篇关于ARM Linux 启动的一些细节的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！