Embedded linux bootstraping, ликбез Опции

[3.14]

Начало обсуждения здесь: http://electronix.ru/forum/index.php?showtopic=33796
Т.е. на данный момент, моя железяка после загрузки ядра пытается смонтировать корневую через NFS (насколько я понимаю).
Начитавшись этого http://www.opennet.ru/base/sys/initrd_intro.txt.html я окончательно запутался.
Здесь инструкции по сборке и запуску линуха на колибри: http://www.vollmann.net/colibri/colibri-bs...ing-started.txt
Там ни слова не говорится о initrd файловой системе ...
Прокомментируйте плиз следующие инструкции по сборке ядра линуха:

$ arm-linux-objcopy -O binary -R .note -R .comment -S vmlinux linux.bin
$ gzip -c -9 linux.bin > linux.bin.gz
$ $PROJECT/colibri-bsp-x.x/bin/mkimage -A arm -O linux -T kernel -C gzip \
-a 0xa0008000 -e 0xa0008000 -n "Linux Kernel Image" -d linux.bin.gz uImage

[amw]

$ arm-linux-objcopy -O binary -R .note -R .comment -S vmlinux linux.bin

При линковке получается ELF файл который можно запускать из какой нибудь среды, чаще всего эта среда - ОС. При загрузке ОС никакой среды нет. Эта стройчка создает бинарный образ пригодный для прямого запуска. Ну типа HEX файл для микроконтроллера, только бинарник.

$ gzip -c -9 linux.bin > linux.bin.gz

А здесь образ сжимается. Ядро - это самораспаковывающийся архив.

$ $PROJECT/colibri-bsp-x.x/bin/mkimage -A arm -O linux -T kernel -C gzip \
-a 0xa0008000 -e 0xa0008000 -n "Linux Kernel Image" -d linux.bin.gz uImage

А это, как я понимаю, из полученного сжатоо бинарного образа ядра создается образ пригодный для загрузки с помощью uBoot. Этот образ содержит дополнительную информацию, которую обрабатывает uBoot. Часть из этой информации uBoot передает ядру при запуске в виде параметров комендной строки, часть использует сам (например адреса).
Сам с uBoot не работал, но большинство embedded/network загрузчиков это делают.

Начитавшись этого http://www.opennet.ru/base/sys/initrd_intro.txt.html я окончательно запутался.

initrd - виртуальный диск, размещаемый в памяти и загружаемый туда загрузчиком вместе с ядром до старта ядра. Ядро потом его находит, распаковывает и монтирует как корневую файловую систему.
От ramdisk он отличается тем, что загружается в память загрузчиком а не ядром. Собственно initrd - это ramdisk загружаемый до запуска ядра.
Создается он вручную достаточно просто. Всякие утилиты типа mkinitrd предназначены для конфигурационно-восстановительных действий применительно к КОНКРЕТНОМУ ДИСТРИБУТИВУ.
Если нужны подробности по initrd - спрашивайте.

Сообщение отредактировал amw - Jul 17 2007, 08:26

[3.14]

Спасибо.
В общем, корневуху на NOR флешку я разместил и теперь линух нормально грузится ...
На данный момент имею следуюшие аргументы загрузки ядра: noinitrd root=/dev/mtdblock2 rootfstype=jffs2 ip=:::::eth0: console=ttyS0,115200n8
Но в последствии, на своей железяке, у меня будет маленькая NOR флешка (4Мбайт), соответственно развесистая корневуха не по силам (да и ни к чему, всего одно приложение крутится будет). Т.е. для моего случая идеальный вариант это небольшой виртуальный диск (initrd) на котором и будет корневуха с моим приложением. Отсюда вопрос, как это организовать?
Допустим я соберу образ этого виртуального диска по этим инструкциям http://www.opennet.ru/base/sys/initrd_intro.txt.html , но какие аргументы загрузки ядра тогда должны быть при этом?
Еще, откуда (на данный момент) ядро знает что устройство /dev/mdtblock находится по адресу 0x480000 (из BSP платы)?

[3.14]

Собрал образ ramdisk, по следующему скрипту:

Код

#!/bin/sh
RDSIZE=4000
BLKSIZE=1024

dd if=/dev/zero of=./ramdisk.img bs=$BLKSIZE count=$RDSIZE

/sbin/mke2fs -F -m 0 -b $BLKSIZE ./ramdisk.img $RDSIZE

mount ./ramdisk.img ./mnt -t ext2 -o loop=/dev/loop0

mkdir ./mnt/bin
mkdir ./mnt/sys
mkdir ./mnt/dev
mkdir ./mnt/proc

