Я пытаюсь создать базовую корневую файловую систему с помощью Buildroot для встроенной системы (Banana PI D1).Не удалось выполнить/init
Я использую ядро из SDK supplied by the SoC vendor. Из этого репо я использую только ядро, найденное в src/kernel.
Нет ничего примечательного в конфигурации Buildroot. Он строит без ошибок, и получившаяся корневая файловая система выглядит так, будто содержит все, что я ожидаю.
Я сконфигурировал его для создания файловой системы как initramfs, встроенной в zImage.
Ядро появляется, чтобы начать правильно, но не может загрузить инициализации, а затем паники:
Booting Linux on physical CPU 0
Linux version 3.4.35 ([email protected]) (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.
Я попытался использовать как uClibc и eglibc
Я попытался с помощью Buildroot собственных кросс-инструментов, а также кросс-инструменты, поставляемые SoC поставщика
Я подтвердил, что встроенный корневые файловая система действительно включают/инициализации (это делает!)
Существует сущность here содержащей конфигурацию Buildroot, копию журнала загрузки ядра, а также перечень содержимого родов ted файловой системы.
Какие шаги можно предпринять для устранения этой проблемы?
Update:
Сформированный rootfs.cpio.gz весит 2139200 байт. Я прочитал, что максимальный размер initramfs вы можете использовать, но я не смог найти, где документирован жесткий лимит.
Я приложил список созданной корневой файловой системы к gist, указанному выше.
Я распаковал 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.
/бен/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
Ваш вопрос не ясен. Вы хотите, чтобы buildroot создавал файл инициализации или вы хотите иметь запущенную систему? –
поставьте 'ignore_loglevel' в свою командную строку ядра и загрузите. Это может показаться немного больше. – 0andriy
Если у вас есть рабочий qemu для вашей целевой архитектуры (или какой-либо другой механизм удаленной отладки - JTAG?), Вы можете использовать это, чтобы прикрепить отладчик к ядру и посмотреть, что происходит близко. Оверкилл иногда, конечно, но перебор не всегда является плохим. –