Кросскомпиляция под ARM
Достаточно давно хотел освоить сабж, но всё были другие более приоритетные дела. И вот настала очередь кросскомпиляции.
В данном посте будут описаны:
- Инструменты
- Элементарная технология кросскомпиляции
- И, собственно, HOW2
Кому это интересно, прошу под кат.
Вводная
Одно из развивающихся направлений в современном 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 зачастую опускается.
- *-none-eabi — это toolchain для компиляции проекта работающего в bare metal.
- *eabi — это toolchain для компиляции проекта работающего в какой-либо ОС. В моём случае, это Linux.
- *eabihf — это почти то же самое, что и eabi, с разницей в реализации ABI вызова функций с плавающей точкой. hf — расшифровывается как hard float.
Описанное выше справедливо для gcc и сделанных на его базе toolchain’ах.
Сперва я пытался использовать 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.
Источник
Installing arm linux gcc
(1) Download arm-linux-gcc-4.4.3
Download address: http://download.csdn.net/download/cqflxyyyyyyy/3690145#comment
Upload with upload tool, pay attention to binary transmission
(2) Unzip
Unzip and generate an opt folder in the current directory
(3) New arm folder
Create a folder named arm under / usr / local /, enter the command in the terminal: cd / usr / local /, press Enter, and then enter the command: mkdir arm, Create an arm directory and modify the attribute of the folder to rwx, enter the command: chmod 777 arm
(4) Copy the content of the file to the new directory
(5) Copy the content of the file to the new directory
Modify the environment variable PATH to avoid entering the full path where arm-linux-gcc is located each time. Enter: vi / etc / profile in the terminal, open the profile file, add «export PATH = $ PATH: /usr/local/arm/4.4.3/bin» to the last line and save the file.
unset i
unset -f pathmunge
export PATH=$PATH:/usr/local/arm/4.4.3/bin
(6) To make the new environment variables take effect immediately, enter: source / etc / profile
(7) Check whether the installation is complete, enter: arm-linux-gcc -v to view the version information
If centos is a 32-bit system, the installation will be successful, and the following information will be displayed:
Using built-in specs.
Target: arm-none-linux-gnueabi
Configured with: /opt/FriendlyARM/mini2440/build-toolschain/working/src/gcc-4.4.3/configure —build=i386-build_redhat-linux-gnu —host=i386-build_redhat-linux-gnu —target=arm-none-linux-gnueabi —prefix=/opt/FriendlyARM/toolschain/4.4.3 —with-sysroot=/opt/FriendlyARM/toolschain/4.4.3/arm-none-linux-gnueabi//sys-root
—enable-languages=c,c++ —disable-multilib —with-arch=armv4t —with-cpu=arm920t —with-tune=arm920t —with-float=soft —with-pkgversion=ctng-1.6.1 —disable-sjlj-exceptions —enable-__cxa_atexit —with-gmp=/opt/FriendlyARM/toolschain/4.4.3 —with-mpfr=/opt/FriendlyARM/toolschain/4.4.3
—with-ppl=/opt/FriendlyARM/toolschain/4.4.3 —with-cloog=/opt/FriendlyARM/toolschain/4.4.3 —with-mpc=/opt/FriendlyARM/toolschain/4.4.3 —with-local-prefix=/opt/FriendlyARM/toolschain/4.4.3/arm-none-linux-gnueabi//sys-root —disable-nls —enable-threads=posix
—enable-symvers=gnu —enable-c99 —enable-long-long —enable-target-optspace
Thread model: posix
gcc version 4.4.3 (ctng-1.6.1)
If the centos system is 64-bit, it will prompt the content
/lib/ld-linux.so.2: bad ELF interpreter: No such file or directory
It means that the installation is not successful. At this time, you need to do the following:
1. Executing 32-bit program in 64 system if /lib/ld-linux.so.2:
bad ELF interpreter: No such file or directory, just install glic
input the command:
2. If error while loading shared libraries: libz.so.1:
cannot open shared object file: No such file or directory
input the command:
3. If it appears / libexec / gcc / arm-none-linux-gnueabi / 4.4.3 / cc1:
error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory
input the command:
In addition, if there is an error reporting that the shared library is missing:
error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory
Solution:
1. Enter the command:
Then it will prompt which installation package has this library file as follows:
]# yum whatprovides libstdc++.so.6
Loaded plugins: aliases, changelog, downloadonly, fastestmirror, kabi, presto, refresh-packagekit, security, tmprepo, verify,
: versionlock
Loading support for CentOS kernel ABI
Loading mirror speeds from cached hostfile
* base: centos.ustc.edu.cn
* centosplus: centos.ustc.edu.cn
* contrib: centos.ustc.edu.cn
* extras: centos.ustc.edu.cn
* updates: centos.ustc.edu.cn
libstdc++-4.4.7-3.el6.i686 : GNU Standard C++ Library
Repo : base
Matched from:
Other : libstdc++.so.6
Enter the command: # yum install
libstdc++-4.4.7-3.el6.i686
Источник
Устанавливаем пакет инструментов GNU ARM под Linux
Существует множество средств разработки для различных версий процессоров ARM, но пакет инструментов GNU ARM является, пожалуй, одним из самых популярных. Узнайте подробнее, как разрабатывать встроенное ПО для ядра ARM, а также о том, как установить и использовать для этой цели пакет инструментов GNU.
статья о sudo aptitude install binutils-arm-linux-gnu* gcc-X.Y-arm-linux-gnu* .
> статья о sudo aptitude install
arm-2008q3-72-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2
.tar.bz2
.tar.bz2
.tar.bz2
я ожидал большего
Что-то как-то ниочем. Меня и мой собственнособранный велик (arm cross-toolchain) совершенно устраивает.
это ж ibm developer labs. чего от него ожидать.
Чем оно лучше buildroot?
хочу aptitude install gcc-arm-cortexm3-none
Чем это лучше clfs, который и не только для arm?
Я как-то для шиваплага обошелся ‘crossdev -t armv5tel-softfloat-linux-gnueabi’. и тулчейн готов.
это не ужас. Это труЪ ынтерпрайз.
# cd /usr/local/bin # ln -s /home/bzimmerly/Sourcery_G++_Lite/bin/arm-none-linux-gnueabi-as as
А «дядя» уверен, что слака по такого будет нормально работать, если gcc до этого установлен в /usr/local/bin? 🙂
>В набор бинарных утилит этого пакета (binutils) входит набор компиляторов GNU (GCC)
Коряво переведено, binutils отдельно GCC отдельно. binutils — это ассемблер, компоновщик(linker) и т.д.
А зачем на ассемблере? oO
Просто интересно, кто-нибудь юзает девайс на ARM как настольную систему?
что-то странное. ну ладно, это бот же запостил
>www.emdebian.org — там всё.
У них тулчейны собраны для кодогенерации под armv4t, что для современных процов слабовато. Плюс почему-то нет gcc > 4.3
ЯЗАБАН. Это же кошмар
>Чем это лучше clfs, который и не только для arm?
Тем что тулчейн от Codesourcery(который кстати тоже не только под arm) хорошенько пропатчен и работает, в отличии от.
А я ожидал openocd и jtag.
Кроскомпилляторы имеют префикс в названии файлов.
И слака после такого работает, проверено:)
Тру энтерпрайз — это Keil и его тулзы, тогда уж.
Вообще если они так хотели версию от CodeSourcery — там же можно скачать обычный инсталлер на жабе, без всяких архивов. И PATH он сам будет подправлять
>Тру энтерпрайз — это Keil и его тулзы, тогда уж.
А он разве умеет генерировать код для arm-linux? То-то же.
Ты не поверишь, я его на посмотреть качал дня 2 назад. У них codesourcery внутрях.
>Просто интересно, кто-нибудь юзает девайс на ARM как настольную систему?
Раз лежит на столе значит настольная 🙂
Положу в карман будет карманная 🙂
Такие не в счет.
> # cd /usr/local/bin
> .
> # ln -s /home/bzimmerly/Sourcery_G++_Lite/bin/arm-none-linux-gnueabi-as as
в /usr/local/bin, без префикса архитектуры. автора уволить, статью удалить, бота забанить.
>Плюс почему-то нет gcc > 4.3
p gcc-4.4-arm-linux-gnueabi 4.4.5-10
p gcc-4.4-arm-linux-gnueabi-base 4.4.5-10
>>Тру энтерпрайз — это Keil и его тулзы, тогда уж.
нельзя о таком вспоминать на ночь глядя! >_ ★★★★★ ( 03.02.11 00:42:54 )
>Билл Циммерли, специалист в области инженерии знаний, Рязанский государственный радиотехнический университет
Живет он в деревушке Хиллсборо, Миссури, где может наслаждаться чистым воздухом и прекрасной природой.
Хотя следующее предложение многое объясняет
Кроме того, неподалеку находятся несколько винных заводов.
Мнда. А какой-т ГСМ в российском IBM поимел за это бабла. (Я не против бабла, я против того, чтобы оно платилось за высеры ГСМ.)
Чем оно лучше OpenEmbedded? Которое к слову проще этого и buildroot-а в 10 раз.
Ну конечно же, Makefile-ы это же так сложно. Лучше придумать свой формат с блэкджеком и т.д. И от 30 гигов при сборке никто совсем не сжирает.
>Чем оно лучше OpenEmbedded? Которое к слову проще этого и buildroot-а в 10 раз.
Тут речь о компиляторах, а не о приблудах для сборки системы. Так что сравнение не совсем корректное. Мне, например, для постороения системы нужно не так уж много и всё это я в состоянии собрать сам, был бы нормальный компилятор.
GNU компилятор и все приблуды собираются из нативных сырцов одним скриптом за 20 минут, нафига велосипеды плодить.
>GNU компилятор и все приблуды собираются из нативных сырцов одним скриптом за 20 минут, нафига велосипеды плодить.
Ну не у всех этот скрипт есть, а собрать вручную не так просто. Плюс GNU кросс-компилятор и приблуды под arm требуют обильного патчения. Для каждой версии gcc/binutils/libc эти патчи свои, их нужно знать где брать и т.д. И даже после этого, качество компилятора много хуже чем для x86. А ребята из codesourcery сами учавствуют в разработке arm linux abi, отправляют много патчей в ванильный gcc, так что им можно доверять. Но себе я собираю сам.
Наконец-то хоть что-то полезное от этого бота.
exception13> статья о sudo aptitude install binutils-arm-linux-gnu* gcc-X.Y-arm-linux-gnu* .
Там для слаки руководство.
Про патчи пруф можно? Почему у меня нативные сырцы собрались без бубнов и патчей и генерируют 100% работособный код без всяких багов, ЧЯДНТ?
Чтобы найти скрипт нужно пользоваться поиском, на ЛОРе этот скриптик был.
Да, пытаюсь. Буду очень признателен, если кто-нибудь поможет достать PandaBoard
С платформой повезло или копаешь не так глубоко. Armv7, например, мне кажется сейчас всяко лучше поддерживаются, чем мои xscale’ы.
Ну посмотри здесь чтоли: binutils-2.20.1 gcc-4.4.5 glibc-2.9 glibc-ports-2.9 Не всё там к армам относится, но всё таки порядочно.
Платформа AT91 все работает из коробки, хотя как автор сборки могу сказать что от arm к arm там мало что зависит (ну если только разрядность да порядок байт). Основные различия на уровне переферии вокруг армового ядра, но это камень уже в сторону ядра системы которую хотите запустить а не компилятора, последнему фиолетово под какой арм плодить код в пределах архитектуры (с точки зрения компилера архитектура это arm5tej или arm6 или что тае еще есть, armv7 это обвязка, Вы путаете божий дар с яичницей).
ЗЫ: засуньте этот crosstool-ng куда подальше и никому не показывайте (Мой опыт показывает что сие «шэдевр» нужно выкинуть), с этими патчами gcc версии больше чем 4.3 так и смог плодить работоспособный код (все плюсовое что им собиралось, особенно Qt рассыпалось по сегфолту в glibc), потому я кстати и написал скрипт который собирает все из ванильных сырцов, и все как не странно работает. А для блэкфина crosstool-ng даже компилятор собрать со своими патчами не смог, когда без них все собирается из ванилина и как не странно опять работает как часы. Так ЧЯДНТ?
>Платформа AT91
Понятно. Ты пишешь под bare metal? У меня проц помощнее и платформа и компилятор у меня для linux. А это всё очевидно сложнее устроено.
(с точки зрения компилера архитектура это arm5tej или arm6 или что тае еще есть, armv7 это обвязка, Вы путаете божий дар с яичницей).
Сходи уже хоть на википедию просвятись чтоли, сам всё напутал. ARMv7 — это версия набора инструкций, а например ARM9 — это семейство ядер, которые могут иметь архитектуру armv4 или armv5. Кстати arm5tej -такой архитектуры нету, есть armv5tej. Мой pxa270 почти такой, только без буковки j. Уж это-то я знаю 🙂
ЗЫ: засуньте этот crosstool-ng куда подальше и никому не показывайте (Мой опыт показывает что сие «шэдевр» нужно выкинуть), с этими патчами gcc версии больше чем 4.3 так и смог плодить работоспособный код (все плюсовое что им собиралось, особенно Qt рассыпалось по сегфолту в glibc),
Да я разные пробую периодически. Был и oselas и buildroot. На самом деле разницы особой нету какая система сборки, главное чтобы патчи нужные были. gcc 4.4.5 у меня работает нормально. По поводу сегфолтов — если ты про эту тему http://www.linux.org.ru/forum/development/5512123, то попробуй в конфиге ct-ng указать «CT_LIBC_GLIBC_EXTRA_CFLAGS=»-U_FORTIFY_SOURCE» и всё у тебя заработает.
и как не странно опять работает как часы. Так ЧЯДНТ?
У меня конкретно претензии к ванильному gcc: [ARM]iwmmx на gcc вообще был когда-нибудь юзабельным?. Но это касается только моего процессора. Патча никто похоже нормального не сделал. Я набросал один workaround, теперь более-менее нормально работает gcc 4.2.x, а всё что выше — дико вылетает. Прмчём даже уже другие ошибки идут, о которых багзилла тоже знает.
> GNU компилятор и все приблуды собираются из нативных сырцов одним скриптом за 20 минут, нафига велосипеды плодить.
а только до этого надо задать кучу вопросов людям о том, как это делать, вот твой http://www.linux.org.ru/forum/development/5528260
>ЗЫ: засуньте этот crosstool-ng куда подальше и никому не показывайте (Мой опыт показывает что сие «шэдевр» нужно выкинуть)
Видел я твои ламерские вопросы тут на форуме — постеснялся бы школота позориться с выводами, ты вообще какой-то придурочный похоже, неужели в дурдоме интернет появился ?
Ну это скорее ответ а не вопрос, к тому моменту я уже допер как это делается. Не боги же горшки обжигали.
Источник