cp ./busybox ./mnt/bin/busybox
pushd ./mnt/bin
ln -s busybox ash
ln -s busybox mount
ln -s busybox echo
ln -s busybox ls
ln -s busybox cat
ln -s busybox ps
ln -s busybox dmesg
ln -s busybox sysctl
popd

cp -a /dev/console ./mnt/dev
cp -a /dev/ramdisk ./mnt/dev
cp -a /dev/ram0 ./mnt/dev
cp -a /dev/null ./mnt/dev
cp -a /dev/tty1 ./mnt/dev
cp -a /dev/tty2 ./mnt/dev

pushd ./mnt
ln -s bin sbin
popd

cat >> ./mnt/linuxrc << EOF
#!/bin/ash
echo
echo "Simple initrd is active"
echo
mount -t proc /proc /proc
mount -t sysfs none /sys
/bin/ash --login
EOF

chmod +x ./mnt/linuxrc

umount ./mnt
#gzip -9 ./ramdisk.img

затем:

Код

#!/bin/sh
./mkimage -A arm -O linux -T ramdisk -C gzip -a 0xa1000000 -e 0xa1000000 -n "Initial RAM disk image" -d ramdisk.img.gz ramdisk

Аргументы запуска ядра:root=/dev/ram0 rw initrd=0xa1000000,0x400000 ramdisk_size=4000 console=ttyS0,115200n8 mem=16M

В итоге, ядро все равно в панике, не может смонтировать "ram0" or unknown-block(2,0).
Не понятно, u-boot-у нужно говорить что перед загрузкой ядра загрузить рамдиск?
В логах обычной загрузки про рамдиск ни слова ...
Я пробовал в ручную, после загрузки u-boot, принудительно загрузть образ рамдиск "bootm 48000" а после этого стартонуть ядро, ничего не меняется.

[S_agent]

Еще, откуда (на данный момент) ядро знает что устройство /dev/mdtblock находится по адресу 0x480000 (из BSP платы)?

У него драйвер для этого специальный есть см. kernel-source/drivers/mtd

Но в последствии, на своей железяке, у меня будет маленькая NOR флешка (4Мбайт), соответственно развесистая корневуха не по силам (да и ни к чему, всего одно приложение крутится будет). Т.е. для моего случая идеальный вариант это небольшой виртуальный диск (initrd) на котором и будет корневуха с моим приложением. Отсюда вопрос, как это организовать?

для c построения rootfs используйте buildroot после конфигурации он сам скачивает необходимые компоненты и компилит их, результатом компиляции будет необходимый Вам rootfs в разных форматах. Для initrd необходим загзипеный ext2 образ рамдиска.
загзипеный минимальный набор - порядка 2 Мб, это при условии что шеллом будет ash и не будет ncurses и многого другого тоже + ядро порядка 1Мб - в 4Мб влезете.
Судя по Вашим записям у Вас есть 16Мб RAM посему можете сконфигурить размер рамдиска 8Мб
(распакованый образ +- столько и будет) а остальные отдать системе
root=/dev/ram0 rw initrd=0xa1000000,0x400000 ramdisk_size=8192 console=ttyS0,115200n8 mem=16M

И еще, не забудьте, что рамдиск после перезагрузки переинитится наново, тоесть все изменения не будут сохраняться. Если необходимо сохранение, используйте тот самый mtd как отдельный раздел с jffs2.

[S_agent]

В итоге, ядро все равно в панике, не может смонтировать "ram0" or unknown-block(2,0).
Не понятно, u-boot-у нужно говорить что перед загрузкой ядра загрузить рамдиск?
В логах обычной загрузки про рамдиск ни слова ...
Я пробовал в ручную, после загрузки u-boot, принудительно загрузть образ рамдиск "bootm 48000" а после этого стартонуть ядро, ничего не меняется.

При загрузке ядра есть сообщение типа: ?
RAMDISK: Compressed image found at block 0

Если Вы ядру указываете initrd=0xa1000000, то и
u-boot-ом рамдиск нужно грузить по адресу 0xa1000000

[PsM]

Если используешь ядро 2.6 я бы посоветовал использовать для рута initramfs и tmpfs вместо ramdisk-а (initrd).
Так можно Будет сэкономить некоторое количество ram-а
подробности можно почитать тут:
http://teleology.ru/projects_ru/informatic...ru/initramfs_ru

[3.14]

