Установка Buildroot — различия между версиями

Материал из virt2real wiki
Перейти к: навигация, поиск
(Текущая система сборки)
Строка 48: Строка 48:
 
git clone git://github.com/virt2real/dm36x-buildroot.git
 
git clone git://github.com/virt2real/dm36x-buildroot.git
 
cd dm36x-buildroot
 
cd dm36x-buildroot
make virt2real_v1_mass_defconfig
+
make virt2real_v1mass_defconfig
 
make menuconfig
 
make menuconfig
 
make
 
make

Версия 23:20, 11 сентября 2013

Для создания готовых решений на базу Virt2Real необходимо использовать систему сборки встраиваемых дистрибутивов buildroot. Все исходные коды проекта можно посмотреть на GitHub-е.

Что такое buildroot на пальцах

Для любой встраиваемой системы (термин не очень подходит для нашего случая, но уже устоялся и применяется в том числе и в контексте пользовательских устройств — ваш телефон или медиа-центр на Андроиде имеет примерно такую же структуру) необходимо три основных программных компонента:

  • загрузчик (bootloader),
  • ядро (kernel),
  • образ файловой системы (FS).

Все это хозяйство помещается на флешку или в NAND-память устройства и потом, как в одной очень старой книге — загрузчик загружает ядро, ядро цепляет ФС и стартует окружение пользователя. Тут полно нюансов.

Ядро — это прослойка между железом и софтом. В нем драйверы, управление памятью, планировщики ввода вывода и процессов на исполнение. Интерфейс ядра стандартен и в рамках ветки обычно не меняется. Мы одинаково успешно можем использовать 2.6.32, 2.6.34, 3.0.9 и 3.9.0. Эти версии отличаются — количеством драйверов (количеством поддерживаемого оборудования) и функциональными улучшениями и переработками. Но интерфейс пользовательского окружения — нерушим.

Файловая система содержит init-процесс, который

  • запускает системные фоновые службы (демоны),
  • стартует программную оболочку для консоли.

Тут много всего, начиная с библиотек для разработки, заканчивая прикладными утилитами. По сути, это то, что составляет собой дистрибутив — набор ПО для конечного использования. В современных системах место принято экономить, поэтому вместо тонны утилит используется busybox и прочие легкие альтернативы.

Buildroot — это система построения готовых наборов ПО для встраиваемых систем. Она поддерживает кучу плат и результатом ее работы становятся собранные загрузчик, ядро и образ ФС (или архив, как настроить). Она, если говорить очень обобщенно, содержит набор Makefile-ов и консольной меню для конфигурирования оных.

В общем случае buildroot сам создает toolchains (т.е. собирает кросс-компилятор и прочие утилиты для сборки кода), в частном — может пользоваться готовым. Принцип простой: сначала собираем систему сборки, потом скачиваем исходный код выбранного ПО(скачиваются как tar.gz архивы, так и git и hg-репозитории), собираем, формируем ФС, после чего собираем ядро и дособираем что остается. Никакой исходный код, в т.ч. и ядра в состав buildroot-а не входят. Все скачивается во время сборки.

Конфигурирование buildroot-a очень похоже на конфигурирование ядра. В корне лежит .config, который и есть текущая настройка. Соответственно, для распределенной работы над сборкой конкретного дистрибутива надо синхронизировать этот файл, например, через систему контроля версий.

А что если туда надо добавить софт, которого там нет? Тут есть варианты. Первый — мы собираем типовой дистрибутив из того, что есть, а потом руками при помощи кросс-компилятора собираем и подпихиваем нужное ПО (если оно уже собрано — то только подпихиваем) прямо в готовый образ, второй — делаем пакет для buidroot-а, который включаем в конфигурацию. В этом случае надо через систему контроля версий, помимо конфигурационного файла, таскать еще и файлы пакета.

Теперь что касается ядра. У ядра есть набор возможностей в виде поддерживаемого оборудования и конфигурационный файл. Последний говорит, что именно из ядра мы включаем в сборку. Добавление драйвера в ядро предполагает, что помимо исходного кода будут добавлены изменения в файлы конфигурирования, а при сборке это драйвер будет помечен как необходимый для включения в состав конечного шмата байтиков.

