кросс компиляция ядра linux

Кросс-компиляция в OS X под Linux используя crosstool-ng

В данном руководстве рассматривается не столько кросс-компиляция по архитектуре, сколько кросс-компиляция по системе — сборка под Linux в Darwin.

Disclaimer

В интернете есть несколько статей по сборке crosstool-ng под OS X, например на benmont.com и в официальном руководстве. Тем не менее, в некоторых статьях встречается множество ошибок и устаревших сведений, а в других описываются лишь общие черты. Здесь будет описан мой путь, по которому я успешно собрал toolchain в июле 2013.

Подготовка

Эта часть зависит от того, какой пакетный менеджер вы используете в OS X — MacPorts или Homebrew. Я для себя давно выбрал ports-way, так что буду писать исходя из этого.

1. Регистрозависимая файловая система

2. Инструменты

Предполагается, что у вас установлен MacPorts. Установим следующие пакеты:

3. Установка crosstool-ng

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

Вынужден прервать официальную инструкцию: в файле kconfig/zconf.hash.c не хватает строчки

Это потому, что ct-ng случайно хавает версию gstat из GNU-набора, вместо оригинального stat из OS X. Полюбуйтесь красотой и изящностью здешнего кода и закройте файл.

Настройка crosstool-ng

Прежде чем начать настройку, унаследуем конфигурацию от шаблона. Нас интересует x86_64-unknown-linux-gnu :

После этого вы видите меню, в котором мы будем настраивать наш инструментарий.

1. Paths and misc options

2. C compiler

3. Debug facilities

4. Companion libraries

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

Сборка toolchain

Практически всё готово. В процессе сборки может возникнуть следующая ошибка (версия ядра указана моя):

Ещё нужно подправить лимит открытых файлов (RE: Libc iconvdata compilation problem):

Если во время сборки у вас возникнет ошибка в gdb, если вы не отключили [*] Enable python scripting раньше:

Кажется, всё готово.

Заключение

Источник

Ускорение процесса разработки под Embedded Linux

Любой программист, решивший заняться разработкой под Embedded Linux, придя будь то из высокоуровневых языков программирования, либо из программирования микроконтроллеров на С/С++, неизбежно оказывается удивлен крайней недружелюбностью embedded linux. Текстовый блокнот и консольные утилиты вместо столь привычных IDE, и отладка по логам вместо отладки программатором сильно замедляют процесс разработки. В статье описывается, как мне удалось снизить время доставки изменений до целевого железа при кросс-компиляции в 10 раз.

Кросс-компиляция

Под кросс-компиляцией подразумевается процесс, когда сборка прошивки целевой железки (target device) под управлением Embedded Linux производится на удаленной машине (host machine), которой, как правило, является обычный ПК. С этим приходится сталкиваться при разработке кода под относительно слабые микропроцессоры с ограниченными объемами доступной оперативной и постоянной памяти (128 Мб и 32 Мб соответственно в нашем случае).

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

Доставка исходников программного кода до хоста (проводится лишь один раз при первой сборке прошивки). git clone в нашем случае.

Сборка всей прошивки целевой железки либо отдельного исполняемого файла на хосте. Утилитой make в нашем случае.

Доставка свеже-собранной прошивки/исполняемого файла до целевой платформы. Утилиты scp и sysupgrade в нашем случае.

Больше всего времени, естественно, уходит на второй этап. Особенно сильно он замедляется в случае работы с тяжеловесными библиотеками, тянущими за собой кучу зависимостей. В нашем случае это библиотеки tensorflow-lite (для нейронок) и alexa voice sdk (голосовой ассистент).

На все три этапа (полная пересборка прошивки и перепрошивка железки) у нас уходило 150 минут. Наиболее редко применяемый сценарий.

Третий этап сам по себе (при обновлении прошивки) занимал минут 5: вначале прошивка копировалась с хоста на целевое железо утилитой scp. После чего производилось обновление прошивки утилитой sysupgrade.

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

16 минут вместо 150 минут для всех трех этапов вместе при первой сборке прошивки;

3 минуты вместо 30 минут для второго этапа в случае пересборки всей прошивки и 1,5 минуты вместо 13 минут при перекомпиляции отдельного приложения.

10 секунд вместо 5 минут для третьего этапа самого по себе.

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