2 S_agent.
В том то и дело, что никаких сообщений о рамдиск при загрузке не возникает.
Сейчас у меня во флешке находятся два образа: 1) линух по адресу 0х80000, 2)рамдиск по адресу 0х480000.
U-boot bootcmd="bootm 80000 || dhcp && bootm"
Наверное надо чего-то добавить в bootcmd ...
Если предварительно дать команду bootm 480000, то образ рамдиска переписывается по адресу 0xa1000000, но дает сообщение "Wrong Image Type for bootm command", хотя как можно видеть из вышеприводимого листинга тип я при сборке рамдиска указываю (-T ramdisk).

2 PsM
Это, конечно, правильно, но с initrd мне тоже надо разобраться.

Насчет адресов.
На колибри стоит 64М (на моей тоже будет столько же).
SDRАM начинается с 0ха0000000
Само ядро располагается по 0ха0008000 (ниже, видимо загрузчик лежит)
Для меньшей вероятности ошибки, расположил образ рамдиска не в верху SDRAM а по середине и обрезал память для линуха.

[S_agent]

3.14, почитайте вот это, там все необходимые действия описаны, сверьте со своими.

[amw]

2 S_agent.
В том то и дело, что никаких сообщений о рамдиск при загрузке не возникает.
Сейчас у меня во флешке находятся два образа: 1) линух по адресу 0х80000, 2)рамдиск по адресу 0х480000.
U-boot bootcmd="bootm 80000 || dhcp && bootm"
Наверное надо чего-то добавить в bootcmd ...
Если предварительно дать команду bootm 480000, то образ рамдиска переписывается по адресу 0xa1000000, но дает сообщение "Wrong Image Type for bootm command", хотя как можно видеть из вышеприводимого листинга тип я при сборке рамдиска указываю (-T ramdisk).

2 PsM
Это, конечно, правильно, но с initrd мне тоже надо разобраться.

Насчет адресов.
На колибри стоит 64М (на моей тоже будет столько же).
SDRАM начинается с 0ха0000000
Само ядро располагается по 0ха0008000 (ниже, видимо загрузчик лежит)
Для меньшей вероятности ошибки, расположил образ рамдиска не в верху SDRAM а по середине и обрезал память для линуха.

Не забудте указать в конфигурации ядра (make menuconfig) в блочных устройствах поддержку ramdisk и initrd в ЯДРЕ, НЕ МОДУЛЕМ.

[3.14]

Итак, начал ковыряться с самодельной железякой на PXA270, стоит 128М SDRAM и 4M NOR флеши.
Пытаюсь подмонтировать корневуху через рамдиск (полученый описаным выше скриптом) получаю следующее:

Код

u-boot$ imls
Image at 00060000:
   Image Name:   Linux Kernel Image
   Created:      2007-08-31   7:21:49 UTC
   Image Type:   ARM Linux Kernel Image (gzip compressed)
   Data Size:    1064735 Bytes =  1 MB
   Load Address: a0008000
   Entry Point:  a0008000
   Verifying Checksum ... OK
Image at 001E0000:
   Image Name:   Initial RAM disk image
   Created:      2007-07-13   3:54:11 UTC
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    282752 Bytes = 276.1 kB
   Load Address: a1000000
   Entry Point:  a1000000
   Verifying Checksum ... OK
u-boot$ cp.b 1e0000 a1000000 60000
u-boot$ boot
## Booting image at 00060000 ...
   Image Name:   Linux Kernel Image
   Created:      2007-08-31   7:21:49 UTC
   Image Type:   ARM Linux Kernel Image (gzip compressed)
   Data Size:    1064735 Bytes =  1 MB
   Load Address: a0008000
   Entry Point:  a0008000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK

Starting kernel ...