Ядро может собираться монолитно (т.е. включать в себя полный комплект функций и драйверов) в виде единого uImage, а может быть собрано с подгружаемыми модулями, которые могут загружаться или выгружаться в момент исполнения. Я стороник первого подхода (потому что мы получаем, что весь фарш уже в памяти и не надо ничего дополнительно грузить, а тем более проверять, загружено это или нет), но, как известно, у производителей оборудования зачастую свое мнение, как их дравера должны поставляться в ядро. Поэтому зачастую дополнительные модули идут уже в собранном виде, как было с модулем wi-fi на предсерийных образцах, когда их остается только пристыковать к текущему ядру, чтотак же можно сделать как пакет buildroot-а. Но, разумеется, эта практика не всегда полезна. Например, настройки платы надо собирать жестко в ядро, поэтому дело решается патчами к ядру с последующим пробросом их в репозиторий.

Текущая система сборки

Для того, чтобы разрабатывать под SoC DM365 компания TI предлагает использовать либо коммерческие сервисы и пакеты разработки, как например RidgeRun SDK или MontaVista embedded Linux, так и открытые проекты, которые, как и следовало ожидать, далеки от коммерческих аналогов. Кроме того, помимо особенностей SoC (в нашем случае — наличие на кристалле DSP) в ядре ОС, существует вопрос поддержки этих возможностей в пользовательском окружении. Сюда же можно отнести и аппаратно усиленные аудио-видео кодеки и фильтры обработки изображений, которые поставляются исключительно в виде бинарных модулей, что сильно затрудняет их использование вне заранее оговоренной среды.

Другая особенность разработки под DM365 в том, что есть открытая версия ядра linux-davinci, которая периодически синхронизируется с основной веткой ядра и в которой наличествует поддержка для всех SoC семейства Da Vinci в большей или меньшей степени.

На фоне такого «разнообразия» очень сложно осуществить какой-либо однозначный выбор для решения конкретных прикладных задач, поэтому работа ведется во множестве направлений, что можно посмотреть на GitHub-аккаунте Virt2Real. Далее я коснусь разработки в рамках представленного там кода.

У нас имеются две рабочих версии buildroot-а, которые можно использовать с разными требованиями по уровню устойчивости к провалам.

Первая версия — немного доработанный для Virt2real дистрибутив dm36x-buildroot, развиваемый Френком Ханлетом (Frank Hunleth), который предназначен для сборки Линукса под leopardboard, построенной на том же DM365. Есть предположение, что в основе этой сборки лежит набор патчей к ядру, buildroot плюс сведения о создании загрузочных флеш-накопителей, доведенный до состояния «можно использовать». Мы перенесли этот и смежные репозитории к себе на Github и немного их доработали. Теперь для сборки необходимо выполнить следующую последовательность команд.

sudo apt-get install git-core bison flex g++ gettext texinfo libncurses5-dev pv libssl-dev lzop gawk
git clone git://github.com/virt2real/dm36x-buildroot.git
cd dm36x-buildroot
make virt2real_v1mass_defconfig
make menuconfig
make

Если нам после процесса сборки потребуется каким-либо образом сконфигурировать ядро (допустим, добавить дополнительные драйверы устройств), то это делается при помощи команды make linux-menuconfig с последующим make.

Результат выполнения операций (в случае успешной сборки) будет находится в том же каталоге в виде leopardboard-XXXXXXXX.fw, который будет, по сути, zip-архивом, содержащем bootloader-ы и образ файловой системы, готовые для распаковки на флешку. Это делается следующими командами (стоит ли уточнять, что /dev/sdc — это microSD, а промах может быть весьма болезненный)

sudo -i
apt-get install pv
umount /dev/sdc1
unzip -p leopardboard_25042013.fw install.sh | sh -s - -a leopardboard_25042013.fw -d /dev/sdc -f

После завершения процесса устанавливаем карту в Виртурилку, подключаем консоль, загружаемся. С большой долей вероятности можно будет увидеть вполне работоспособную среду. Можно приступать к экспериментам.

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