Ускоряем процесс кросс-компиляции

Долго сомневались, будет ли смысл, но все же пошли ва-банк, начитавшись статей о вдохновляющих бенчмарках, и раскошелились на рабочую станцию на базе процессора AMD Threadripper 3970X (64 ядра):

С утра принялся выжимать все соки из дорогостоящей покупки. Первым делом запустил htop параллельно с процессом компиляции. Лишь изредка наблюдал подобную картину:

но, чаще всего, такую:

Это говорило о том, что задействуются не все ядра. Ответ в интернете нашел быстро: Enable parallel builds by default?. Недолго думая закоммитил соответствующие изменения к себе в репу и получил заветные 3 минуты на пересборку прошивки и 1,5 минуты на пересборку приложения. htop показывал полную загрузку. Радости не было предела! Деньги не ушли на ветер!

Вдобавок к этому попробовал поиграться работой из RAMDISK:

но особого ускорения не заметил.

Но этот кейс довольно легко закрыл костылем. В сборочном скрипте заменил:

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

Ускоряем процесс обновления прошивки целевой железки

Погуляв на просторах интернета, узнал, что вместо копирования прошивки утилитой scp и ее обновления утилитой sysupgrade можно грузить и ядро, и файловую систему по сети, с помощью tftp и nfs.

Запуск TFTP сервера для загрузки ядра

Запуск на хосте командой:

После этого остается положить в каталог volume образ ядра (uImage). В моем случае это делается командой:

Исходники можно найти тут.

Все готово для загрузки ядра загрузчиком (u-boot, в нашем случае). Но перед тем как переключиться в консоль целевой железки проверьте состояние фаерволла:

и если он включен, то временно отключите его:

Загрузка ядра с tftp-сервера

Итак, первым делом сохраняем текущие настройки загрузки:

к которым вы в дальнейшем сможете вернуться в любой момент:

Теперь задаем сетевые настройки, чтобы u-boot знал, куда стучаться за образом ядра:

Попробуйте пингануть сервер:

Теперь попробуйте скачать образ с сервера:

Отлично. Значит пока нигде не напортачили и можно сохранять настройки и запускать ядро:

Теперь снова возвращайтесь в консоль U-boot и настройте автоматическую загрузку ядра с TFTP-сервера с последующей загрузкой:

Теперь u-boot должен будет автоматически грузить образ с сервера и стартовать с него. Файловая система, при этом, пока еще, будет использоваться дефолтная. Та, что у вашей железки во флеш-памяти/microSD-карте.

Запуск NFS-сервера для загрузки файловой системы

Для начала, аналогично tftp-серверу соберем и запустим в контейнере NFS-сервер.

запускаем точно также как и TFTP-сервер:

Программы разные ( tftp-hpa и nfs-kernel-server ), а запускаются одной и той же командой).

Осталось распаковать в каталог volume архив с файловой системой, который у вас должен был быть скомпилировать вместе с образом ядра. В моем случае:

Протестировать сервер можно с другой машины в той же сети командой:

Загрузка с NFS-сервера

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

В открывшемся окне нужно найти опцию Compile the kernel with rootfs on NFS. В моем случае она расположена по пути: Global build settings—>Kernel build options—>Compile the kernel with rootfs on NFS :

включить данную опцию, нажав кнопку Y

выйдите из конфигуратора, сохранив изменения.

пересоберите образ ядра по новой и сохраните результирующий uImage файл в каталоге volume вашего TFTP-сервера.

перезагрузите u-boot на всякий случай, если вдруг вы уже успели загрузить образ ядра командой tftp

Итак, единственная настройка в u-boot, необходима для того, чтобы примонтировать сетевую файловую систему вместо файловой системы, расположенной на флеш-накопителе:

Обратите внимание на вывод первой команды и запомните его.

После этого введите:

U-boot перезагрузится, передаст управление ядру. После этого введите:

Отлично! Сетевая файловая система примонтирована. Теперь любое изменение на хосте в каталоге volume TFTP-сервера будет моментально отображаться в файловой системе целевой железки. Для проверки можете в каталоге volume NFS-сервера (на хосте) создать какой-нибудь файл:

Он должен сразу же отобразиться в файловой системе железки:

Development и production режимы загрузки