Linux version 2.6.12.4-col2 (pi@linuxServer) (gcc version 3.3.2) #5 Fri Aug 31 12:21:25 SAMST 2007
CPU: XScale-PXA270 [69054117] revision 7 (ARMv5TE)
CPU0: D VIVT undefined 5 cache
CPU0: I cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets
CPU0: D cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets
Machine: Toradex Colibri Module
Ignoring unrecognised tag 0x00000000
Ignoring unrecognised tag 0x00000000
Memory policy: ECC disabled, Data cache writeback
Run Mode clock: 208.00MHz (*16)
Turbo Mode clock: 520.00MHz (*2.5, active)
Memory clock: 208.00MHz (/2)
System bus clock: 208.00MHz
Built 1 zonelists
Kernel command line: root=/dev/ram0 rw initrd=0xa1000000,0x400000 ramdisk_size=4000 console=ttyS0,115200n8 mem=128M
PID hash table entries: 1024 (order: 10, 16384 bytes)
Console: colour dummy device 80x30
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 128MB = 128MB total
Memory: 123392KB available (1829K code, 361K data, 92K init)
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
checking if image is initramfs...it isn't (bad gzip magic numbers); looks like an initrd
Freeing initrd memory: 4096K
NET: Registered protocol family 16
SCSI subsystem initialized
usbcore: registered new driver hub
NetWinder Floating Point Emulator V0.97 (double precision)
JFFS2 version 2.2. (C) 2001-2003 Red Hat, Inc.
ttyS0 at MMIO 0x40100000 (irq = 22) is a FFUART
ttyS1 at MMIO 0x40200000 (irq = 21) is a BTUART
ttyS2 at MMIO 0x40700000 (irq = 20) is a STUART
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 16 RAM disks of 4000K size 1024 blocksize
PPP generic driver version 2.4.2
dm9000 Ethernet Driver
dm9000: read wrong id 0x2b2a2928
dm9000: read wrong id 0x2b2a2928
dm9000: wrong id: 0x2b2a2928
dm9000: not found (0).
Probing Colibri flash at physical address 0x00000000 (16-bit buswidth)
Colibri flash: Found 1 x16 devices at 0x0 in 16-bit bank
Intel/Sharp Extended Query Table at 0x0031
Using buffer write method
cfi_cmdset_0001: Erase suspend on write enabled
Creating 3 MTD partitions on "Colibri flash":
0x00000000-0x00060000 : "Bootloader"
0x00060000-0x001e0000 : "Kernel"
0x001e0000-0x00400000 : "Filesystem"
usbmon: debugs is not available
Setting port 3 power failed.
pxa27x-ohci pxa27x-ohci: PXA27x OHCI
pxa27x-ohci pxa27x-ohci: new USB bus registered, assigned bus number 1
pxa27x-ohci pxa27x-ohci: irq 3, io mem 0x4c000000
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
Initializing USB Mass Storage driver...
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.01:USB HID core driver
mice: PS/2 mouse device common for all mice
NET: Registered protocol family 2
IP: routing cache hash table of 1024 buckets, 8Kbytes
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
NET: Registered protocol family 1
RAMDISK: Couldn't find valid RAM disk image starting at 0.
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)

Интересно, чего его мой RAMDISK не устраивает ...

[amw]

u-boot$ boot
## Booting image at 00060000 ...
Image Name: Linux Kernel Image
Created: 2007-08-31 7:21:49 UTC
Image Type: ARM Linux Kernel Image (gzip compressed)
Data Size: 1064735 Bytes = 1 MB
Load Address: a0008000
Entry Point: a0008000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK

А рамдиск где грузится в память?

Интересно, чего его мой RAMDISK не устраивает ...

А /dev/ram0 на рамдиске есть?

Я пользуюсь RedBoot-ом, там сначала грузится рамдиск, потом ядро, потом запуск ядра. Это отдельные команды redboot, которые сохраняются в скрипт для автоматизации.

[3.14]

А рамдиск где грузится в память?

Перед запуском ядра, "руками" копирую рамдиск "u-boot$ cp.b 1e0000 a1000000 60000"

А /dev/ram0 на рамдиске есть?

Есть.
Далее ... у меня логика такая же, чего то видимо с генерированием рамдиска ... делаю его этим http://www.opennet.ru/base/sys/initrd_intro.txt.html скриптом.

[amw]

Перед запуском ядра, "руками" копирую рамдиск "u-boot$ cp.b 1e0000 a1000000 60000"
Есть.
Далее ... у меня логика такая же, чего то видимо с генерированием рамдиска ... делаю его этим http://www.opennet.ru/base/sys/initrd_intro.txt.html скриптом.

Меня смущает использование cpio в этой статье. Это дополнительное, необязательное действие.
Попробуйте попроще.

Код

dd if=/dev/zero of=initrd.img bs=1024 count=4096
mke2fs -F initrd.img
mkdir imnt
mount -t ext2 initrd.img imnt -oloop
Тут копируем в imnt все что нужно, создаем /dev ит.д.
........
umount imnt
gzip -c < initrd.img > initrd.gz

Теперь initrd.gz содержит все, что Вам нужно, используйте его.
Коментарии по командам нужны?
Посмотрите в исходниках ядра Documentation/ramdisk.txt и Documentation/initrd.txt

Сообщение отредактировал amw - Sep 3 2007, 07:14

[3.14]

Странно, если образ рамдиска не GZIP-ить, тогда ядро его находит ...

Оказывается, это я упустил момент - "руками" я копирую не только образ рамдиска, но и заголовок от u-boot, т.е. нужно либо средствами u-boot копировать (не простым копированием) либо сохранять образ без заголовка для загрузчика.