Задача: сделать так, чтобы ядро при загрузке увидело раздел /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?
Полная версия этой страницы: initramfs "не уходит"
Форум разработчиков электроники ELECTRONIX.ru > Cистемный уровень проектирования > Операционные системы > Linux
а что за плата? кит или самоделка?
если самоделка то надо ещё настройки PINMUXа в ядро зашить.
если самоделка то надо ещё настройки PINMUXа в ядро зашить.
c PINMUX всё впорядке. карточка же определяется, запис/чтение идёт нормально. Беда в том что сейчас монтируется initramfs и система так и не переключается на файловую систему карты.
читаю это http://wiki.gentoo.org/wiki/Custom_Initramfs#Init
подозреваю, что у меня скрипт init не правильно настроен. в конце он должен передать
# Boot the real thing.
exec switch_root /mnt/root /sbin/init
буду пробовать вкомпилить свой initramfs в ядро
читаю это http://wiki.gentoo.org/wiki/Custom_Initramfs#Init
подозреваю, что у меня скрипт init не правильно настроен. в конце он должен передать
# Boot the real thing.
exec switch_root /mnt/root /sbin/init
буду пробовать вкомпилить свой initramfs в ядро
Цитата
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)
он у вас не монтируется. вот с этим и надо разбираться в первую очередь.
вы правы.
монтированием mmcblk0p1 должен заниматься init.
монтированием mmcblk0p1 должен заниматься init.
если в двух словах, то любой init из состава initramfs будет содержать
т.е. ничего нового, что могло бы вам помочь.
под словом "разбираться" я имел в виду почему не срабатывает опция ядра root=/dev/mmcblk0p1
зы. я честно говоря не понимаю зачем вам вообще initrd.
в классических дистрибутивах Linux он нужен был для загрузки со всяких экзотических scsi raid-контроллеров, или вообще через PXE.
Потому что ядро собиралось с модулями, а не монолитом. Потому как драйверы в модулях это отличное решение для установки на компы любых конфигураций. С расчетом что загружены будут только необходимые.
Вот все нужные модули ядра aka драйверы на этапе initrd и загружались.
А зачем для embedded-системы делать модули? они же все известны, и всё равно будут загружены все, и никакого выигрыша по памяти, занимаемой ядром не будет.
Только лишняя работа по поддержанию initrd и вечный головняк с загрузкой.
Код
modprobe -a
mkdir /chroot
mount /dev/mmcblk0p1 /chroot
chroot /chroot /sbin/init
mkdir /chroot
mount /dev/mmcblk0p1 /chroot
chroot /chroot /sbin/init
т.е. ничего нового, что могло бы вам помочь.
под словом "разбираться" я имел в виду почему не срабатывает опция ядра root=/dev/mmcblk0p1
зы. я честно говоря не понимаю зачем вам вообще initrd.
в классических дистрибутивах Linux он нужен был для загрузки со всяких экзотических scsi raid-контроллеров, или вообще через PXE.
Потому что ядро собиралось с модулями, а не монолитом. Потому как драйверы в модулях это отличное решение для установки на компы любых конфигураций. С расчетом что загружены будут только необходимые.
Вот все нужные модули ядра aka драйверы на этапе initrd и загружались.
А зачем для embedded-системы делать модули? они же все известны, и всё равно будут загружены все, и никакого выигрыша по памяти, занимаемой ядром не будет.
Только лишняя работа по поддержанию initrd и вечный головняк с загрузкой.
не знаю зачем тут initrd.
У меня все драйверы впорядке и вкомпилены в ядро. Просто во время загрузки линукс не схватывал /dev/mmcblk0p1. А откуда возьмётся /dev/mmcblk0p1 если его не создать через initrd на самом раннем этапе?
Завтра попробую создать новую initramfs и подсунуть ядру.
У меня все драйверы впорядке и вкомпилены в ядро. Просто во время загрузки линукс не схватывал /dev/mmcblk0p1. А откуда возьмётся /dev/mmcblk0p1 если его не создать через initrd на самом раннем этапе?
Завтра попробую создать новую initramfs и подсунуть ядру.
Цитата
А откуда возьмётся /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
Цитата(krux @ Oct 2 2014, 00:08) 
тут надо разделить мух и котлеты.
во-первых есть внутренняя кухня ядра (kernelspace), и сами названия вида /dev/mmcblk0p1 уже вкомпилены в ядро.
во-первых есть внутренняя кухня ядра (kernelspace), и сами названия вида /dev/mmcblk0p1 уже вкомпилены в ядро.
как именно они вкомпилены? какие опции конфига ядра нужно включить? всё что касается MMC у меня включено. /dev/mmcblk0p1 само собой не появляется.
создал initramfs, вот init:
CODE
#!/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
}
# 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!
думаю дальше...
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.