Продолжаем изучение SoC Zynq 7000 и разбираемся с тем, как организовать подготовку, сборку Linux для нашей отладочной платы QMTech. В прошлой статье я рассмотрел процедуру быстрой сборки (без кастомизации) основных компонентов встраиваемой системы Linux и шаг за шагом прошли путь до приглашения к вводу в работающей ОС. Согласитесь, что если вы новичок - то работа была выполнена колоссальная! К счастью, всю эту работу можно автоматизировать! И в этой статье я хотел бы уделить внимание этому вопросу и рассказать как это сделать с помощью Buildroot. Эту статью можно считать логическим продолжением общего повествования о начале работы с Linux на Zynq.
Что такое Buildroot, как им пользовать и чем он может быть полезен для нас - я постараюсь раскрыть в этой статье, без углубления в дебри, но в достаточной степени, чтобы вы могли повторить за мной всю последовательность действий и получить желаемый результат.
Всем интересующимся - добро пожаловать под кат!
Важно! Перед началом повествования, хотелось бы заранее оговориться, что основная цель, которую я преследую при написании этой статьи - рассказать о своем опыте, с чего можно начать, при изучении отладочных плат на базе Zynq. Я не являюсь профессиональным разработчиком под ПЛИС и SoC Zynq, не являюсь системным программистом под Linux и могу допускать какие-либо ошибки в использовании терминологии, использовать не самые оптимальные пути решения задач, etc. Но отмечу, что любая конструктивная и аргументированная критика только приветствуется. Что ж, поехали…
Рекомендуемые источники для более глубокого изучения
Перед началом повествования хотелось бы отдельно отметить источники информации, которые помогли мне при подготовке этого материала:
Книга Криса Симмондса Встраиваемые системы на основе Linux.
Стрим ребят из команды FPGA-Systems.ru по сборке Linux: https://www.youtube.com/watch?v=339hpNuRZDo
Стрим компании Макро-Групп по сборке Linux: https://www.youtube.com/watch?v=aBFiVaTka6s
Стрим Алексея Ростова в двух частях: https://www.youtube.com/watch?v=Xn5cs9uh8gc и https://www.youtube.com/watch?v=PxGK7h_DYfE
Что такое 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 имеет смысл взять последнюю стабильную версию, но они редко обновляются после выпуска. Рекомендую все время использовать последнюю стабильные версии по мере их выхода.
Перейдем к установке
Как обычно все начинается с клонирования репозитория на локальный компьютер. Привожу пример получения последней версии на момент написания статьи:
megalloid@pc:~/Desktop$ cd
megalloid@pc:~$ git clone git://git.buildroot.net/buildroot
Cloning into 'buildroot'...
remote: Enumerating objects: 45749, done.
remote: Counting objects: 100% (45749/45749), done.
remote: Compressing objects: 100% (23910/23910), done.
remote: Total 422643 (delta 29805), reused 33912 (delta 21727), pack-reused 376894
Receiving objects: 100% (422643/422643), 92.41 MiB | 893.00 KiB/s, done.
Resolving deltas: 100% (293487/293487), done.
megalloid@pc:~$ cd buildroot/
megalloid@pc:~/buildroot$ git checkout 2021.05.x
Branch '2021.05.x' set up to track remote branch '2021.05.x' from 'origin'.
Switched to a new branch '2021.05.x'
После клонирования репозиториев необходимо установить все требуемые зависимости:
megalloid@pc:~$ sudo apt install make binutils build-essential gcc g++ patch gzip bzip2 perl tar cpio unzip rsync bc libncurses-dev -y
Конфигурирование
Основная сущность, которой оперирует buildroot - это файлы defconfig, которые относятся к той или иной целевой плате. В этом файле хранятся все настройки которые отличаются от тех, что заданы по умолчанию.
Давайте посмотрим, что находится рабочем каталоге buildroot:
board - каталог с файлами, которые относятся к конкретным платам. Тут могут быть скрипты, каталог rootfs_overlay, конфигурацию ядер;
configs - в этой папке находятся те самые файлы defconfig;
dl - каталог со скачанными файлами исходного кода;
Всё, что будет скомпилировано будет положено в папку output, либо в папку указанную в параметрах компиляции с ключом O=<путь>, в которой появятся два основных каталога:
host - папка с утилитами для сборки на хосте;
build - папка с собранными пакетами;
megalloid@pc:~$ cd buildroot/
megalloid@pc:~/buildroot$ make help
На подробном объяснении каждой команды мы останавливаться не будем, все что нужно - можно найти в документации на buildroot.
megalloid@pc:~/buildroot$ cd
megalloid@pc:~$ cd Zynq/Projects/buildroot
megalloid@pc:~/Zynq/Projects/buildroot$ mkdir -p board/qmtech/z7020/rootfs_overlay
megalloid@pc:~/Zynq/Projects/buildroot$ mkdir -p board/qmtech/z7020/patches
megalloid@pc:~/Zynq/Projects/buildroot$ mkdir configs
megalloid@pc:~/Zynq/Projects/buildroot$ mkdir -p package/qmtech/package1
Создадим файл, запуская который у нас будет открываться меню конфигурации:
megalloid@pc:~/Zynq/Projects/buildroot$ touch br_config
megalloid@pc:~/Zynq/Projects/buildroot$ vi br_config
megalloid@pc:~/Zynq/Projects/buildroot$ chmod +x br_config
Запишем в него следующее:
#!/bin/sh
make -C /home/megalloid/buildroot O=$PWD ARCH=arm nconfig
После этого можно запустить этот файл и если все необходимые зависимости установлены - будет открыто меню конфигурации 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:
megalloid@pc:~/Desktop$ cd
megalloid@pc:~$ git clone https://github.com/Xilinx/linux-xlnx
После в поле Custom repository version необходимо указать хэш текущего указателя на master-ветку в репозитории:
megalloid@pc:~/linux-xlnx$ git show-ref | grep master
d25c42dcc2a9fed0d00f4f20eded4aa733d51d5b refs/heads/master
Смотрим версию ядра, склонированную в репозитории linux-xlnx:
megalloid@pc:~/linux-xlnx$ make menuconfig
Будет выведено окно настройки конфигурации ядра для последующего компилирования и в заголовке будет указана версия:
Выбираем версию ядра 5.10.х в опции Custom kernel headers series.
Устанавливаем опцию Install glibc utilities.
Выбираем версию компилятора gcc. В моем случае это 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 banner - 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 и записал в него следующее:
#!/bin/sh
sudo make -C /home/megalloid/buildroot O=$PWD
ARCH=arm BR2_JLEVEL="$(($(nproc) - 1))"
После этого необходимо присвоить ему права на исполнение и запустить:
megalloid@pc:~/Zynq/Projects/buildroot$ chmod +x br_build
megalloid@pc:~/Zynq/Projects/buildroot$ ./br_build
Если все указано и настроено верно - начнется процедура скачивания исходных кодов и компиляция. Этот процесс может затянуться на многие десятки минут.
После окончания компиляции в папке images/ появятся необходимые образы:
megalloid@pc:~/Zynq/Projects/buildroot$ ls -ls images/
total 37376
14000 -rw-r--r-- 1 root root 14335488 июл 12 17:58 rootfs.cpio
3940 -rw-r--r-- 1 root root 4034206 июл 12 17:58 rootfs.cpio.lzma
15060 -rw-r--r-- 1 root root 15421440 июл 12 17:58 rootfs.tar
4376 -rw-r--r-- 1 root root 4478424 июл 12 17:58 uImage
Для того, чтобы можно было воспользоваться образом rootfs - необходимо сделать подпись для загрузки его через U-Boot. Для этого нам понадобится пакет U-Boot-tools:
megalloid@pc:~/Zynq/Projects/buildroot/images$ sudo apt install u-boot-tools
megalloid@pc:~/Zynq/Projects/buildroot/images$ sudo mkimage -A arm -T ramdisk -C gzip -d rootfs.cpio uramdisk.image.gz
Image Name:
Created: Mon Jul 12 19:28:22 2021
Image Type: ARM Linux RAMDisk Image (gzip compressed)
Data Size: 14335488 Bytes = 13999.50 KiB = 13.67 MiB
Load Address: 00000000
Entry Point: 00000000
После этого можно попробовать загрузить то, что у нас получилось. Копируем на загрузочную microSD файлы uImage и uramdisk.image.gz и файл devicetree.dtb который у нас был сделан в прошлом занятии.
Проверим, что получилось
Запускаем плату и попадаем в меню U-Boot. В этом меню вводим команды:
fatload mmc 0 0x2000000 uImage
fatload mmc 0 0x2A00000 system.dtb
fatload mmc 0 0x3100000 uramdisk.image.gz
bootm 0x2000000 0x3100000 0x2A00000
Если все получилось верно - у нас загрузится ядро, все программы которые мы указали при старте уже будут в составе ОС. И все будет готово к работе.
В целом основная задача выполнена и достигнутое можно считать хорошей заготовкой для дальнейшей кастомизации используемого образа Linux. Можно пробовать добавлять свои скрипты и проводить более углубленное изучение buildroot, например, осуществить сборку Device Tree через buildroot.
Дерзайте! =)
andreykorol
при клонировании большого git репозитория, если он нужен только для сборки и вся история не нужна, то добавляю --depth=1
megalloid Автор
Спасибо, возьму на заметку)