Сборка linux buildroot virtualbox

[Из песочницы] Buildroot — часть 1. Общие сведения, сборка минимальной системы, настройка через меню

Введение

В данной серии статей я хочу рассмотреть систему сборки дистрибутива buildroot и поделиться опытом её кастомизации. Здесь будет практический опыт создания небольшой ОС с графическим интерфейсом и минимальным функционалом.

Прежде всего, не следует путать систему сборки и дистрибутив. Buildroot может собрать систему из набора пакетов, которые ему предложили. Buildroot построен на make-файлах и поэтому имеет огромные возможности по кастомизации. Заменить пакет на другую версию, добавить свой пакет, поменять правила сборки пакета, кастомизировать файловую систему после установки всех пакетов? Всё это умеет buildroot.

В России buildroot используется, но на мой взгляд мало русскоязычной информации для новичков.

Цель работы — собрать дистрибутив с live-загрузкой, интерфейсом icewm и браузером. Целевая платформа — virtualbox.

Зачем собирать свой дистрибутив? Зачастую нужен ограниченный функционал при ограниченных ресурсах. Ещё чаще в автоматизации нужно создавать прошивки. Приспосабливать дистрибутив общего назначения, вычищая лишние пакеты и превращать его в прошивку путь более трудоёмкий, чем собрать новый дистриб. Использование Gentoo тоже имеет свои ограничения.

Buildroot система очень мощная, но она ничего не сделает за вас. Она может лишь дать возможности и автоматизировать процесс сборки.

Альтернативные системы сборки (yocto, open build system и прочие) не рассматриваются и не сравниваются.

Где взять и как начать

Сайт проекта — buildroot.org. Здесь можно скачать актуальную версию и прочитать руководство. Там же можно обратиться к сообществу, есть багтрекер, mail-lists и irc-канал.

Buildroot оперирует defconfig’aми для целевой платы сборки. Defconfig — это конфигурационный файл, хранящий в себе только опции, не имеющими значения по умолчанию. Именно он определяет, что и как будет собрано. При этом можно отдельно настроить конфиги busybox, linux-kernel, uglibc, загрузчиков u-boot и barebox, но все они будут привязаны к целевой плате.
После распаковки скачанного архива или клонировании из git получаем готовый к работе buildroot. Подробно о структуре каталогов можно прочитать в руководстве, расскажу о самых важных:

board — каталог с файлами, специфичными для каждой платы. Это могут быть скрипты формирования образов системы(iso, sdcart, cpio и прочие), каталог overlay, конфиг ядер и прочее
configs — собственно defconfig платы. Defconfig — это неполная конфигурация платы. В нем хранится только отличные от дефолтных настроек параметры
dl — каталог со скачанными исходными кодами/файлами для сборки
output/target — собранная файловая система полученной ОС. В дальнейшем из нее создаются образы для загрузки/установки
output/host — host-утилиты для сборки
output/build — собранные пакеты

Конфигурирование сборки осуществляется через KConfig. Эта же система используется для сборки ядра linux. Список самых часто используемых команд (выполнять в каталоге buildroot):

• make menuconfig — вызвать настройку сборки. Так же можно с использование графического интерфейса (make nconfig,make xconfig,make gconfig)
• make linux-menuconfig — вызвать конфигурацию ядра.
• make clean — очистить результаты сборки (всё что храниться в output)
• make — собрать систему. При этом не выполняется пересборка уже собранных процессов
• make defconfig_name — переключить конфигурацию на определенный defconfig
• make list-defconfigs — показать список defconfig’ов
• make source — только скачать установочный файлы, без сборки.
• make help — вывести список возможных команд

Важные замечания и полезные советы

Buildroot не пересобирает уже собранные пакеты! Поэтому может создаться ситуация, когда потребуется полная пересборка.

Можно пересобрать отдельный пакет командой make packagename-rebuild. Например, можно пересобрать ядро linux:

Buildroot хранит состояние любого пакета созданием .stamp-файлов в каталоге output/build/$packagename:

Следовательно, можно пересобрать root-fs и образы без пересборки пакетов:

Полезные переменные

В buildroot есть набор переменных для удобного конфигурирования

• $TOPDIR — корневой каталог buildroot
• $BASEDIR — каталог OUTPUT
• $HOST_DIR, $STAGING_DIR, $TARGET_DIR — каталоги сборки host fs, staging fs, target fs.
• $BUILD_DIR — каталог c распакованными и собранными пакетами

Визуализация

