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 и корневую файловую систему. 

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

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

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

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

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

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

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

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

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

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

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

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

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

Наверняка, пытливый пользователь может спросить “А ведь есть же 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. 

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

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

  3. В пункте 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
  1. Будет выведено окно настройки конфигурации ядра для последующего компилирования и в заголовке будет указана версия: 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  18. Обязательные опции:

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

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

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

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

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

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

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

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

    1. host dosfstools

    2. host genimage

    3. host mtools

  22. Все настройки завершены, записываем их путем нажатия клавиши 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.

Дерзайте! =)

Источник: https://habr.com/ru/post/567408/


Интересные статьи

Интересные статьи

Всем привет. В компании Convergent, где я работаю, в проектные команды часто входят несколько разработчиков: это могут быть специалисты по бэкенду, фронтенду и/или вёрстк...
В прошлом году китайская компания Huawei стала активно искать альтернативные пути развития. Это случилось после того, как США наложили жесткие санкции, которые лишь усилились с течением...
Будучи наивным чукотским программистом, я думал: "питон такой кроссплатформенный, напишу игрушку для сына, запущу на планшетике, пусть играется". В результате две недели ...
Китайская компания Huawei после наложения на нее санкций со стороны США ищет способы решить эту проблему. Один из способов — разработка собственной операционной системы для планшетов, ...
В последние полгода удалось поработать над большим и интересным проектом, в котором было все: от монтажа оборудования до создания единого VXLAN/EVPN домена в 4-х ЦОД. Т.к. было получено м...