[Dubov 0]

Задача: сделать так, чтобы ядро при загрузке увидело раздел /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?

Изменено 1 октября, 2014 пользователем Dubov

[krux 8]

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

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

[Dubov 0]

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

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

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

 

# Boot the real thing.

exec switch_root /mnt/root /sbin/init

 

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

Изменено 1 октября, 2014 пользователем Dubov

[krux 8]

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)

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

[Dubov 0]

вы правы.

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

[krux 8]

если в двух словах, то любой 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 и вечный головняк с загрузкой.

[Dubov 0]

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

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

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

 

 

[krux 8]

А откуда возьмётся /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

[Dubov 0]

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

во-первых есть внутренняя кухня ядра (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!

 

 

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

Изменено 2 октября, 2014 пользователем Dubov