В U-boot вы теперь можете любой момент включать отладочный (сетевой) режим загрузки:

таки и «продакшн» режим загрузки:

если ранее => printenv bootargs вам ничего не выдало.

В чем же его преимущества? В том, что любое изменение на хосте в каталоге volume TFTP-сервера будет моментально отображаться в файловой системе целевой железки. Дело осталось за малым написать скрипт, который будет копировать свеже-собранный образ ядра и распаковывать свеже-собранный архив файловой системы в соответствующие каталоги volume TFTP- и NFS-серверов. Таким образом, длительность третьего этапа (доставки изменений в коде) до целевой железки сокращается до 10 секунд в худшем случае (время перезагрузки ядра) при внесении изменений в ядро Линукс и до 0 секунд при внесении изменений в приложения пользовательского пространства!

Итоги

В общем, длительность наиболее типового сценария разработки кода (второй + третий этап): пересборки ядра либо пользовательского приложения с последующей доставкой на целевое железо удалось сократить с 30+ минут до 2-3 минут! Это дало возможность тестировать порядка 20 изменений в коде на целевой платформе, вместо 1-2 изменений ранее. Скорость разработки возросла на порядок! Даже не верится, что раньше я мирился с такими потерями времени!

Источник

Русские Блоги

Кросс-компиляция и развертывание ядра Raspberry Pi Linux

Получите исходный код ядра и инструменты

Ссылка на источник:

Ссылка на инструмент:

Если вы хотите загрузить другие версии ядра, например версию ядра 5.1.y, используйте следующий метод

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

Вышеуказанное предназначено для загрузки с помощью git, скорость загрузки в Китае относительно низкая. Если вы хотите скачивать на высокой скорости, вы можете использовать Thunder. Метод состоит в том, чтобы скопировать ссылку вверху браузера и скопировать ее в Thunder для поиска.

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

После завершения загрузки разархивируйте все файлы.

Хит патч

Мы добавляем патчи в ядро ​​Linux, это процесс исправления. Распакуйте сжатую версию патча, загруженного выше, в соответствующую папку ядра и выполните

Настроить среду кросс-компиляции

Для этого нужны инструменты, которые мы скачали. Папка, загруженная с помощью git, называется tools; папка, в которую загружается сжатая версия пакета, называется tool-master. Мы объясним с названием tools.

представление цифр системы ubuntu

Если в вашей системе ubuntu 32 бита, выполните

Если он 64-битный, выполните

В 64-битных системах также должна быть установлена ​​поддержка 32-битного компилятора.

Войдите в каталог исходного кода Linux, чтобы настроить кросс-компиляцию

Компилировать

Войдите в каталог исходного кода Linux и выполните

Этот процесс должен занять десятки минут, в зависимости от скорости компьютера. Подождите чашку чая

Развернуть на SD-карту

Сначала вставьте устройство чтения карт памяти с системой и смонтируйте его в виртуальной машине.

Просмотрите имя раздела в / dev

Далее монтируем его. Сначала создайте две папки в / mnt

Затем смонтируйте sdc1 и sdc2 на fat32 и ext4 соответственно

Сначала установите модуль ядра в / mnt / ext4, найдите папку с исходным кодом ядра и выполните

Следующие операции выполняются в загрузочном разделе / ​​mnt / fat32.

Переименуйте zImage в исходном коде ядра в kernel7.img (расположение: linux-rpi-4.9.y / arch / arm / boot)

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

Если есть ошибка компиляции python

/usr/bin/env python\r no such file or directory

Это связано с тем, что код Python, написанный под Windows, не соответствует спецификациям под Linux, используйте следующий метод для перекодирования

sudo apt-get install dos2unix

Скопируйте сгенерированное ядро ​​в / mnt / fat32

Пока что обновление ядра Raspberry Pi завершено, вставьте его в Raspberry Pi и попробуйте

Источник

Русские Блоги

содержание

Обзор

