Jump to content

    

initramfs "не уходит"

Задача: сделать так, чтобы ядро при загрузке увидело раздел /dev/mmcblk0p1, смонтировало его как корневую файловую систему.

 

С наскока такое сделать не получилось. Если писать в строке параметров загрузки "root=/dev/mmcblk0p1", то ядро ругается так:

 

VFS: Cannot open root device "mmcblk0p1" or unknown-block(0,0)

Please append a correct "root=" boot option; here are the available partitions:

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

 

 

Понимаю, что нужно как-то смонтировать mmc-карту(иначе /dev/mmcblk0p1 просто не появится) перед тем как запускать инициализацию файловой системы. Узнал, что для этого используется initramfs. Тут я совсем новичок.

Включил в ядре поддержку initramfs:

 

CONFIG_INITRAMFS_SOURCE="./initramfs-list-min"

CONFIG_INITRAMFS_ROOT_UID=0

CONFIG_INITRAMFS_ROOT_GID=0

# CONFIG_INITRAMFS_IS_LARGE is not set

CONFIG_RD_GZIP=y

# CONFIG_RD_BZIP2 is not set

# CONFIG_RD_LZMA is not set

# CONFIG_RD_LZO is not set

CONFIG_INITRAMFS_COMPRESSION_NONE=y

 

в файле "initramfs-list-min" по мимо всего прочего создал ноду /dev/mmcblk0p1 и /dev/mmcblk0

 

После запуска, ядро нашло /dev/mmcblk0p1 и даже стало ждать присоединения карты, если в строке загрузке написать rootwait. Ну, думаю, нашлась корневая файловая система...

Но, после успешной загрузки ядра и входа в систему, я понял, что в корневой файловой системе присутствует толкьо тот минимум папок, что был в initramfs, а всё многообразие полноценной файловой системы на mmc система просто проигнорировала как корневую файловую систему, при это ниразу не ругнувшись.

Выходит просто root=/dev/mmcblk0p1 не достатачно для загрузки рутовой с mmc.

Как именно должно происходить монтирование полноценной файловой системы после initramfs?

Edited by Dubov

Share this post


Link to post
Share on other sites

а что за плата? кит или самоделка?

если самоделка то надо ещё настройки PINMUXа в ядро зашить.

Share this post


Link to post
Share on other sites

c PINMUX всё впорядке. карточка же определяется, запис/чтение идёт нормально. Беда в том что сейчас монтируется initramfs и система так и не переключается на файловую систему карты.

читаю это http://wiki.gentoo.org/wiki/Custom_Initramfs#Init

подозреваю, что у меня скрипт init не правильно настроен. в конце он должен передать

 

# Boot the real thing.

exec switch_root /mnt/root /sbin/init

 

буду пробовать вкомпилить свой initramfs в ядро

Edited by Dubov

Share this post


Link to post
Share on other sites
c PINMUX всё впорядке. карточка же определяется, запис/чтение идёт нормально.

это не аргумент.

на ките например помимо разъёма для SD ещё распаяна микросхема eMMC.

У нас человек очень сильно удивлялся, когда обнаружил что при выставленной загрузке с SD-шки u-boot и ядро грузились те самые, а в качестве rootfs цеплялся не раздел с карточки, а раздел с распаянной микросхемы.

"И куда это делись мои файлы??? я же их только что туда записал!!1 с компа же всё правильно видно, вот они"

 

нумерация в u-boot и нумерация устройств в linux совпадать не обязаны.

 

 

exec switch_root /mnt/root /sbin/init

тогда уж лучше сразу man chroot, но перед этим у вас должен быть смонтирован раздел /dev/mmcblk0p1 или какой он там.

а судя по

VFS: Cannot open root device "mmcblk0p1" or unknown-block(0,0)

он у вас не монтируется. вот с этим и надо разбираться в первую очередь.

Share this post


Link to post
Share on other sites

вы правы.

монтированием mmcblk0p1 должен заниматься init.

Share this post


Link to post
Share on other sites

если в двух словах, то любой init из состава initramfs будет содержать

modprobe -a
mkdir /chroot
mount /dev/mmcblk0p1 /chroot
chroot /chroot /sbin/init

т.е. ничего нового, что могло бы вам помочь.

под словом "разбираться" я имел в виду почему не срабатывает опция ядра root=/dev/mmcblk0p1

 

зы. я честно говоря не понимаю зачем вам вообще initrd.