В buildroot есть возможность по визуализации.Можно построить схему зависимостей, график времени сборки, график размера пакетов в итоговой системе. Результаты в виде pdf файлов( на выбор есть svn,png) в каталоге output/graph.

Примеры команд визуализации:

• make graph-depends построить дерево зависимостей
• make

-graph-depends построить дерево зависимостей конкретного пакета

BR2_GRAPH_OUT=png make graph-build построить график времени сборки с выводом в PNG

make graph-size построить график размера пакетов

Полезные скрипты

В каталоге buildroot есть подкаталог utils c полезными скриптами. Например, там есть скрипт, проверяющий корректность описания пакетов. Это может быть полезно при добавлении своих пакетов (я это сделаю позже). В файле utils/readme.txt есть описание этих скриптов.

Соберем cтоковый дистрибутив

Важно напомнить, что все операции ведутся от лица обычного пользователя, не root.
Все команды выполняются в корне buildroot. В поставке buildroot уже есть набор конфигураций под многие распространённые платы и виртуализацию.

Смотрим список конфигураций:

Переключаемся на конфиг qemu_x86_64_defconfig

И запускаем сборку

Сборка завершается успешно, смотрим на результаты:

Buildroot собрал образы, которые можно запустить в Qemu и убедиться, что они работают.

Результат — запущенная в qemu система:

Создание конфигурации собственной платы

Добавление файлов платы

Смотрим список конфигураций:

В списке видим pc_x86_64_efi_defconfig. Мы создадим свою плату, скопировав её с конфигурации:

Сразу же создадим каталог платы для хранения своих скриптов, rootfs-overlay и прочих нужных файлов:

Переключаемся на этот defconfig:

Таким образом, теперь конфиг сборки (хранится в .config в корне каталога buildroot’а) соответствует целевой машине x86-64 legacy(bios) загрузкой.

Скопируем конфигурацию linux-kernel (пригодится в дальнейшем):

Настройка параметров сборки через KConfig

Откроется окно KConfig. Есть возможность конфигурировать с графическим интерфейсом (make nconfig, make xconfig, make gconfig):

Входим в первый раздел Target Options. Здесь можно выбрать целевую архитектуру, под которую будет вестись сборка.

Build options — здесь есть различные настройки сборки. Можно указать каталоги с исходными кодами, количество потоков сборки, зеркала для скачивания исходных кодов и прочие настройки. Оставим настройки по-умолчанию.

Toolchain – здесь настраивается сам инструментарий сборки. О нем подробнее.

Toolchain type – тип используемого тулчейна. Это может быть встроенный в buildroot или внешний тулчейн (можно указать каталог с уже собранным или url для скачивания). Для разных архитектур есть дополнительные опции. Например, для arm можно просто выбрать версию внешнего тулчейна Linaro.

C library – выбор библиотеки С. От этого зависит работа всей системы. Обычно используется glibc, поддерживающая весь возможный функционал. Но она может оказаться слишком большой для встроенной системы, поэтому часто выбирают uglibc или musl. Мы выберем glibc (в дальнейшем это потребуется для использования systemd).

Kernel Headers и Custom Kernel Headers series – должно совпадать с версией ядра, которое будет в собираемой системе. Для kernel headers можно так же указать путь к тарболу или git-репозиторий.

GCC COMPILER VERSIONS – выбор версии компилятора, которая будет использована для сборки
Enable C++ support – выберем для сборки с поддержкой библиотек c++ в системе. В дальнейшем нам это пригодится.

Additional gcc options – можно задать дополнительные опции компилятора. Нам без надобности пока что.

System configuration позволяет задать будущие параметры созданной системы:

Большинство пунктов понятны из названия. Обратим внимание на следующие пункты:
Path to the users tables — таблица с создаваемыми пользователями (https://buildroot.org/downloads/manual/manual.html#makeuser-syntax).

Пример файла. Будет создан пользователь user с паролем admin, автоматически gid/uid, /bin/sh шеллом, группой по-умолчанию user, член группы root, комментарием Foo user

Root filesystem overlay directories — каталог, накладываемый поверх собранной target-fs. Добавляет новые файлы и заменяет имеющиеся.

Custom scripts to run before creating filesystem images — Скрипты, выполняемые непосредственно перед сворачиванием файловой системы в образы. Сам скрипт пока оставим пустым

Перейдём в раздел Kernel

Здесь задаются настройки ядра. Само ядро конфигурируется через make linux-menuconfig.
Задать версию ядра можно по-разному: выбрать из предложенных, ввести версию вручную, указать репозиторий или готовый tarball.

Kernel configuration — путь к конфигу ядра. Можно выбрать конфигурацию по-умолчанию для выбранной архитектуры или defocnfig из Linux. В исходниках Linux есть набор defconfig’ов для разных целевых систем. НАйти нужный можно, глянув напрямую в исходники здесь. Например, для платы beagle bone black можно выбрать конфиг.

Раздел Target packages позволяет выбрать, какие пакеты будут установлены в собираемую систему. Пока оставим без изменений. Позже мы добавим свои пакеты в этот список.
Filesystem images — список образов файловых систем, которые будут собраны. Добавим iso-образ

Bootloaders — выбор собираемых загрузчиков. Выберем isolinix

Конфигурирование Systemd

Systemd становится одним из столбов linux, наравне с kernel и glibc. Поэтому вынес его настройку в отдельный пункт.

Настраивается через make menuconfig, далее Target packages → System tools → systemd. Здесь можно указать, какие службы systemd будут установлены и запущены при старте системы.

Сохранение конфигурации системы

Сохраняем этот конфиг через KConfig.

После чего сохраним наш defconfig:

Конфигурирование ядра Linux

Конфигурирование ядра linux вызывается следующей командой:

Добавим поддержку видеокарты Virtualbox

Добавим Virtualbox Guest integration support

Сохраняем и выходим. ВАЖНО: конфигурация сохранится в output/build/linux-$version/config, но не в board/my_x86_board/linux.config

Поэтому нужно вручную скопировать конфиг в место хранения:

После чего выполним полную пересборку всей системы.Т.к. buildroot не пересобирает уже собранное, то надо вручную указать пакеты для пересборки. Чтобы не терять время и нервы, небольшую систему проще пересобрать целиком):

По завершении сборки запускаем VirtualBox(проверялось на версии 5.2 и 6.0) с загрузкой с cd-диска.Параметры системы:

Источник

Zynq 7000. Собираем Linux и RootFS при помощи Buildroot

Продолжаем изучение SoC Zynq 7000 и разбираемся с тем, как организовать подготовку, сборку Linux для отладочной платы QMTech. В прошлой статье я рассмотрел процедуру быстрой сборки (без кастомизации) основных компонентов встраиваемой системы Linux и шаг за шагом прошли путь до приглашения к вводу в работающей ОС. Согласитесь, что если вы новичок — то работа была выполнена колоссальная! К счастью, всю эту работу можно автоматизировать! И в этой статье я хотел бы уделить внимание этому вопросу и рассказать как это сделать с помощью Buildroot. Эту статью можно считать логическим продолжением общего повествования о начале работы с Linux на Zynq.

Что такое Buildroot, как им пользовать и чем он может быть полезен для нас — я постараюсь раскрыть в этой статье, без углубления в дебри, но в достаточной степени, чтобы вы могли повторить за мной всю последовательность действий и получить желаемый результат.

Всем интересующимся — добро пожаловать под кат!

Важно! Перед началом повествования, хотелось бы заранее оговориться, что основная цель, которую я преследую при написании этой статьи — рассказать о своем опыте, с чего можно начать, при изучении отладочных плат на базе Zynq. Я не являюсь профессиональным разработчиком под ПЛИС и SoC Zynq, не являюсь системным программистом под Linux и могу допускать какие-либо ошибки в использовании терминологии, использовать не самые оптимальные пути решения задач, etc. Но отмечу, что любая конструктивная и аргументированная критика только приветствуется. Что ж, поехали…

Что такое Buildroot и зачем он нужен?

В предыдущей статье мы полностью в ручном режиме собрали всё необходимое для работы операционной системы. Учитывая объем проделанной работы и количество затраченного времени — ручная сборка не выглядит чем-то эффективным и быстрым.

Чтобы решить эту проблему профессионалы придумали нечто такое, что позволило бы автоматизировать всю процедуру сборки, настройки всего необходимого! Звучит заманчиво, не правда ли?

В результате реализации этой идеи на свет появился Buildroot! Это система автоматизированной сборки на основе GNU Make и Kconfig.

Основная идея автоматизированной сборки состоит в том, что эта система должна уметь собрать из полученного исходного кода с репозиториев всё необходимо для работы, набор для кросс-компиляции, всех инструментов, начальный загрузчик, ядро ОС, откомпилированный файл device-tree и корневую файловую систему.

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

Общая последовательность шагов которые выполняются при работе с системами сборки мне видится таковой:

Конфигурирование. В этом шаге выполняется настройка всего того, что будет в последствии собрано: от загрузчика до программ которые будут скомпилированы и включены в корневую файловую систему. Самый трудоемкий и объемный шаг, который в последствии облегчается тем, что наработки можно сохранять в файлы конфигурации и детальная настройка нужна только один раз. В дальнейшем можно переиспользовать уже готовую конфигурацию.

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

Сборка и компиляция исходных кодов. Занимает достаточно много времени, длительность зависит от объема выбранных программ и того, насколько сложную систему вы хотите собрать.

Создание корневой файловой системы и конечная компоновка.

Создание финальных образов с возможностью выбора их форматов, пригодных для загрузки на устройстве.

В дополнение к этому, есть еще ряд плюшек которые предоставляются системой сборки:

Можно добавлять свои программы и пакеты.

Есть возможность выбора различных профилей файловой системы, с оптимизацией по размеру. с поддержкой разных опций влияющих на размер образа.

Очень удобно использовать при создании автономного SDK и распространения его среди других разработчиков.

Возможность создавать обновления, которые можно применить к уже установленным системам.

Наличие удобного интерфейса для взаимодействия с пользователем.

Наверняка, пытливый пользователь может спросить “А ведь есть же PetaLinux который базируется на Yocto. Зачем нужен buildroot?”. И я немного разобравшись в вопросе смело могу заявить, что это абсолютно две разные системы которые подходят к решению задачи сборки довольно таки разных по сложности и преследуют совершенно разные цели.

Основная цель Buildroot — это сборка именно образа корневой файловой системы, хоть она и умеет собирать загрузчик, DTS, и образ ядра.

А что касается Yocto — это полноценная система подготовки дистрибутива Linux. Это более общая система в том, смысле что позволяет описать целевое устройство и способна собирать полновесные дистрибутивы для весьма сложных устройств. Каждый компонент в Yocto генерируется в виде пакетов RPM, DPKK или IPK и после этого все пакеты собираются в цельный образ файловой системы.

Возможно когда-нибудь в будущем я попробую разобраться и с Yocto, но точно не в этой статье. Едем дальше…

Переходим от разговоров к делу!

Сразу отмечу основные моменты касающиеся с источниками полезной информации. Сайт проекта buildroot находится по адресу http://buildroot.org/. На сайте находится очень подробная документация https://buildroot.org/downloads/manual/manual.html/. По большинству вопросов и для углубленного изучения — можно обращаться к ней.

Что касается используемых версий. Разработчики Buildroot выпускают стабильные версии четыре раза в год: в феврале, мае, августе и ноябре. В этой связи в Git-репозитории им соответствуют метки вида . . Обычно при начале работы с buildroot имеет смысл взять последнюю стабильную версию, но они редко обновляются после выпуска. Рекомендую все время использовать последнюю стабильные версии по мере их выхода.

Перейдем к установке

Как обычно все начинается с клонирования репозитория на локальный компьютер. Привожу пример получения последней версии на момент написания статьи:

После клонирования репозиториев необходимо установить все требуемые зависимости:

Конфигурирование

Основная сущность, которой оперирует buildroot — это файлы defconfig, которые относятся к той или иной целевой плате. В этом файле хранятся все настройки которые отличаются от тех, что заданы по умолчанию.

Давайте посмотрим, что находится рабочем каталоге buildroot:

board — каталог с файлами, которые относятся к конкретным платам. Тут могут быть скрипты, каталог rootfs_overlay, конфигурацию ядер;

configs — в этой папке находятся те самые файлы defconfig;

dl — каталог со скачанными файлами исходного кода;

Всё, что будет скомпилировано будет положено в папку output, либо в папку указанную в параметрах компиляции с ключом O= , в которой появятся два основных каталога:

host — папка с утилитами для сборки на хосте;

build — папка с собранными пакетами;

На подробном объяснении каждой команды мы останавливаться не будем, все что нужно — можно найти в документации на buildroot.

Создадим файл, запуская который у нас будет открываться меню конфигурации:

Запишем в него следующее:

После этого можно запустить этот файл и если все необходимые зависимости установлены — будет открыто меню конфигурации buildroot:

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

Первым пунктом заходим в меню Target options и выбираем архитектуру ARM (little endian) и выбираем вариант архитектуры Cortex-A9, что собственно соответствует тому, что мы имеем на плате. Устанавливаем также опции связанные с Hard Floating Point. После проведения правильной конфигурации окно примет следующий вид:

Переходим обратно в главное меню и заходим в меню Build options. Для ускорения процедуры сборки можно поставить опцию Number of jobs to run simultaneously в соответствии с количеством ядер CPU. Остальные опции оставляем по умолчанию.

Переходим к настройке Toolchain.