Я в основном слежуПолное руководство по разработке приложений для встроенных Linux, второе изданиеДля учебы. В процессе настройки среды разработки пошагово, согласно руководству по разработке, еще много проблем, о которых я расскажу ниже по очереди. Как новичку, мне потребовалось четыре или пять дней, чтобы создать среду разработки для компиляции ядра. Я поменял несколько виртуальных машин в середине. Я перепробовал все, от официального руководства по Firefly до руководств, опубликованных Вэй Дуншань. Я лично чувствую что они дают Кажется, что в учебнике пропущено много шагов. Мне не удалось выполнить шаги учебника. Очевидно, что вводится та же команда, но на моей стороне всегда есть различные проблемы, и есть много мест, где язык непонятный, люди не могут понять, и можно сказать, что они крайне недружелюбны к новичкам (не исключаю из-за моей еды). Вот мой новичок, который подробно описывает шаги по настройке среды разработки RK3288, я могу гарантировать, что, по крайней мере, я могу это понять (смеется).

готовы

Загрузите пакет BSP, соответствующий вашей собственной плате разработки:

Вэй Дуншань

Информация Совета по развитию Вэй Дуншань
Исходный код версии Wei Dongshan находится вПервый сезон обновленной версии полной серии встроенного видео Quick Start Password: 6FJkНайдите папку, соответствующую вашей собственной плате для разработки.Рекомендуется загрузить всю папку, и в ней есть много вещей, которые можно использовать позже.

Версия Firefly

Скачать официальные данные Firefly-RK3288Здесь следует отметить, что пакет SDK, загруженный с официального сайта firefly, необходимо скопировать на виртуальную машину Ubuntu, а затем снова скомпилировать для получения полного исходного кода.Вы можете напрямую загрузить исходный код Firefly, предоставленный Вэй Дуншань.Пароль пакета BSP: SVdnLinux3288-sdk внутри представляет собой полный исходный код firefly. После распаковки:

Рекомендуется загрузить Wei Dongshan’s, в следующем руководстве используется Wei Dongshan’s

Примечание

Структура хранения пакета SDK Wei Dongshan и официального пакета SDK Firefly различна:

Цепочка кросс-компиляции	Ядро
Вэй Дуншань	100ask_firefly-rk3288\ToolChain	100ask_firefly-rk3288\linux-4.4
Firefly	linux-sdk\prebuilts	linux-sdk\kernel

Программное обеспечение, которое будет использоваться

FileZilla

Функция: передача файлов между виртуальной машиной и компьютером
FileZill скачать

виртуальная машина

Виртуальная машина Ubuntu16.04 (я использовал, другие версии не знают, что будет)

Процесс установки

Перезагрузите виртуальную машину перед началом установки и откройте терминал

Установить предварительный пакет

Установка пакета Ubuntu 16.04:

Цепочка инструментов кросс-компиляции ARM и программные пакеты для компиляции ядра:

Установите инструмент mkbootimg

Это много программных пакетов, после того, как вы их установите,
Если он не будет установлен в течение следующего года, возникнет ошибка

Получите исходный код ядра и исходный код цепочки инструментов кросс-компиляции

Настроить набор инструментов кросс-компиляции

Настроить набор инструментов кросс-компиляции

Цепочка инструментов кросс-компиляции в основном используется для компиляции на хосте ubuntu и утверждает, что может работать на других платформах.
Настройка инструмента кросс-компиляции в основном заключается в настройке трех переменных среды PATH, ARCH и CROSS_COMPILE. Ниже описаны конкретные методы настройки, а одноразовая настройка действует постоянно:
Измените файл конфигурации пользователя в системе Ubuntu, измените его следующим образом:

Добавьте или измените в конце строки: Путь ко второй строке изменяется в соответствии с вашим собственным именем файла

Набор инструментов для кросс-компиляции тестов

Переменные тестовой среды:

Протестируйте кросс-компилятор:

Скомпилируйте ядро

Разархивируйте исходный код ядра

Если вы загружаете код локально в Ubuntu, войдите в каталог ядра и разархивируйте исходный код ядра:

Примечание. Если вы используете код онлайн-синхронизации репозитория, описанный выше этап декомпрессии не требуется.

Скомпилируйте ядро

Примечание. Сначала необходимо установить цепочку инструментов кросс-компиляции и задать переменные среды.
Разным платам разработки соответствуют разные файлы конфигурации. Файл конфигурации находится в каталоге linux4.4 / arch / arm / configs / под

Версия Firefly

Чтобы установить пакет SDK, предоставляемый Firefly, вам нужно только изменить путь цепочки инструментов кросс-компиляции. Наконец, укажите на папку bin При компиляции ядра компилируйте его в папке ядра.

