Для сборки своей файловой системы для mini2440 на базе генту линукса нам потребуется специальным образом подготовленный хостовый линукс (x86 или x86_64). В идеале это должен быть многопроцессорный сервер, но технически это будет работать и на виртуалке под эмуляцией (разумеется на порядок медленнее).
Вообще существует несколько вариантов сборки системы под себя, они отличаются кросс сборкой и нативной сборкой.
Кросс сборка это когда физически для компиляции используется процессор другой архитектуры ( под arm компилим на x86 или x86_64)
Нативная сборка это когда физически над компиляцией трудится сам mini2440 (файловая система при этом может быть по сети или SD)
По понятным причинам нативная сборка самая медленная, я её отбросил сразу же. С другой стороны скорость нативной сборки сопоставима с кросс компиляцией из под одно-ядерного линукса x86 запущенного в виртуалке - поэтому кой чего не очень большое можно собирать и на mini2440 это тема другой статьи
Кросс сборка в свою очередь бывает выполненной посредством кросс компиляторов и сборкой из под эмулятора процессора.
Сборка кросс компиляторами самая быстрая но систему на ней полноценную собрать - ещё та задача для продвинутых программистов разработчиков. Дело в том что в состав системы входит много пакетов которые в процессе сборки выполняют серию тестов запуском только что собранного кода. По понятным причинам мы выполнить такие тесты не можем - бинарник под другой проц. Есть методы обхода этого ограничения, но всегда это уникальный подход, отдельные патчи и много много потраченного времени. Есть и другого рода сложности вроде фиксированных в коде путей линковки библиотек - получается arm бинарник с библиотеками x86... В общем это путь для супер продвинутых разработчиков.
Кросс сборка эмуляторами существуют программы которые позволяют эмулировать нужный нам процессор или даже таргет систему, например qemu
Эмуляция процессора qemu-{архитектура} дает возможность запускать бинарники другой архитектуры находясь в хостовой системе непосредственно. Этот путь я избрал для сборки своей системы, он позволяет получить особенности таргет архитектуры процессора без привязки к аппаратной части и что самое главное - использовать ВСЕ ядра (аппаратные) для сборки.
Эмуляция устройства qemu-system-{таргет устройство} Позволяет запустить виртуальную машину эмулирующую требуемую платформу. Этот путь хорош тем что позволяет работать в рамках органичений присутствующих в системе (объемы RAM NAND, порты). Позволяет запустить загрузчик и проверить его работу, влить kernel и т.д. НО автоматически получаем все прелести ограничений при сборке, это сильно замедляет процесс.
Начну пожалуй с описания эмуляции устройства: Эмуляция mini2440 через qemu работать я буду в каталоге /tftproot хостовой системы, хотя это не принципиально
качаем патченый под mini2440 вариант qemu # cd /tftproot # git clone qemu_src
конфигирим и устанавливаем # cd qemu_src # ./configure —prefix=/tftproot/qemu --target-list=arm-softmmu # make -j3 # make install
каталог /tftproot/qemu теперь содержит необходимые бинарники для запуска
для подключения виртуальной mini2440 нам потребуется бридж интерфейс ! обращаю внимание что перенастройка сети должна вестись с локальной консоли хост системы ! вносим правки в /etc/conf.d/net
нужно подготовить ядро для того чтобы оно распознавало иной формат бинарников (опция CONFIG_BINFMT_MISC=m или CONFIG_BINFMT_MISC=y при сборке ядра системы). В сборке Calculate Linux Roboforum Build места разработчика это уже включено.
собираем обработчик кода arm (! статическая сборка обязательна для чрута) # USE=static emerge -b1 app-emulation/qemu-user
регистрируем обработчик в ядре (вынес в тег код потому что сложная строка)
берём последний стейдж arm gentoo линукса и разворачиваем его для работы (ищем здесь ссылку ) # wget # mkdir /tftproot/rootfs # tar -xvjpf stage3-armv4tl-20100718.tar.bz2 -C /tftproot/rootfs
установим обработчик qemu-arm на таргет систему (при переносе на железку mini2440 его нужно будет удалить) # cp /usr/bin/qemu-arm /tftproot/rootfs/usr/bin/qemu-arm
и скопируем минимально необходимые библиотеки для обработчика в хост систему # mkdir -p /usr/gnemul/qemu-arm # cp -a /tftproot/rootfs/lib/ /usr/gnemul/qemu-arm
визуально ничего не изменилось но попробуйте набрать uname -a и вот оно чудо: amper / # uname -a Linux amper 2.6.24-gentoo-r8 #1 SMP Wed Apr 8 01:21:51 MSD 2009 armv5tel GNU/Linux
возьмите за правило всегда после чрута выполнять команду amper / # env-update && source /etc/profile это позволит избежать неприятных вещей с переменными окружения
возможно вам потребуется поставить переменные прокси сервера и DNS amper / # echo "nameserver 192.168.0.30" >/etc/resolv.conf amper / # export ftp_proxy=http://192.168.0.30:3128 amper / # export http_proxy=http://192.168.0.30:3128
ну а делее фантазия Ваша, работаем в генту линуксе
сборка binutils gcc заняля около 4 часов на 8 ядерном сервере, glibc на момент написания пока собирается именно поэтому рекомендую пользоваться уже собранными мной бинарниками!
Все пакеты которые я успел собрать лежат тут, они же будут пытаться подтягиваться при вышеуказанном конфиге в бинарном виде (для экономии Вашего времени сборки)
Добавлено спустя 31 минуту 55 секунд: пример насколько это "тяжкая задача"
прелесть заключается в том что этот линукс является source based и систему можно собрать ровно настолько оптимально сколько это требуется пример: я не планирую вообще использовать в системе ipv6 выключаю флагом в профиле системы (USE="-ipv6") и пересобираю подверженые изменению пакеты с учетом всех зависимостей emerge -uDNav system
Всё - система чиста от поддержки ipv6. И так с любой опцией. На выходе получаем на 100% требуемую нам систему, ничего лишнего. + всякие вкусности рекурсивных проверок зависимостей и чистка ненужных библиотек и файлов в системе.
Про минимальную файловую систему вопрос не корректный - смотря что считать "минимумом" в теоритическом минимуме размер одинаков для всех линуксов = размер busybox+baselayout ~1МБ но я подозреваю такая система не совсем интересна? хотя и полноценно работать будет. мой стейдж с компиляторами sshd и набором всяких полезных программок порядка 100МБ
Я собственно спросил про размер именно для того что-бы понять можно ли создать именно то, что мне нужно. А мне как раз нужна система минимального размера, или точнее мне мало что нужно. ftp+ssh+busybox и отдельно Qtopia + мое ПО. Сам использую busybox для этих целей. Наверное попробую и Gentoo в минимальной конфигурации. Еще интересует время загрузки, до появления консоли без графики при минимальной количестве демонов (FTP+SSH). И напоследок вопрос философского характера: а неужели так нужно иметь одновременно так много всяких библиотек и программ на mini2440? Сорри за оффтоп.
в минимальных конфигурациях генту линукс ничем не отличается от любых других ну немного по другому реализованы инит скрипты. скорость загрузки тоже у всех линуксов с одинаковым набором запускаемых сервисов будет одинакова
если не тянуть на таргет порты, компиляторы и тд то генту просто обеспечивает удобный инструмент сборки таргет системы, не более
сколько нужно одновременно иметь библиотек и программ решает разработчик (Вы) например собираем любой пакет для работы с текстом - с базовыми настройками он хочет подсистему документации (+ man ), найтив лэнгвич (+nls это целая цепочка пакетов), подсистему работы с мышкой и т.д. при попытке сбора по умолчанию получим цепочку из десятка библиотек и программ вспомогательных отключив не нужные нам флаги мы собираем только то что нам действительно нужно в этом и есть сила генту
Добавлено спустя 1 минуту 48 секунд:
Palachzzz писал(а):
Обнаруженна папка kernels)))
я там вообще выложил полный комплект с описанием
Добавлено спустя 13 минут 13 секунд: забыл сказать что в системе портов генту есть прекрасные инструменты для удаления не нужных Вам пакетов поэтому стейдж на 100МБ он нужен для утобной пересборке его самого в сторону уменьшения:
просмотр установленных пакетов # eix -I
удаление ненужных пакетов # emerge -Cav mc syslog-ng
и чистка освободившихся библиотек # emerge --depclean -av
если вас "смущает" какой то файл или каталог можно посмотреть чей он # qfile /usr/share/man (так я убирал документацию - смотрел чьё там ещё лежит и пересобирал соответствующие пакеты с фичами noman noinfo nodoc )
все настройки профиля сборки делаются флагами USE="" и FEATURES="" в /etc/make.conf в юзы ставим нужные (или не нужные с "-") нам флаги : USE="-ipv6 -cups samba" удобная прога для редактирования флагов c их описанием # ufed
фичи меняют обычно редко - это опции самого установщика пакетов например FEATURES="buildpkg noman noinfo nodoc getbinpkg" buildpkg - оставляем собранные пакеты с бинарном виде (каталог задается PKGDIR=/packages/) getbinpkg - пытаемся сначала посмотреть наличие уже собраных пакетов по расположению PORTAGE_BINHOST="http://projects.roboforum.ru/mini2440/gentoo/packages"
пересборка тулчейна это процесс бутстрапа или шнуровки в стейдже от которого я отталкивался тулчейн собран под абстрактный ARM, желательно ео пересобрать под конкретный процессор, чтобы либы на которые будут опираться в дальнейшем ВСЕ программы содержали оптимальный набор инструкций для таргет процессора.
традиционно пример: по опыту из взрослых вычислительных кластеров: если сравнить софт который занимается расчётами на кластере из коммерческой поставки например RedHat (из rpm пакета) и сравнить его производительность с ним же пересобранным из исходных кодов с использованием оптимальным для процессора набором инструкций, то можем получить выигрыш до 15-20% производительности в пользу самосборного. Я с коллегами был очень удивлен и озадачен этим и для анализа причин была произведена декомпиляция бинарников с подсчётом кол-ва инструкций процессора по классам sse sse2 ssse3 sse4_1 В итоге оказалось что пакеты из дистрибутива x86_64 для совместимости собраны вообще без поддержки инструкций sse4_1 и их применение на новых ксеонах дало значительное увеличение производительности.
Именно поэтому набор ключей компиляции крайне важен в устойчивости и производительности сборки. кстати стейдж весь скомпилирован без с флага -fomit-frame-pointer : коллеги разработчики ядра рекомендовали убрать как потенциально приводящий к нестабильности некоторых пакетов на ARM. из статьи сейчас его уберу
в стейдже нет файла /etc/resolv.conf а в /etc/conf.d/net : config_eth0=( "noop" ) заменил на dhcp - не работает (не установлен dhcp клиент?) пришлось в ручную.. так что толку от предустановленного sshd как понимаете - 0, т.к. сеть не работает изначально) хм.. запустил emerge --sync в итоге вывалился с ошибкой - не хватает места в /tmp/.<абракадабра>:
resolv.conf убран умышленно, ровно как и конфигурация eth0 отключена резолв - чтобы самостоятельно добавляли свои сервера А вот насчёт сети вы не правы - она работает изначально, ещё до запуска корня, из параметров ядра ip= именно поэтому отключено оно в инитах я сам тестирую по NFS корню и управляю SSH
eix -I и должен выдавать большое число пакетов - их там столько установлено, я не ставил задачу собрать минимальную систему, это полнофункциональный базовый текстовый корень, тот что по классификации называют stage3
Вы не указали куда вы хотите синхрануть порты - держать их на embedded очень не разумно, они большие и нужны только при пересборке папка /usr/portage должна быть либо на SD либо на NFS
У меня все на SD карточке, первый раздел FAT32 (260 Мб) с ядрами (разные, если надо поменять, просто надо переименовать его), и еще 3 раздела ext3, на двух (по 1 Гб) разные rootfs (debian и gentoo, для смены надо переписать в u-boot-е раздел rootfs), третий (1,5 Гб) в резерве пока.
И еще непонятный трабл, уж не знаю то ли из за корявой сборки ядра(ядро свое, в ядре с репо нет поддержки ext3), то ли rootfs.. в общем в /dev есть mmcblk0, но почему то нет mmcblk0p1, mmcblk0p2, mmcblk0p3, mmcblk0p4 (разделы)
C eix разобрался)) eix -I (параметр i (большое) а не L (маленькое))
все правильно в ядре с диска, да и с repo.or.cz по умолчанию отключена поддержка ext3 /usr/portage лучше смонтировать на большой раздел
Добавлено спустя 1 час 5 минут 3 секунды: для того чтобы видились все разделы mtd вам нужно решить как поддерживать /dev есть варианты стаический , devtmpfs, udev статический самый простой и самый не правильный - у нас просто на уровне файловой системы собраны ноды на девайсы (mknod) можно посмотреть устойства в ядре и руками сделать на них ссылки из /dev (смотреть вроде в /proc/devices)
второй вариант - собрать ядро с поддержкой devtmpfs - оно будет само создавать ноды при появлении новых устройств в /proc/devices
ну и третий вариант - udev (в моем стейдже это # rc-update add udev system ) автосоздание нод девайсов по правилам (/etc/udev.d)
я сейчас использую первый и второй варианты, юдев по умолчанию отключен из запуска но имеется в системе
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 0
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
FAQ
Поиск
