[РЕШЕНО] Автоматизированная генерация stage3 (stage4) для архитектуры ARM
Добрый день, уважаемому сообществу!
Ответ на поставленный вопрос на сегодня 23 май 2014:
Кросс-компиляция stage3 и stage4 затруднена вплоть до невозможна, так как часть пакетов не адаптирована под нее. Наиболее стабильные результаты получаются при использовании qemu и запуска под ним нативной системы сборки.
Как сделать. Собрать последний qemu статически слинкованным, для этого размаскируем создав файл /etc/portage/package.keywords/qemu со следующим содержимым
=app-emulation/qemu-2.0.0 ~amd64
Прописать в /etc/portage/make.conf
USE="$USE qemu static-user static-libs"
QEMU_USER_TARGETS="arm"
QEMU_SOFTMMU_TARGETS=""
Собрать qemu
# emerge qemu
Поправить файл /etc/init.d/qemu-binfmt в части строки
echo ':arm:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x28\x00:\
\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\x00\xff\xfe\xff\xff\xff:/usr/bin/qemu-arm:P' \
> /proc/sys/fs/binfmt_misc/register
на
echo ':arm:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x28\x00:\
\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\x00\xff\xfe\xff\xff\xff:/usr/bin/qemu-arm:' \
> /proc/sys/fs/binfmt_misc/register
т.е. удалить последнюю "P". За одно проверить, что ядро собрано с поддержкой binfmt-misc. Добавить qemu-binfmt для запуска на актуальном уровне
# rc-update add qemu-binfmt default
Подготовительные операции завершены. Далее берем stage3 для arm с http://get.gentoo.org, распаковываем и переходим туда с использованием статически собранного эмулятора. Например, с помощью скрипта
#!/bin/bash
export CHROOT_DIR="/exportfs/armv7a-hardfp"
echo "Binding root directory"
mount -o bind /proc ${CHROOT_DIR}/proc
mount -o bind /sys ${CHROOT_DIR}/sys
mount -o bind /dev ${CHROOT_DIR}/dev
mount -o bind /dev/pts ${CHROOT_DIR}/dev/pts
mount -o bind /dev/shm ${CHROOT_DIR}/dev/shm
mount -o bind /usr/portage ${CHROOT_DIR}/usr/portage
echo "Copy resolv.conf"
cp -f /etc/resolv.conf ${CHROOT_DIR}/etc/resolv.conf
cp -f /usr/bin/qemu-arm ${CHROOT_DIR}/usr/bin/qemu-arm
echo "Entering chroot ..."
export LANG="C"
chroot ${CHROOT_DIR} /bin/bash --login
echo "Exit chroot enverooment"
echo "Unbinding root directory"
umount ${CHROOT_DIR}/proc
umount ${CHROOT_DIR}/sys
umount ${CHROOT_DIR}/dev/shm
umount ${CHROOT_DIR}/dev/pts
umount ${CHROOT_DIR}/dev
umount ${CHROOT_DIR}/usr/portage
Там уже обновляемся штатными средствами. Собственно здесь получаем оптимизации с помощью CFLAGS в /etc/portage/make.conf
При необходимости для генерации базовой (stage3) и рабочей (stage4) системы используем либо бинарные пакеты c emerge (быстрее по времени, но сложнее для stage4 - нужны пользователи, правки конфигов и т.п.), либо catalist (медленнее и более затратно по диску).
Надеюсь, когда-нить можно будет обойтись и просто кросс-компиляцией.
Далее история вопроса:
Собственно вопрос в теме. Очень хочется получить возможность локально генерировать stage3, так, как это сделано допустим тут. Крайне желательно в виде кросскомпиляции на машине x86_64. Пока интересны разные вариации архитектуры ARM (v5tel-softfloat, v7a-hardfp, v7a-neon). В последствии возможно и другие.
Что пробовал?
Пробовал crossdev. Что-то в стиле
# emerge crossdev
# crossdev --target armv7a-neon-linux-gnueabi
<правим /usr/armv7a-neon-linux-gnueabi/etc/portage/make.conf, правим ссылку /usr/armv7a-neon-linux-gnueabi/etc/make.profile на /usr/portage/profiles/default/linux/arm/13.0>
# armv7a-neon-linux-gnueabi-emerge world
умирает где-то на первой трети работы.
Пробовал catalist в режиме кросс-компиляции. Еще хуже. Умирает практически сразу. (Можно я не буду конфиги приводить без надобности? Сдается мне есть путь проще...)
Пока единственное работающее решение это развернуть на ARM'овскую доску stage3, и подтянуть туда нативный catalist. Так работает. Но уж очень долго и тоскливо...
Пробовал qemu-arm с последующим chroot. Но как-то тоже не срослось...
Вот и подумалось - может кто знает как именно кросплатформенные stage'ы генерируются на build-серверах. Ведь не на ARM'ах же их делают!
Или хоть что-то похожее на step-by-step руководство по пересборке. А то embedded-handbook явно дает не рабочее решение, а куда еще копать я не в курсе.
- Для комментирования войдите или зарегистрируйтесь
Ведь не на ARM'ах же их
Ведь не на ARM'ах же их делают ..
Почему нет ? :)
http://wiki.gentoo.org/wiki/Project:Infrastructure/Developer_Machines
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)
slepnoga написал(а):Почему
Нда... Вариант конечно... Озадачить доску с Tegra3 на сборку stage's... Там вроде даже SATA работает... Принято как работая версия.
Но хочется альтернатив. В идеале в виде кросскомпляции...
[Добавка]
Разобрался (вроде) с qemu-arm. В portage стоит неправильный magic для binfmt-mics (точнее mask, в embedded-handbook она правильная). Но на моей машинке qemu-arm работает много медленнее нативного ARM'а. А он в свою очередь много медленнее кроскомпиляции.
Потому вопрос таки актуален. Очень хочется кроскомпилировать stage'сы.
Цитата: Но на моей машинке
Кросскомпиляция - самый быстрый в плане ресурсов способ, но ВСЕ пакеты собрать не удастся, это достаточно хрупкая конфигурация, многие пакеты тупо не соберутся, потому что апстрим не заинтересован в поддержке кросс-компиляции. Тем не менее, @system обычно кросс-компилируется без проблем.
qemu-arm у меня работает БЫСТРЕЕ чем нативная компиляция, но только потому, что в качестве ARM-девайса у меня - Raspberry Pi, а у неё чрезвычайно медленный I/O.
Нейтральность - высшее достижение сознания!
Как вариант - qemu-arm и
Как вариант - qemu-arm и кросс-компилятор для объектов. В qemu будет только линковка (python тоже отлично выносится).
Можно попытаться distcc для этого приспособить или скрипт-враппер (может падать в нестандартных ситуациях).
Локальный оверлей растёт
А где можно почитать как это
А где можно почитать как это делается? Что-то я не могу себе представить как такое можно настроить... Разве что попробовать указать что-то типа
export QEMU_LD_PREFIX="/usr/armv7a-neon-linux-gnueabi"
export LD="/usr/bin/qemu-arm /usr/armv7a-neon-linux-gnueabi/usr/bin/ld --sysroot=/usr/armv7a-neon-linux-gnueabi"
Но как-то сомнительно... Хотя... Надо попробовать...
Цитата:Пробовал qemu-arm с
Что именно не срослось?
Логи?
Рассказываю из личного опыта. Собирал stage3 через crossdev на amd64 следующим образом:
Сначала - armv6j-hardfloat-linux-gnueabi-emerge @system
потом qemu chroot внутрь и досборка мира через emerge @world
Делалось это всё на ZFS, подвисло 1 раз из-за самой ZFS(давно было, сыровата она еще была).
Catalyst-ом собирать не пробовал, мне хватило crossdev-а.
Embedded handbook содержит 100% рабочее решение. То, что в вашей системе есть какие-то проблемы с кросскомпилятором и Qemu - не повод винить в этом документацию. Как видите, я по этой документации смог собрать стейдж для armv6. А еще я mips64 собирал, там свои приколы.
И вообще - какие-то проблемы - добро пожаловать на IRC-канал #gentoo-embedded, знающие люди там вполне помогут по конкретным вопросам.
Нейтральность - высшее достижение сознания!
Pinkbyte
Тут скорее проблемы с самим Qemu. Сейчас не нравится скорее скорость работы. А так да, развернутый stage3 и chroot в него. Работаем.
Да пожалуйста. Четко по Вашему рецепту. Надо сказать, что armv7a-neon-linux-gnueabi-emerge @system ушел дальше, чем armv7a-neon-linux-gnueabi-emerge world. И это повод мне понять в чем разница между ними... Особенно в данном конкретном случае... Но до конца все равно не дошел. Ладно, очевидные предупреждения у linux-headers, gcc и binutils о том, что переписываем файлы. Оно понятно и оно предупреждение. Остановка компиляции openssl
не понятна, но перезапуск armv7a-neon-linux-gnueabi-emerge @system ее решает. В том смысле, что в следующий раз openssl собирается и ставится. А вот на perl'е мы ломаемся.
В принципе даже понятно на чем ломаемся - на попытке запустить неродной бинарник. Ибо жалоба на отсутствие /lib/ld-linux-armhf.so.3 исходят от qemu-arm. Т.е. не видим кроскомпиляции и считаем, что оно у нас нативно компилируется.
И, кстати, внутрь-то я chroot'нулся... Но emerge'а то там нет. Как дособирать непонятно...
Раньше я как правило получал ругань от линкера на несоответствие формата библиотеки /lib/libc.so.6 (вариант /lib/ncurses.so.X.X) или отсутствующую /lib/libz.so. Причина тоже понятна - компилятор или libtools куда-то теряют sysroot. Только вот "--sysroot=/usr/armv7a-neon-...." прописано во всех *FLAGS, и переменная окружения SYSROOT определена. И даже EXTRA_ECONF="--with-sysroot=/usr/armv7a-neon..." пробовал. Ни в какую. При этом такая свистопляска начинается как только libc обновится.
Хм... Простите, не хочу занудничать но где же это 100% рабочее решение? Что-то я там варианте с cross-emerge @system предложенного Вами не видел. Да и кросскомпилатор собран по ней. Вот только с qemu накладочка - решение из EmbeddedHandbook уже устарело, и portage предлагает чуть-чуть другой вариант. Впрочем, подъемный и работающий. А стейджи как не генерировались, так и не генерируются.
А вот с этим сложнее... Я как-то IRC'шный живой чат не очень... Шумно... Списки рассылки, форумы, личная переписка - это запросто, а вот чаты... Ну не мое... Хотя за информацию спасибо... Прижмет пойду и туда... Пока буду искать решения в другом месте...
Цитата: А вот с этим
У нас и мэйллист есть - gentoo-embedded :-)
Полный список мэйллистов и краткое руководство по работе с ними тут
Алгоритм там описан верный. А перечисленные вами проблемы - это проблемы самих пакетов, об этом надо слать багрепорты. Сначала на bugs.gentoo.org, а там разберемся - чьи это грабли.
Нейтральность - высшее достижение сознания!
И для чего же люди писали
И для чего же люди писали embedded handbook
Кстати с qemu-user и binfmt можно запустить lxc контейнер с армом внутри
___________________________________________
Working on Gentoo for iPAQ hx4700 and Openmoko Neo Freerunner :-)
Если у вас компьютер с Windows, есть два выхода: выбросить компьютер в форточку или выбросить форточки с компьютера
alexxy написал(а): И для чего
Кратко - не знаю. Развернуто:
Да, идея Embedded Handbook (мы ведь об этом тексте) именно в том, что бы дать универсальное лекарство на случай кросс-компиляции системы. На деле, данное решение работает только в случае удачного стечения обстоятельств и нужной четверти луны. По совершенно разным (в том числе и не зависящим от авторов Embedded Handbook) причинам. А решение нужно уже сейчас. Так что и Handbook и пакеты, безусловно продолжаем пилить. Но стабильный результат только так.
Пробежимся по доке?
Введение (General Topics. Раздел 1) важно, но там общие слова про кросс-компиляцию.
Создание кросс-компилятора (General Topics. Раздел 2). Нужно и важно. И очень подробно. За что огромное человеческое спасибо. Особенно за вторую часть, где создание кросс-компилятора в подробностях. Но по сути, все кроскомпиляторная часть сводится к
# emerge crossdev# crossdev --target you-favorit-target
Что, в прочем необходимо и достаточно.
Кросс-компиляция с системой portage (General Topics. Раздел 3). Самая важная и интересная часть. Опять же по факту она сводится к простой и понятной команде
# you-favorit-target-emerge what-you-wantПредварительно поправив профиль системы и настроив make.conf. Ах, как бы хотелось что бы это работало. Увы, perl и python из @system на такую уловку не поддаются (во всяком случае конкретно на сегодня). А уж про @world и говорить не приходится. Чего, конечно, безумно жаль... Именно из-за этого и проходится юлить и придумывать обходные пути с qemu.
Кросс-компиляция ядра (General Topics. Раздел 4) прямо таки идеален. Просто и со вкусом. И ровно в том объеме, который необходим. Правда, лично я бы с радостью поменял местами 3 и 4 разделы. Ибо смысла в окружении без ядра не много. Да и грузится сначала ядро, а уж затем окружение.
Кросс-компиляция с qemu (General Topics. Раздел 5). Ну, начнем с того, что название не соответствует содержанию. Ибо про кросс-компиляцию здесь ни слова. За то есть рецепт создания qemu. Увы, не безупречный. В частности ряд пакетов не соберутся если не забиндить /dev/shm с хоста. (ммм... Не помню кто именно, но минимум пара в @system есть - могу уточнить). Инит-скрипт qemu-binfmt входит в состав пакета (правда, с несколько неподходящим содержанием). По факту, безоговорочно полезным становится wrapper для возможности указания типа процессора. Остальное требует переработки (возможно не быстрой, ибо qemu 2.0 замаскирован, но все равно со временем потребует).
Остальное - либо общие слова (как в FAQ) - практически без рекомендаций к действию. Это в первую очередь про "configure: error: C compiler cannot create executables", либо вещи специфичные для конкретно взятой доски.
К чему все это? Да к тому, что по Embedded Handbook рабочей системы не собрать. Во всяком случае в произвольный момент времени. Увы, рещение с qemu тоже не идеально. Например у меня есть доска с Marvell PXA320 (там armv5tel + iwmmxt2) - увы, но приходится обходиться набором команд iwmmxt, так как только он присутствует в Marvell PXA270 (поддерживаемом qemu).
Наверное можно. А зачем? Для поддержания актуального состояния можно запускать в chroot не шел, а скрипт. Результат тот же.