в классических дистрибутивах Linux он нужен был для загрузки со всяких экзотических scsi raid-контроллеров, или вообще через PXE.

Потому что ядро собиралось с модулями, а не монолитом. Потому как драйверы в модулях это отличное решение для установки на компы любых конфигураций. С расчетом что загружены будут только необходимые.

Вот все нужные модули ядра aka драйверы на этапе initrd и загружались.

А зачем для embedded-системы делать модули? они же все известны, и всё равно будут загружены все, и никакого выигрыша по памяти, занимаемой ядром не будет.

Только лишняя работа по поддержанию initrd и вечный головняк с загрузкой.

Share this post


Link to post
Share on other sites

не знаю зачем тут initrd.

У меня все драйверы впорядке и вкомпилены в ядро. Просто во время загрузки линукс не схватывал /dev/mmcblk0p1. А откуда возьмётся /dev/mmcblk0p1 если его не создать через initrd на самом раннем этапе?

Завтра попробую создать новую initramfs и подсунуть ядру.

 

 

Share this post


Link to post
Share on other sites
А откуда возьмётся /dev/mmcblk0p1 если его не создать через initrd

тут надо разделить мух и котлеты.

во-первых есть внутренняя кухня ядра (kernelspace), и сами названия вида /dev/mmcblk0p1 уже вкомпилены в ядро. Но при этом наружу эти названия не светятся. При использовании в качестве параметров ядра используются именно они. "Создавать" их когда ядро уже загружено - масло масляное.

во-вторых есть файловая система и на запрос ls /dev выдается именно то что указано в файловой системе (userspace). содержимое ФС может отличатсья от строк с названиями /dev в ядре.

Для сопоставления и общения kernelspace<->userspace используются Major number и Minor number devices.txt

вручную сопоставить /dev-устройство файлу можно командой mknod

mknod /dev/mmcblk0p1 179 1

создаст соответствующий файл.

динамически создавать нужные файлы в /dev умеет udev

Share this post


Link to post
Share on other sites
тут надо разделить мух и котлеты.

во-первых есть внутренняя кухня ядра (kernelspace), и сами названия вида /dev/mmcblk0p1 уже вкомпилены в ядро.

как именно они вкомпилены? какие опции конфига ядра нужно включить? всё что касается MMC у меня включено. /dev/mmcblk0p1 само собой не появляется.

 

создал initramfs, вот init:

 

#!/bin/busybox sh

# Mount the /proc and /sys filesystems.
mount -t proc none /proc
mount -t sysfs none /sys
mknod /dev/console c 5 1
mknod /dev/tty c 5 0
mknod /dev/null c 1 3
mknod /dev/mem c 1 1
mknod /dev/kmem c 1 2
mknod /dev/ttyS0 c 4 64
mknod /dev/ttyS1 c 4 65
mknod /dev/ttyS2 c 4 66
mknod /dev/mmcblk0 b 179 0
mknod /dev/mmcblk0p1 b 179 1

chmod 777 /dev/console
chmod 777 /dev/tty
chmod 777 /dev/ttyS0
chmod 700 /dev/mmcblk0
chmod 700 /dev/mmcblk0p1

# Do your stuff here.
echo "This script mounts rootfs and boots it up, nothing more!"

# Mount the root filesystem.
mount -o rw /dev/mmcblk0p1 /mnt/root || rescue_shell

# Clean up.
umount /proc
umount /sys

# Boot the real thing.
exec switch_root /mnt/root /sbin/init

rescue_shell() {
   echo "Something went wrong. Dropping you to a shell."
   busybox --install -s
   exec /bin/sh
}

 

 

 

вот строка загрузки ядра:

root=/dev/mmcblk0p1 rw rootwait init=init

 

Вот вывод консоли ядра:

 

mmci-pl18x mmci0: mmc0: MMCI rev 4 cfg 10 at 0x0000000040012c00 irq 49,-1

sdhci: Secure Digital Host Controller Interface driver

sdhci: Copyright© Pierre Ossman

ARMv7-M VFP Extension supported

Freeing init memory: 16K

Warning: unable to open an initial console.

mmc0: host does not support reading read-only switch. assuming write-enable.

mmc0: new SD card at address 0002

mmcblk0: mmc0:0002 00000 1.86 GiB

mmcblk0:

p1

Kernel panic - not syncing: Attempted to kill init!

 

 

думаю дальше...

Edited by Dubov

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this