Источник

Кросскомпиляция под ARM

Достаточно давно хотел освоить сабж, но всё были другие более приоритетные дела. И вот настала очередь кросскомпиляции.

В данном посте будут описаны:

Вводная

Одно из развивающихся направлений в современном IT это IoT. Развивается это направление достаточно быстро, всё время выходят всякие крутые штуки (типа кроссовок со встроенным трекером или кроссовки, которые могут указывать направление, куда идти (специально для слепых людей)). Основная масса этих устройств представляют собой что-то типа «блютуз лампочки», но оставшаяся часть являет собой сложные процессорные системы, которые собирают данные и управляют этим огромным разнообразием всяких умных штучек. Эти сложные системы, как правило, представляют собой одноплатные компьютеры, такие как Raspberry Pi, Odroid, Orange Pi и т.п. На них запускается Linux и пишется прикладной софт. В основном, используют скриптовые языки и Java. Но бывают приложения, когда необходима высокая производительность, и здесь, естественно, требуются C и C++. К примеру, может потребоваться добавить что-то специфичное в ядро или, как можно быстрее, высчитать БПФ. Вот тут-то и нужна кросскомпиляция.

Если проект не очень большой, то его можно собирать и отлаживать прямо на целевой платформе. А если проект достаточно велик, то компиляция на целевой платформе будет затруднительна из-за временных издержек. К примеру, попробуйте собрать Boost на Raspberry Pi. Думаю, ожидание сборки будет продолжительным, а если ещё и ошибки какие всплывут, то это может занять ох как много времени.

Поэтому лучше собирать на хосте. В моём случае, это i5 с 4ГБ ОЗУ, Fedora 24.

Инструменты

Для кросскомпиляции под ARM требуются toolchain и эмулятор платформы либо реальная целевая платформа.

Т.к. меня интересует компиляция для ARM, то использоваться будет и соответствующий toolchain.

Toolchain’ы делятся на несколько типов или триплетов. Триплет обычно состоит из трёх частей: целевой процессор, vendor и OS, vendor зачастую опускается.

Сперва я пытался использовать toolchain’ы, которые лежат в репах Fedora 24. Но был неприятно удивлён этим:

Поискав, наткнулся на toolchain от компании Linaro. И он меня вполне устроил.

Второй инструмент- это QEMU. Я буду использовать его, т.к. мой Odroid-C1+ пал смертью храбрых (нагнулся контроллер SD карты). Но я таки успел с ним чуток поработать, что не может не радовать.

Элементарная технология кросскомпиляции

Собственно, ничего необычного в этом нет. Просто используется toolchain в роли компилятора. А стандартные библиотеки поставляются вместе с toolchain’ом.

Какие ключи у toolchain’а можно посмотреть на сайте gnu, в соответствующем разделе.

Для начала нужно запустить эмуляцию с интересующей платформой. Я решил съэмулировать Cortex-A9.

После нескольких неудачных попыток наткнулся на этот how2, который оказался вполне вменяемым, на мой взгляд.

Ну сперва, само собою, нужно заиметь QEMU. Установил я его из стандартных репов Fedor’ы.

Далее создаём образ жёсткого диска, на который будет установлен Debian.

По этой ссылке скачал vmlinuz и initrd и запустил их в эмуляции.

Далее просто устанавливаем Debian на наш образ жёсткого диска (у меня ушло

После установки нужно вынуть из образа жёсткого диска vmlinuz и initrd. Делал я это по описанию отсюда.

Сперва узнаём смещение, где расположен раздел с нужными нам файлами:

Теперь по этому смещению примонтируем нужный нам раздел.

Копируем файлы vmlinuz и initrd и размонтируем жёсткий диск.

Теперь можно запустить эмуляцию.

И вот заветное приглашение:

Теперь с хоста по SSH можно подцепиться к симуляции.

Теперь можно и собрать программку. По Makefile’у ясно, что будет калькулятор. Простенький.

Собираем на хосте исполняемый файл.

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

Копируем исполняемый файл на таргет и проверяем.

Собственно, вот такая она, эта кросскомпиляция.

UPD: Подправил информацию по toolchain’ам по комментарию grossws.

Источник