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 копировать (не простым копированием) либо сохранять образ без заголовка для загрузчика.

[amw]

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

Ммм... Никогда не пробовал не GZIP-ить.
Мож чего в uboot надо сказать по поводу GZIP? Ну или при создания образа для uboot?

Как вариант пользуйте непакованный и разберитесь с initramfs. Оно конечно ядро перелинковывать каждый раз при изменении файловой системы не ахти как удобно, но типа рекомендуемый путь.

[3.14]

Спасибо, нашел причину ошибочной загрузки образа, см. предыдущее сообщение (рассинхронизировались сообщения на форуме).

[amw]

К стати не понял что за второй параметр у initrd=0xa1000000,0x400000

Kernel command line: root=/dev/ram0 rw initrd=0xa1000000,0x400000 ramdisk_size=4000 console=ttyS0,115200n8 mem=128M

Из kernel-parameters.txt

initrd= [BOOT] Specify the location of the initial ramdisk

Что указано после запятой?

[3.14]

Сам пока не понял
Чего то еще не то ... ядро упорно говорит что не может init найти (он лежит в корне рамдиска - linuxrc) я уж и init=/linuxrc параметр для ядра добавил, а все равно не видит ...

[3.14]

Уперся ...
В качестве init (linuxrc) у меня ash скрипт работающий через busybox, bysybox я сам не собирал я взял из корневухи для платы colibri (процессор такой же).
Если при загрузке пытаться этот скрипт запустить (linuxrc), получаю следующее

RAMDISK: Compressed image found at block 0
VFS: Mounted root (ext2 filesystem).
Freeing init memory: 92K
Kernel panic - not syncing: No init found. Try passing init= option to kernel.

Заглянув в тело самого busybox, заметил строчку "/lib/ld-linux.so.2", из чего сделал вывод, что бузибокс собран не статически и добавил в образ своего рамдиска директорию lib и эту самую библиотеку (из корневухи для colibri), получаю:

RAMDISK: Compressed image found at block 0
VFS: Mounted root (ext2 filesystem).
Freeing init memory: 92K
/bin/ash: error while loading shared libraKernel panic - not syncing: Attempted
to kill init!
ries: libm.so.6: cannot open shared object file: No such file or directory

Добавляю в lib libm.so.6, получаю:

RAMDISK: Compressed image found at block 0
RAMDISK: ran out of compressed data
invalid compressed format (err=1)
VFS: Mounted root (ext2 filesystem).
Freeing init memory: 92K
EXT2-fs error (device ram0): ext2_check_page: bad entry in directory #14: rec_len is smaller than minimal - offset=0, inode=0, rec_len=0, name_len=0
Warning: unable to open an initial console.
EXT2-fs error (device ram0): ext2_check_page: bad entry in directory #12: rec_len is smaller than minimal - offset=0, inode=0, rec_len=0, name_len=0
Kernel panic - not syncing: No init found. Try passing init= option to kernel.

[3.14]

Еще, если попробовать залить не GZIP-нутый образ рамдиска (с двумя либами), получаетяс:

RAMDISK: ext2 filesystem found at block 0
RAMDISK: Loading 4000KiB [1 disk] into ram disk... done.
VFS: Mounted root (ext2 filesystem).
Freeing init memory: 92K
EXT2-fs error (device ram0): ext2_check_page: bad entry in directory #14: directory entry across blocks - offset=0, inode=3844988932, rec_len=12556, name_len=159
Warning: unable to open an initial console.
Kernel panic - not syncing: No init found. Try passing init= option to kernel.

Заметьте, появилась строка "RAMDISK: Loading 4000KiB [1 disk] into ram disk... done."

[amw]

Чтобы не заморачиватся с либами на этапе загрузки лучше пересоберите busybox статически. У меня динамический так и не пошел. Не знаю, чего ему точно не хватило, но busybox всегда использую статический.
"Loading 4000KiB [1 disk] into ram disk" - это потому что не GZIP-леный. Ядро его копирует в удобный участок памяти (туда, где отмаллочился ramdisk). Если GZIP-леный, то распаковывается прямо на место.
Перепроверте соответствие размеров рамдиска параметрам, укажите 4096 вместо 4000. ramdisk_size указывается для распакованного образа.
В соответствии с рекомендацией на загрузчики Linux GZIPленный initrd нужно размещать по адресу 16M - sizeof(initrd). Правда могу ошибатся на счет 16M - эта цифра зависима от архитектуры.

Только что посмотрел, нашел рекомендации для x86 в Documentation/i386/boot.txt.
Для ARM вроде нет указаний куда грузить initrd.
Думаю, что initrd лучше разместить в притык к концу памяти, то есть
по адресу = размер памяти - размер GZIP-ленного initrd. С учетом memory map конечно.

Добавляю в lib libm.so.6, получаю:

Этого по идее не достаточно.
Нужно, по крайней мере, всю libc на initrd закатать. Со всеми ссылками. В качестве перчня можно посмотреть на PC. Набор библиотек тот-же.
Вероятно нужно libiconv еще.

В качестве init (linuxrc)

Обычно
/linuxrc -> симлинк на /bin/init
/bin/init -> симлинк на /bin/busybox
Можно и ash скрипт, ситуацию с библиотеками это не маняет.

[amw]

В дополнение,
Поскольку ldd не работает в кросс-варианте, используйте objdump (от кросс-компиллятора) для определения необходимых библиотек.

Код

arm-linux-objdump -x bin/bash
...... Тут много всякого, найдите седующее:
Dynamic Section:
  NEEDED      libtermcap.so.2
  NEEDED      libdl.so.2
  NEEDED      libc.so.6
...... Тут еще много всякого

arm-linux- - это для примера - разумеется используйте Ваш вариант именования crosstools.

[3.14]

Итак ... взял образ рамдиска отсюда http://heavy-online.ru/arm-linux/ .
На удивление, все заработало, теперь пошли общие вопросы.
Скачал более свежий busybox, насколько я понимаю, если я его собираю (make CROSS_COMPILE=arm-linux-), то при сборе он использует либу glib, причем для x86?
По крайней мере, все попытки запустить на моем девайсе самодельно собранный бузибокс закончились неудачей, пробовал и статически собирать и ... .
Новую либу тоже надо кросс компилятором собрать?

Еще, мне надо как то Z-modem к моему хозяйству прикрутить, чтоб начать ковырятся с драйвером NAND флешки (иначе тонны времени потрачу на обновлении корневухи).

Какие могут возникнуть минусы, если пользоваться uClib?
Думаю, стоит ли бузибокс с uClib собирать ...
Скачал uClib, собирается если указать процессор i386, если указать ARM, вываливается с криком:

./extra/scripts/conf-header.sh .config > include/bits/uClibc_config.h
cc1: error: invalid option `little-endian'
cc1: error: invalid option `little-endian'
CC ldso/ldso/ldso.oS
cc1: error: invalid option `little-endian'
make: *** [ldso/ldso/ldso.oS] Ошибка 1

Причем от настройки индианы это не зависит.

[amw]

Итак ... взял образ рамдиска отсюда http://heavy-online.ru/arm-linux/ .
На удивление, все заработало, теперь пошли общие вопросы.
Скачал более свежий busybox, насколько я понимаю, если я его собираю (make CROSS_COMPILE=arm-linux-), то при сборе он использует либу glib, причем для x86?
По крайней мере, все попытки запустить на моем девайсе самодельно собранный бузибокс закончились неудачей, пробовал и статически собирать и ... .
Новую либу тоже надо кросс компилятором собрать?

Надо собрать кросс-компилятор, потом этим кросс-компилятором собрать glibc.
Прописать в PATH путь к кросс-компилятору ВПЕРЕДИ остальных путей.
Что-то на подобие:

Код

cd glibc-2.3.6
configure --target=arm-linux host=arm-linux build=i686-pc-linux-gnu

Само собой, надо указать Ваш "arm-linux"
Для сравнения у меня под big-endian для IXP425 - это armv5b-softfloat-linux
Вообще-то лучше всего взять crosstools http://kegel.com
Там очень просто настраивается три файла, собирает все, начиная от binutils и заканчивая gdb.
У busybox есть конфигуратор, как в ядре. Запускается по make menuconfig.

Еще, мне надо как то Z-modem к моему хозяйству прикрутить, чтоб начать ковырятся с драйвером NAND флешки (иначе тонны времени потрачу на обновлении корневухи).

На ум приходит только minicom. Он использует отдельный пакет, не помню как называется.
Посмотрите в составе пакета minicom, что он использует. Можно перекомпилить.
Сам я этим не занимался, у меня флеш прошивается по Ethernet. Думаю, что uboot это тоже может.

Какие могут возникнуть минусы, если пользоваться uClib?
Думаю, стоит ли бузибокс с uClib собирать ...
Скачал uClib, собирается если указать процессор i386, если указать ARM, вываливается с криком:Причем от настройки индианы это не зависит.

uClibc никогда не пробовал, именно из-за возможных минусов. Памяти достаточно - 16M Flash 64M SDRAM.

./extra/scripts/conf-header.sh .config > include/bits/uClibc_config.h
cc1: error: invalid option `little-endian'
cc1: error: invalid option `little-endian'
CC ldso/ldso/ldso.oS
cc1: error: invalid option `little-endian'
make: *** [ldso/ldso/ldso.oS] Ошибка 1

Ключи gcc -mlittle-endian и -mbig-endian определены для ARM. Похоже, что у Вас вызывается gcc хоста (x86), для которого эти ключи не определены. См. выше про PATH.
Для uClibc есть какой-то конфигуратор? Тогда надо там указать target и host (см. выше).

[v_shamaev]

Итак ... взял образ рамдиска отсюда http://heavy-online.ru/arm-linux/ .
На удивление, все заработало, теперь пошли общие вопросы.
Скачал более свежий busybox, насколько я понимаю, если я его собираю (make CROSS_COMPILE=arm-linux-), то при сборе он использует либу glib, причем для x86?
По крайней мере, все попытки запустить на моем девайсе самодельно собранный бузибокс закончились неудачей, пробовал и статически собирать и ... .
Новую либу тоже надо кросс компилятором собрать?

Еще, мне надо как то Z-modem к моему хозяйству прикрутить, чтоб начать ковырятся с драйвером NAND флешки (иначе тонны времени потрачу на обновлении корневухи).

Какие могут возникнуть минусы, если пользоваться uClib?
Думаю, стоит ли бузибокс с uClib собирать ...
Скачал uClib, собирается если указать процессор i386, если указать ARM, вываливается с криком:Причем от настройки индианы это не зависит.

У меня:
#!/bin/sh
export ARCH=arm
export CROSS_COMPILE=arm-linux-
make clean
make ARCH=arm
make install

А для разных вариантов - разные тулчейны, собирается.

[3.14]

Итак, с налету uClib не собирается (под ARM), ошибки всеми цветами радуги валятся, в зависимости от включеных опций ...
Сфокусировался на glib.
1) распаковал glibc-2.3.6.tar.bz2
2) распаковал glibc-linuxthreads-2.3.6.tar.bz2
3) незная как правильно приложить патчи ioperm.c.diff и Makeconfig.patch, тупо нашел редактируемые строки в изменяемых файлах и руками попроавил
4) объявил переменную:

BUILD_CC=gcc CC=${CROSS_COMPILE}gcc AR=${CROSS_COMPILE}ar \
RANLIB=${CROSS_COMPILE}ranlib AS=${CROSS_COMPILE}as LD=${CROSS_COMPILE}ld \
../../glibc-2.3.6/configure --prefix=/usr --build=i386-unknown-linux \
--host=arm-linux --target=arm-linux --without-fp \
--without-__thread --enable-add-ons=linuxthreads \
--with-headers=${SYSROOT}/usr/include 2>&1 | tee configure.out

В ответ на make 2>&1 tee make.out получаю:

Makeconfig:84: arm/config.make: No such file or directory
Makerules:782: Не задано имя файла для `include'
/bin/sh: line 0: cd: arm: No such file or directory
The GNU C library has not been configured.
Run `configure' to configure it before building.
Try `configure --help' for more details.
make: *** [arm/config.status] Ошибка 1

[v_shamaev]

Итак, с налету uClib не собирается (под ARM), ошибки всеми цветами радуги валятся, в зависимости от включеных опций ...

Для uClibc тулчейн собирается при сборке buildroot, у меня Atmel - atmel_buildroot и использую.

[3.14]

А разве для glib и uClib разные тулчейны нужны?

[Idle]

А разве для glib и uClib разные тулчейны нужны?

Да, buildroot и нужен в первую очередь, для того, чтобы собрать toolchain именно для использования с uClibc.

[amw]

Вообще-то glib и glibc - разные вещи.
Судя по именам файлов у Вас glibc (что и ожидалось).
Используйте crosstools. Файлы конфигурации для IXP4xx во вложеном архиве - используйте для примера.

3) незная как правильно приложить патчи ioperm.c.diff и Makeconfig.patch, тупо нашел редактируемые строки в изменяемых файлах и руками попроавил

Код

cd в_каталог_исходников_которые_нужно_патчить
patch -p1 -iпуть_к_файлу_различий

путь_к_файлу_различий - обычно имя файла заканчивается на .patch или .diff
p1 - посмотрите man patch

Прикрепленные файлы

 crosstool_0.42.zip ( 1.1 килобайт ) Кол-во скачиваний: 32

 

[3.14]

А что в скрипте all.sh должно быть?

Попробовал собрать buildroot, а эта падлюка останавливается (может просто стоять час ничего ни делая, на большее время терения не хватило) после загрузки binutils, причем я уже три разные версии binutils попробовал

[amw]

А что в скрипте all.sh должно быть?

crosstools? Этот скрипт меняеть не надо. Он собственно все и собирает.

Попробовал собрать buildroot, а эта падлюка останавливается (может просто стоять час ничего ни делая, на большее время терения не хватило) после загрузки binutils, причем я уже три разные версии binutils попробовал

Сборка toolchain занимает несколько часов. crosstools все сообщения выводит на экран. buiodroot - не знаю.
Если перенаправить вывод, то экран будет пустой, а все сообщения пойдут в файл. Его лучше смотреть с помощью tail -F имя_файла с другой консоли.

Сообщение отредактировал amw - Sep 5 2007, 13:27

Прикрепленные файлы

 all.sh.zip ( 2.17 килобайт ) Кол-во скачиваний: 26

 

[v_shamaev]

Если перенаправить вывод, то экран будет пустой, а все сообщения пойдут в файл. Его лучше смотреть с помощью tail -F имя_файла с другой консоли.

Я вот так делаю:
make -w 2>&1 | tee make.out

Можно потом лог посмотреть. Собирается действительно долго, не один час. Но если висит - посмотреть в каком месте, может что из интернета ждет.

[3.14]

В продолжение сборки buildroot, сегодня, видимо из-за фазы луны , сборка не остановилась на старом месте, зато встала потом с ошибкой:

CC libc/sysdeps/linux/arm/syscall.os
libc/sysdeps/linux/arm/syscall.c: In function 'syscall':
libc/sysdeps/linux/arm/syscall.c:28: error: '__NR_syscall' undeclared (first use
in this function)
libc/sysdeps/linux/arm/syscall.c:28: error: (Each undeclared identifier is reported only once
libc/sysdeps/linux/arm/syscall.c:28: error: for each function it appears in.)
make[2]: *** [libc/sysdeps/linux/arm/syscall.os] Error 1
make[1]: *** [lib/libc.so.0] Ошибка 2

[amw]

В продолжение сборки buildroot, сегодня, видимо из-за фазы луны , сборка не остановилась на старом месте, зато встала потом с ошибкой:

CC libc/sysdeps/linux/arm/syscall.os
libc/sysdeps/linux/arm/syscall.c: In function 'syscall':
libc/sysdeps/linux/arm/syscall.c:28: error: '__NR_syscall' undeclared (first use
in this function)
libc/sysdeps/linux/arm/syscall.c:28: error: (Each undeclared identifier is reported only once
libc/sysdeps/linux/arm/syscall.c:28: error: for each function it appears in.)
make[2]: *** [libc/sysdeps/linux/arm/syscall.os] Error 1
make[1]: *** [lib/libc.so.0] Ошибка 2

Ну, из собственного опыта, toolchain либо собирается сразу и работает как надо, либо приходится долго изращатся с устранением вот таких ошибок.

Точно сказать что делать не могу.
Примерно следующая комбинация действий может помочь.
1. Что используется на ХОСТЕ для сборки (дистрибутив, версия хост компиллятора).
2. Как я понял, у Вас есть какой-то кросскомпилятор, может из состава BSP?
Что он говорит по команде
arm-linux-as -v
3. Что говорит по команде
arm-linux-gcc -v
4. Как я понял, у Вас есть корневая ФС (рамдиск)? Вы можете ее примонтировать на хосте?
Что говорят команды
ls -l lib/ld-linux*
ls -l lib/ld-*
Пути относительно точки монтирования этой ФС!!!
5. Какое ядро используется в оригинале?

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

Искать причину ошибки компиляции и править исходники gcc/glibc занятие муторное.

Ну и на всякий случай, google иногда помогает найти нужный патч. Хотя, и не особо надейтесь на это.

Еще можно посмотреть архив списка рассылки на http://www.arm.linux.org.uk/mailinglists/ по toolchain. Сначала почитать Etiquette, потом появится список.

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

[3.14]

Чего то я не пойму ... buildroot сам качает ядро, toolchain, uClibc и т.п. потом по замыслу он и должен все это сам собрать и подготовить корневуху. Разве мое текущее ядро (из BSP) и тулчейн имеет к buildroot отношение?

[root@linuxServer buildroot]# arm-linux-as -v
GNU assembler version 2.14.90.0.7 (arm-linux) using BFD version 2.14.0.0.7 20031029

[root@linuxServer buildroot]# arm-linux-gcc -v
Reading specs from /usr/local/arm-linux/lib/gcc-lib/arm-linux/3.3.2/specs
Configured with: ../gcc-3.3.2/configure --target=arm-linux --prefix=/usr/local/arm-linux --enable-languages=c,c++ --with-local-prefix=/usr/local/arm-linux/arm-linux --with-cpu=xscale --with-headers=/usr/local/arm-linux/arm-linux/include --host=i686-host_pc-linux-gnu --disable-nls --enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit --enable-shared --enable-c99 --enable-long-long --without-fp
Thread model: posix
gcc version 3.3.2
[root@linuxServer buildroot]#

-rwxr-xr-x 1 root root 93888 Май 4 2006 lib/ld-2.3.6.so
lrwxrwxrwx 1 root root 11 Май 5 2006 lib/ld-linux.so.2 -> ld-2.3.6.so

lrwxrwxrwx 1 root root 11 Май 5 2006 lib/ld-linux.so.2 -> ld-2.3.6.so

[v_shamaev]

Чего то я не пойму ... buildroot сам качает ядро, toolchain, uClibc и т.п. потом по замыслу он и должен все это сам собрать и подготовить корневуху. Разве мое текущее ядро (из BSP) и тулчейн имеет к buildroot отношение?

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

[amw]

Чего то я не пойму ... buildroot сам качает ядро, toolchain, uClibc и т.п. потом по замыслу он и должен все это сам собрать и подготовить корневуху. Разве мое текущее ядро (из BSP) и тулчейн имеет к buildroot отношение?

А качает он те-же версии, что и в BSP?
Не все комбанации версий собираются "чисто". Для некоторых комбинаций нужно долго искать патчи.

А в BSP есть glibc (ну или uClibc)? Почему-бы не использовать то, что есть.

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

Главное разместить все правильно.
См. результат вывода arm-linux-gcc -v на предмет --prefix.
В этот префикс и нужно все положить.
Прописать в PATH (см. пост #25) и использовать.

По идее линкер должен сам все найти (в смысле библиотеки), если они расположены в тех местах, где он ищет.
Если не находит, указать -Lпуть_к_библиотекам. Например

Код

LDFLAGS=-L/usr/local/arm-linux/arm-linux/lib configure
make

Для busybox это не проходит. Найдите в .config файле или Makefile LDFLAGS и пропишите пути.

Я почему-то решил, что в BSP нет glibc - потому и нужно компилировать.
Если есть, используйте их!

[3.14]

В /usr/local/arm-linux/arm-linux/lib лежит одна либа libiberty.a и директория gcc-lib, наверное это все-таки не те либы которые нужны для сборки бузибокса.

В /home/pi/src/linux-2.6.12.4-col2/lib/ лежит lib.a и небольшая кучка исходников (типа vsprintf.c ...) с объектниками, это оно (glibc) ?

Насколько я понимаю, мне нужно еще и пути к хидерам указывать (-I /home/pi/src/linux-2.6.12.4-col2/include ...), только там куча поддиректорий (в /linux-2.6.12.4-col2/include) типа asm, asm-arm ...

Еще, в makefile бузибокса LDFLAFS := ${LDFLAGS}, т.е. насколько понимаю, где то в меню должно быть поле для ввода? Пока ничего подобного не нашел.

[amw]

В /usr/local/arm-linux/arm-linux/lib лежит одна либа libiberty.a и директория gcc-lib, наверное это все-таки не те либы которые нужны для сборки бузибокса.

Посмотрите в /usr/local/arm-linux/lib

В /home/pi/src/linux-2.6.12.4-col2/lib/ лежит lib.a и небольшая кучка исходников (типа vsprintf.c ...) с объектниками, это оно (glibc) ?

Это только для ядра!!! Не используйте в программах!!!

Насколько я понимаю, мне нужно еще и пути к хидерам указывать (-I /home/pi/src/linux-2.6.12.4-col2/include ...), только там куча поддиректорий (в /linux-2.6.12.4-col2/include) типа asm, asm-arm ...

Ссылки в исходниках на хедеры ядра идут с указанием подкаталога
#include <linux/fs.h>
#include <asm/types.h>
и тп.
Достаточно указать -I/home/pi/src/linux-2.6.12.4-col2/include
Программы довольно редко используют хедеры ядра.

Еще, в makefile бузибокса LDFLAFS := ${LDFLAGS}, т.е. насколько понимаю, где то в меню должно быть поле для ввода? Пока ничего подобного не нашел.

Это значит, что используется переменная окружения. Используется так:

Код

make LDFLAGS=-L/usr/local/arm-linux/lib

или так

Код

export LDFLAGS=-L/usr/local/arm-linux/lib
make

ну или так

Код

make LDFLAGS="-L/usr/local/arm-linux/lib -L/usr/local/arm-linux/arm-linux/lib -L/usr/local/arm-linux/lib/gcc/3.3.2/lib"

Просто посмотрите где у Вас в toolchain есть файлы lib*.a и lib*.so* и укажите эти каталоги.
Если toolchain установлен ... ну скажем так ... не совсем правильно - то есть чего-то не хватает или не там лежит, то нужно прописывать пути к библиотекам и хедерам в ручную.
С другой стороны, busybox, не совсем правильная программа .

Пропишите в Makefile путь прямо открытым текстом.

[3.14]

Спасибо, уже лучше, по крайней мере собраный бузибокс наконец заработал (в1.7).
Странно, я думал, если бузибокс собран не статически, то он должен и памяти меньше потреблять (после запуска), на данный момент каждая "реинкорнация" бузибокса берет !!!2М БАЙТА!!!, хотя старая (в1.2) отнмала по 0.5М.
Не статически, новый бузибокс, с ходу не собирается.

Далее, у меня есть исходники утилит Z-modem-а, как теперь должен выглядеть процесс их сборки под кросс-компилятором (просто в makefile подменить компилятор и LDFLAGS)?

[amw]

Спасибо, уже лучше, по крайней мере собраный бузибокс наконец заработал (в1.7).
Странно, я думал, если бузибокс собран не статически, то он должен и памяти меньше потреблять (после запуска), на данный момент каждая "реинкорнация" бузибокса берет !!!2М БАЙТА!!!, хотя старая (в1.2) отнмала по 0.5М.
Не статически, новый бузибокс, с ходу не собирается.

Далее, у меня есть исходники утилит Z-modem-а, как теперь должен выглядеть процесс их сборки под кросс-компилятором (просто в makefile подменить компилятор и LDFLAGS)?

Дальнейший процесс сборки софта кросс-компилятором выполняется путем

Код

cd в_каталог_исходников
configure --target=arm-linux --host=arm-linux

Не забудте прописать пути правильно!!!
Еще вариант.

Код

export CFLAGS="-Iпуть1 -Iпуть2"
export CXXFLAGS="-Iпуть1 -Iпуть2"
export LDFLAGS="-Lпуть1 -Lпуть2"
export CC=arm-linux-gcc
export CXX=arm-linux-g++
export LD=arm-linux-ld
configure --target=arm-linux --host=arm-linux

Здесь следует обратить внимание на то, что часто в качестве линкера после configure будет не ld, а gcc или g++. Тогда надо LD=arm-linux-gcc или LD=arm-linux-g++

Если нет configure, то тогда править Makefile.
Заменить переменные CC, CXX, LD, STRIP и им подобные. Указать кросс-компилятор.
Поправить CFLAGS, CXXFLAGS, LDFLAGS.
Ну и соответственно, некоторые программы вообще не используют переменных в Makefile, тогда заменить имя компилятора, линкера, флаги...

[3.14]

собрал новое ядро, дык оно упорно не хочет распаковывать ramdisk с корневухой, пишет:

Код

RAMDISK: Compressed image found at block 0
bad gzip magic numbers

Меняю ядро на старое, грузится без вопосов.
Если новому ядру подсунуть не gzip-нутый образ корневухи, тогда грузится нормально.

[amw]

CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=4
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024
CONFIG_BLK_DEV_INITRD=y

А какое ядро? Может оно initramfs хочет?

[3.14]

Это все в ядро включено ...
Ядро 2.6.14-intcl (интересно, что такое initcl).
аргументы запуска:

Код

root=/dev/ram rw initrd=0xa7800000,0x500000 ramdisk_size=5129 video=pxafb:mode:800x480-18,active,pixclock:70000,vsynclen:10 console=ttyS1,115200 mem=128M

Собрал новый образ initrd, все по старому, "старое" ядро грузится, а новое говорит bad gzip magic numbers

Еще, насколько я понимаю, ядро расаковывает u-boot, тогда как бы его заставить образ корневухи распаковывать?

[amw]

Это все в ядро включено ...
Ядро 2.6.14-intcl (интересно, что такое initcl).
аргументы запуска:

Код

root=/dev/ram rw initrd=0xa7800000,0x500000 ramdisk_size=5129 video=pxafb:mode:800x480-18,active,pixclock:70000,vsynclen:10 console=ttyS1,115200 mem=128M

Собрал новый образ initrd, все по старому, "старое" ядро грузится, а новое говорит bad gzip magic numbers

Еще, насколько я понимаю, ядро расаковывает u-boot, тогда как бы его заставить образ корневухи распаковывать?

Что такое "initrd=0xa7800000,0x500000"? В смысле последняя цифра зачем? По документации такой нет. Есть только адрес. Может быть ошибка преобразования строки в число.

u-boot имеет утилиту для создания uImage. Там, как я понимаю, указывается все параметры. u-boot должен загрузить ядро и образ рамдиска, а потом уже запускать ядро.

[3.14]

Насчет 0x500000, я так понимаю, это область памяти выделяемая распакованному рамдиску, попробую покрутить ...
U-boot нормально видит оба образа, но как ему сказать что нужно распаковать рамдиск?
Команда bootm применительна к ядру. В настоящий момент (со старым ядром) я принудительно перед загрузкой ядра копирую рамдиск в память (при этом, заголовок для у-бута, с помощью mkimage не создаю), мой bootcmd:

Код

cp.b 1e0000 a7800000 220000; bootm 60000

[vanokuten]

В продолжение сборки buildroot, сегодня, видимо из-за фазы луны , сборка не остановилась на старом месте, зато встала потом с ошибкой:

У меня buildroot всегда собирается и toolchain и rootfs,
Пропробуй buildroot из svn.

Может у тебя слишком старый dist & kernel ?

Best regards,
Ivan

[amw]

Насчет 0x500000, я так понимаю, это область памяти выделяемая распакованному рамдиску, попробую покрутить ...
U-boot нормально видит оба образа, но как ему сказать что нужно распаковать рамдиск?
Команда bootm применительна к ядру. В настоящий момент (со старым ядром) я принудительно перед загрузкой ядра копирую рамдиск в память (при этом, заголовок для у-бута, с помощью mkimage не создаю), мой bootcmd:

Код

cp.b 1e0000 a7800000 220000; bootm 60000

По U-Boot помочь не могу - не пользовался.
Для параметра ядра initrd указывается только адрес. Размер задается в ramdisk_size.
Должен соответствовать размеру распакованного рамдиска. Может быть больше но НЕ МЕНЬШЕ. Грузить можно и упакрванный и распакованный. Ядро само определяет что это такое по сигнатурам.
На сколько я понимаю, код в ядре для распаковки рамдиска не зависит от архитектуры и способа загрузки. Надо что-бы ареса были правильными.

[3.14]

Ладно, с корневухой разобрался, был клубок нюансов ...
Создал новую корневуху, логин никак не хочет рута пускать.
Содержимое /etc идентично "старой рабочей" корневухе (passwd ...).
?

[amw]

Запустить busybox на консоль, сгенерить пароль, сохранить passwd, прописать в корневухе.

[S_agent]

..Создал новую корневуху, логин никак не хочет рута пускать...

в /etc/inittab добавить строку:
::askfirst:/bin/sh
так будет пускать с консоли без запроса пароля
а далее как сказал amw:
запустить с консоли passwd установить пароль,
и если рутфс на рамдиске а не jffs сохранить passwd: cat /etc/passwd
и, если, включен shadow, cat /etc/shadow

[Frox_SzC]

А какая нибудь литература есть по этому вопросу???

[Idle]

А какая нибудь литература есть по этому вопросу???

Karim Yaghmour - "Building Embedded Linux Systems"
Christopher Hallinan - "Embedded Linux Primer: A Practical, Real-World Approach"
P. Raghavan, Amol Lad, Sriram Neelakandan - "Embedded Linux System Design and Development"