В нашем случае мы воспользуемся toolchain встроенным в Buildroot. Оставляем без изменений пункт Toolchain type.

Меняем используемую C library на glibc.

В пункте Kernel Headers выбираем Custom Git Repository и в меню URL of custom repository указываем путь, к cклонированному в прошлом занятии, ядру Linux. Либо клонируем репозиторий в папку /home:

После в поле Custom repository version необходимо указать хэш текущего указателя на master-ветку в репозитории:

Смотрим версию ядра, склонированную в репозитории linux-xlnx:

Будет выведено окно настройки конфигурации ядра для последующего компилирования и в заголовке будет указана версия:

Выбираем версию ядра 5.10.х в опции Custom kernel headers series.

Устанавливаем опцию Install glibc utilities.

Выбираем версию компилятора gcc установленного в системе . Узнать версию gcc можно через команду gcc -v. В моем случае это gcc 9.x. Установим его в поле GCC compiler Version.

Установим поддержку C++ в поле Enable C++ support.

Далее выбираем опции Enable compiler link-time-optimization support.

Ставим поддержку мультипроцессорного компилятора OpenMP в поле Enable compiler OpenMP support.

Переходим в меню System configuration и тут по желанию можно написать имя целевой системы и приветственное лого. Я указал в поле System hostname Z7020, а в System banned Welcome to QMtech Zynq Linux!. Остальные пункты меню оставляю по умолчанию.

Переходим в меню Kernel. Если вы хотите, чтобы вместе с rootfs было так же собрано ядро Linux — включите опцию Linux kernel.

Настроим параметры ядра для последующей компиляции следующим образом.

Таким же образом указываем Custom Git repository с указанием пути до репозитория и хэша.

Указываем что корневой файл конфигурации будем использовать из in-tree источника: Kernel configuration (Using an in-tree defconfig file).

Файл defconfig указываем тот, что использовали по умолчанию при компиляции ядра в прошлом уроке: записываем в поле Defconfig name xiinx_zynq без постфикса “_defconfig”.

Выбираем опцию Kernel binary format и ставим uImage и тип компрессии gzip

Устанавливаем адрес загрузки Load address в 0x8000.

Остальные опции в этом меню остаются по умолчанию. Выглядит меню настройки следующим образом:

Переходим в меню Target options. В этом меню мы можем выбрать весь набор необходимых программ которые будут включены в состав будущего образа.

Miscelaneous — haveged, который является базовым демоном для генерации случайных чисел;

Networking — dhcpd, демон для работы с сетью и получения сетевых реквизитов по протоколу DHCP;

Networking — dropbear, демон для организации SSH-сервера;

Networking — ifupdown scripts, для работы с сетевыми интерфейсами;

Networking — iperf, iperf3, для проведения бенчмарка пропускной способности по сети (по желанию);

Переходим в меню Filesystem images. Выбираем интересующие нас образы, я выбираю только cpio и метод сжатия lzma.

Поскольку у нас будет использоваться свой кастомный загрузчик — пункт меню Bootladers пропускаем.

В меню Host Utilites ставим опции:

host dosfstools

host genimage

host mtools

Все настройки завершены, записываем их путем нажатия клавиши F6 сохраняем файл с именем .config.

На этом мы можем считать, что предварительная настройка Linux закончена. Можно запускать компиляцию. Для этого я сделал скрипт br-build и записал в него следующее:

После этого необходимо присвоить ему права на исполнение и запустить:

Если все указано и настроено верно — начнется процедура скачивания исходных кодов и компиляция. Этот процесс может затянуться на многие десятки минут.

После окончания компиляции в папке images/ появятся необходимые образы:

Для того, чтобы можно было воспользоваться образом rootfs — необходимо сделать подпись для загрузки его через U-Boot. Для этого нам понадобится пакет U-Boot-tools:

После этого можно попробовать загрузить то, что у нас получилось. Копируем на загрузочную microSD файлы uImage и uramdisk.image.gz и файл devicetree.dtb который у нас был сделан в прошлом занятии.

Проверим, что получилось

Запускаем плату и попадаем в меню U-Boot. В этом меню вводим команды:

Если все получилось верно — у нас загрузится ядро, все программы которые мы указали при старте уже будут в составе ОС. И все будет готово к работе.

В целом основная задача выполнена и достигнутое можно считать хорошей заготовкой для дальнейшей кастомизации используемого образа Linux. Можно пробовать добавлять свои скрипты и проводить более углубленное изучение buildroot, например, осуществить сборку Device Tree через buildroot.

Источник