четверг, 13 декабря 2007 г.

Производители железа не умеют писать софт?

Бытует мнение... и думаю это действительно так. Щас докажу. :)

Работаю, как уже писал, с одной ARM'овой железякой от EmbeddedArtists. Ну начать наверное стоиит с того, что они положили в коробку с железякой...

В корорбке лежит CD, на котором записан exe файл, который представляет из себя 7z архив...

В архиве лежит образ vmware c устаановленным дебианом, в домашнем каталоге пользователя по умолчанию развернуты исходники uClinux, версии 20051014, уже пропатченные и настроенные на сборку. Справедлливости ради отмечу, что там все нормально собирается.

На сайте можно скачать патч, который, почему-то, не хочет накладываться на вышеозначенную версию uClinux. И который, помимо существенных изменений, касающейся данной борды, или хотя бы всех бордов данного производителя, содержит еще множество изменений в других подсистемах (преедпололжительно hsc патч и coldfire патч).

Кстати, ядро имееет версию 2.6.11.8 - использовать более новое ядро пока вообще представляется почти невозможным. Но не стоит рассчитывать и на то, что ядро 2.6.11.8 удастся успешно пропатчить, на первых порах придется довольствоваться ихним предустановленным.

В приннципе я ссогласен с тем, что готовая система для vmware - это оправданный шаг, ибоо сборка на других системах весьма не тривиальна. О чем щас тоже расскажу...

Но начатть стоит с того, что в крросскомпиляциях а уж тем более в ARM я не силен. Но и от своей любимой Gentoo отказываться не намерен. Берем crossdev и начинаем делать свои собственные toolchain. uclilbc почему-то вообщее не хочет собираться, может быть не любит ядро 2.6.23, инклюды от которого система ему подсовывает? arm-elf вполне успешно собрался (binutils, gcc-3, newlib), но с ним не захотел собираться busybox, который сказал примерно следующее:
/usr/libexec/gcc/arm-elf/ld: ERROR: /usr/lib/gcc/arm-elf/3.4.6/libgcc.a(_muldi3.o) uses hardware FP, whereas busybox uses software FP
Не совсем понимаю чем ему не нравится hardware FP. Ядро ведь должно его эмулирировать (поддержка включена), или на ARM'ах это не прокатывает?

Ладно, arm-softfloat-elf собрал все, да только очередной затык... все модули в системе получились elf, в то время, как ядро без MMU не может поддерживать ELF. :(

Начал разбираться а почему они собственно не Flat? дык очень просто. Для того, чтобы они стали flat, в binutils необходим дополнительный пакет - elf2flt, который через use флаги не активизируется, и на зеркалах нигде не лежит. Пришлось перековырять ebuild, благо кроссчейны лежат в оверлее... и наконец таки я собрал то, что они предоставили по умолчанию...
## Starting application at 0xA0008000 ...
Linux version 2.6.11.8-hsc0 (dron@mdf2007) (gcc version 3.4.6 (Gentoo 3.4.6-r2 p1.5, ssp-3.4.6-1.0, pie-8.7.10)) #5 Thu Dec 13 17:14:08 MSK 2007
CPU: Philips-lpc24xx [24000000] (ARMv3)
Machine: LPC24xx, NXP
...
init: Booting to single user mode
#
Кто-то скажет, что стоило ли столько мучится, тем более что в виртуальной машине все собирается... но мне в любом случае требовалось наладить свою сборку, мне в дальнейшем придется это менять, возможно дописывать модули.

2 коммент.:

Анонимный комментирует...

С ARM-ами сейчас вообще непросто, их самих несколько вариации, есть аж несколько ABI для FP, плюс есть просто разные ABI (EABI, конечно, рулит), плюс в uClibc с поточностью надо разбираться, и то, может без патчей не пойти... ;)

Я бы на твоём месте для начала просто вытащил бы установленный Debian из виртуальной машины в chroot, да работал. А уж потом, разобравшись толком, как собран их инструментарий, стал собирать свой.

Кстати, я не очень верю в кроссовый Gentoo, есть гораздо более компетентные в этом деле товарищи, которые делают, например, BuildRoot или OpenEmbedded.

Андрей Валяев комментирует...

Впринципе я добился нормальной сборки... не без напильника конечно...

Но за указания спасибо, я гляну на эти окружения...