Question

我正在尝试使用Buildroot为嵌入式系统（Banana PI D1）构建一个基本的根文件系统。

我正在使用SDK supplied by the SoC vendor中的内核。从这个repo我只使用在src / kernel中找到的内核。

Buildroot配置没什么了不起的。它构建时没有错误，并且生成的根文件系统看起来像包含了我期望的所有内容。

我已将其配置为将文件系统构建为嵌入在zImage中的initramfs。

内核似乎启动正常，但无法加载init然后发生恐慌：

Booting Linux on physical CPU 0
Linux version 3.4.35 (harmic@penski.harmic.moo.org) (gcc version 4.8.4 (Buildroot 2015.02) ) #7 Sat Mar 21 22:59:18 AEDT 2015
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
...
Kernel command line: root=/dev/mtdblock1 ro init=/sbin/init mem=64M console=ttySAK0,115200
...
Freeing init memory: 4632K
Failed to execute /init
Failed to execute /sbin/init.  Attempting defaults...
mmc0: host does not support reading read-only switch. assuming write-enable.
mmc0: new SDHC card at address 0007
mmcblk0: mmc0:0007 SD08G 7.42 GiB 
 mmcblk0: p1
Kernel panic - not syncing: No init found.  Try passing init= option to kernel. See Linux Documentation/init.txt for guidance.

我尝试过多个故障排除步骤：

我使用this miniroot project构建了一个根文件系统（做了一些，因为它已经过时了）。它启动正常，使用与我尝试使用buildroot root fs相同的内核。
我尝试过使用uClibc和eglibc
我尝试过使用Buildroot自己的交叉工具以及SoC供应商提供的交叉工具
我已经确认构建的rootfs确实包含/ init（确实如此！）

有一个gist here包含buildroot配置，内核启动日志的副本以及生成的文件系统内容列表。

我可以采取哪些措施对此进行进一步排查？

更新

生成的rootfs.cpio.gz的重量为2139200字节。我已经读过你可以使用的initramfs的最大大小，但是我无法找到记录硬限制的位置。
我已将生成的根文件系统列表附加到上面链接的要点。

我已经解压缩了主机上的rootfs并进行了检查。 / init包含这个：

#!/bin/sh
# devtmpfs does not get automounted for initramfs
/bin/mount -t devtmpfs devtmpfs /dev
exec 0</dev/console
exec 1>/dev/console
exec 2>/dev/console
exec /sbin/init $*

/ sbin / init是/ bin / busybox的符号链接。

/ bin / busybox是动态链接的：

$ file busybox
busybox: setuid ELF 32-bit MSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, stripped
$ ../../../host/usr/bin/armeb-buildroot-linux-gnueabi-readelf -a busybox | grep "Shared library:"
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]

libc.so.6存在于/ lib中。 / lib32是/ lib的符号链接，用于衡量标准。

该设备具有64M RAM。
供应商的交叉工具和buildroot交叉工具都是为eabi设置的

Answer 1

正如@sawdust所建议的，问题是CPU不应该以大端模式运行。

将目标更改为“ARM（Little Endian）”，清洁并重新构建后，它现在可以正确启动。

回想起来，这应该是显而易见的 - 检查供应商的核心图像：

$ file zImage
zImage: Linux kernel ARM boot executable zImage (little-endian)

无法执行/ init

1 个答案: