Arm linux gnueabihf gcc windows

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

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

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

1. Инструменты
2. Элементарная технология кросскомпиляции
3. И, собственно, 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.

Источник

9.2-2019.12

The GNU Toolchain for the Cortex-A Family is a ready-to-use, open source suite of tools for C, C++ and Assembly programming. This toolchain targets processors from the Arm Cortex-A family and implements the Arm A-profile architecture.

The toolchain includes the GNU Compiler (GCC) and is available free of charge directly for Windows and Linux operating systems. Follow the links on this page to download the correct version for your development environment.

See the downloaded package Release Notes, which are linked from this page, for full installation instructions.

GNU Toolchain for the A-profile Architecture

Version 9.2-2019.12

Released: December 19, 2019

What’s new in 9.2-2019.12

We are pleased to announce the Arm release of the pre-built GNU cross-toolchain for the A-profile cores: GCC 9.2-2019.12.

This is the same toolchain that was previously distributed by Linaro.

For more information about the GNU Arm toolchain and download the release packages, please go to the Arm Developer website.

In this release

Windows (mingw-w64-i686) hosted cross compilers

AArch32 bare-metal target (arm-none-eabi)

AArch32 target with hard float (arm-none-linux-gnueabihf)

AArch64 bare-metal target (aarch64-none-elf)

AArch64 GNU/Linux target (aarch64-none-linux-gnu)

x86_64 Linux hosted cross compilers

AArch32 bare-metal target (arm-none-eabi)

AArch32 target with hard float (arm-linux-none-gnueabihf)

AArch64 ELF bare-metal target (aarch64-none-elf)

AArch64 GNU/Linux target (aarch64-none-linux-gnu)

AArch64 GNU/Linux target (aarch64_be-none-linux-gnu)

AArch64 Linux hosted cross compilers

AArch32 bare-metal target (arm-none-eabi)

AArch32 target with hard float (arm-none-linux-gnueabihf)

AArch64 ELF bare-metal target (aarch64-none-elf)

Sources

Linaro ABE example manifest files for x86_64 hosted cross compilers

Release Note for GNU-A Downloads 9.2-2019.12

Description

GNU 9.2 cross-toolchain for the A-profile processors

Features

• Based on GCC 9.2 (See https://gcc.gnu.org/gcc-9/changes.html for details).
• Supported targets on Windows(x86_64): AArch64 (bare-metal and Linux), AArch32 (bare-metal, Linux hard-float)
• Supported targets on Linux(x86_64): AArch64 (bare-metal, Linux, Linux big-endian), AArch32 (bare-metal, Linux hard-float)
• Supported targets on Linux(AArch64): AArch64 (bare-metal), AArch32 (bare-metal, Linux hard-float)

Changes since Arm release GCC 8.3-2019.03

• Additional AArch64 hosted cross toolchains for AArch64 (bare-metal) and AArch32 (bare-metal, Linux hard-float)
• Additional Windows hosted cross toolchains for AArch64 (Linux) and AArch32 (Linux hard-float)
• Retired Linux(x86_64) toolchain for AArch64 (big-endian bare-metal) and AArch32 (Linux soft-float)
• Changed toolchain naming convention to match standard target triplet naming convention, with vendor name being none. For example, arm-eabi is arm-none-eabi.
• Fixed the Windows toolchain convention to correctly include mingw-w64 instead of mingw32

Content

This release includes the following items:

GCC 9.2.1	Repository: svn://gcc.gnu.org/svn/gcc/branches/ARM/arm-9-branch Revision: 277439 Sources provided in release source tar ball.
glibc 2.30	Repository: git://sourceware.org/git/glibc.git Revision: 50f20fe506abb8853641006a7b90a81af21d7b91 Release note
binutils 2.33.1	Repository: git://sourceware.org/git/binutils-gdb.git Revision: da3b036b57c0d409fc1fc3e25597fa13dc71baf5 Release note
GDB 8.3.0	Repository: git://sourceware.org/git/binutils-gdb.git Revision: e908e11a4f74ab6a06aef8c302a03b2a0dbc4d83 GDB-with-python support for Python 2.7.6 (x86_64 builds). GDB-with-python support for Python 2.7.13 (mingw-w64-i686 builds). Release note
libexpat 2.2.5	Repository: https://github.com/libexpat/libexpat.git Revision: Release note
Linux Kernel	Repository: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git Revision: v4.20.13 Release Note
libgmp 4.3.2 libisl 0.15 libmpfr 3.1.6 libmpc 1.0.3 libiconv 1.15	Sources provided in release source tar ball.

Host requirements

Description	Requirement	OS identifier in the toolchain triplet
Windows on 64-bit x86 (x86_64)	Windows 10	mingw-w64-i686
Linux on 64-bit x86(x86_64)	Ubuntu 16.04 LTS or later RHEL 7 or later	x86_64
Linux on 64-bit Arm(AArch64)	Ubuntu 18.04 LTS or later RHEL 8 or later

Known dependencies

• GDB’s Python support requires Python compiled with UCS-4 support (built with —enable-unicode=ucs4) for Linux (x86_64) and Windows hosts
• GDB’s Python support requires Python DLL dependencies for Windows host.
• Toolchains dedicated for Windows host require mingw-w64 library, a complete runtime environment for GCC.

The GNU Toolchains

Name	Host	Target
aarch64-aarch64-none-elf	AArch64 Linux	AArch64 ELF bare-metal target.
aarch64 -arm-none-eabi	AArch64 Linux	AArch32 bare-metal target.
aarch64 -arm-none-linux-gnueabihf	AArch64 Linux	AArch32 target with hard float.
mingw-w64-i686-arm-none-eabi	Windows	AArch32 bare-metal target.
mingw-w64-i686-aarch64-none-elf	Windows	AArch64 ELF bare-metal target.
mingw-w64-i686- arm-none-linux-gnueabihf	Windows	AArch32 target with hard float.
mingw-w64-i686-aarch64-none-linux-gnu	Windows	AArch64 GNU/Linux target.
x86_64-aarch64-none-elf	x86_64 Linux	AArch64 ELF bare-metal target.
x86_64-aarch64-none-linux-gnu	x86_64 Linux	AArch64 GNU/Linux target.
x86_64-aarch64_be-none-linux-gnu	x86_64 Linux	AArch64 GNU/Linux big-endian target.
x86_64-arm-none-eabi	x86_64 Linux	AArch32 bare-metal target.
x86_64-arm-none-linux-gnueabihf	x86_64 Linux	AArch32 target with hard float.

Released files

gcc-arm-*.tar.xz	Toolchain binaries
gcc-arm-src-snapshot-*.tar.xz	Toolchain sources
gcc-arm-src-snapshot-*-manifest.txt	Text manifest file with list of remote repositories for toolchain
gcc-arm-*-abe-manifest.txt	Input files for Linaro ABE build system.
*.asc	MD5 checksum files for sources and binaries

Installation instructions

Extract XZ compressed release archive using TAR archiving utility:

Compute and check MD5 checksum of XZ compressed release archives using md5sum utility:

The prebuilt binary bundles can be un-tarred and executed in place. Unpack the Linux cross toolchain:

How to build the toolchain from sources

You can build GNU cross-toolchain for the A-profile from sources using Linaro ABE (Advanced Build Environment) and provided ABE manifest files.

Below example shows how to build gcc-arm-aarch64-linux-gnu toolchain from sources using Linaro ABE build system.

Instructions

Clone ABE one of the URL below and checkout the stable branch (see Getting ABE):

Create the build directory and change to it. Any name for the directory will work (see Building Toolchains With ABE):

Configure ABE (from the build directory):

And finally build toolchain (from the build directory):

Known issues

Ask questions

For any questions, please use the Arm Communities forums.

Report bugs

Please report any bugs via the Linaro Bugzilla.

Источник

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

Среда кросс-компиляции ARM-LINUX

В связи с необходимостью разработки приложений для руки необходимо создать среду компиляции для руки. Есть два способа создать среду:

• Среда кросс-компиляции
• среда разработки руки

Среда кросс-компиляции включает следующее:

• Используйте Visual Studio для создания среды разработки под Windows
• Используйте GCC для создания среды разработки под Linux

Поскольку среда Linux более удобна в настройке, рекомендуется использовать среду Linux для разработки. Visual Studio удобнее разрабатывать, IDE лучше, но удобнее выбирать Linux + Makefile.

Построение среды Linux

Так называемая настройка среды заключается в установке ряда инструментов для компиляции и отладки.Установленный здесь инструмент — am-linux-gcc.

Объяснение названия инструментария

gcc — это инструмент компиляции для x86-64, который может компилировать наборы инструкций, такие как SSE и AVX. Целевое оборудование — это ЦП настольного уровня. А gcc-arm-linux — это программное обеспечение, которое работает на ЦП настольного уровня. Созданный исполняемый файл — это файл, который запускается на руке.

Что такое аби и эаби

• ABI: двоичный интерфейс приложения (ABI) для архитектуры ARM
  В компьютере двоичный интерфейс приложения описывает низкоуровневый интерфейс между приложением (или другими типами) и операционной системой или другими приложениями.
• ABI охватывает различные детали, например:
  • Размер, расположение и выравнивание типов данных;
  • Соглашение о вызовах (контролирует, как передаются параметры функции и как принимается возвращаемое значение), например, все параметры передаются через стек или некоторые параметры передаются через регистры; какой регистр используется для какого параметра функции; первый передается через стек Параметр функции помещается в стек первым или последним;
  • Кодирование системных вызовов и то, как приложение выполняет системные вызовы операционной системы;
  • А в полной операционной системе ABI — двоичный формат объектного файла, программной библиотеки и т. Д.

Полный ABI, такой как Intel Binary Compatibility Standard (iBCS), позволяет программам в операционных системах, которые его поддерживают, запускаться в других операционных системах, поддерживающих этот ABI, без изменений.
ABI отличается от интерфейса прикладного программирования (API), API определяет интерфейс между исходным кодом и библиотекой, поэтому один и тот же код может быть скомпилирован в любой системе, поддерживающей этот API, ABI позволяет компиляцию Хороший целевой код может работать без изменений в системе, использующей ABI-совместимую.

• EABI: встроенный ABI
  • Двоичный интерфейс встроенного приложения определяет формат файла, тип данных, использование регистров, оптимизацию организации стека и стандартные соглашения о параметрах во встроенном программном обеспечении.
  • Разработчики, использующие свой собственный язык ассемблера, также могут использовать EABI в качестве интерфейса к языку ассемблера, созданного совместимым компилятором.
  • Объектные файлы, созданные компилятором, поддерживающим EABI, могут быть совместимы с кодом, созданным аналогичными компиляторами, что позволяет разработчикам связывать библиотеки, созданные разными компиляторами.

Основное различие между EABI и ABI на компьютерах общего назначения заключается в том, что привилегированные инструкции разрешены в коде приложения, динамическое связывание не требуется (иногда запрещено), а для экономии памяти используется более компактная структура стека. EABI широко используется Power PC и ARM.

Два кросс-компилятора, связанные с gnueabi: gnueabi и gnueabihf

Определения этих двух кросс-компиляторов в исходном коде debian следующие:

• gcc-arm-linux-gnueabi – The GNU C compiler for armel architecture
• gcc-arm-linux-gnueabihf – The GNU C compiler for armhf architecture

Видно, что эти два кросс-компилятора подходят для двух разных архитектур armel и armhf. Две архитектуры armel и armhf используют разные стратегии для операций с плавающей запятой (руки с fpu могут поддерживать эти две стратегии операций с плавающей запятой)

Фактически, эти два кросс-компилятора представляют собой просто параметры gcc -mfloat-abi с разными значениями по умолчанию. Параметр gcc -mfloat-abi имеет три значения soft, softfp и hard (последние два требуют плавающей запятой fpu в руке) Операционный блок, soft и два последних совместимы, но два режима softfp и hard несовместимы друг с другом):

• soft: не используйте fpu для вычислений с плавающей запятой, даже если есть арифметический блок fpu с плавающей запятой, не используйте его, а используйте программный режим.
• softfp: значение по умолчанию, используемое архитектурой armel (соответствующий компилятор — gcc-arm-linux-gnueabi), вычисляется fpu, но параметры передаются обычными регистрами, поэтому при прерывании нужно сохранять только обычные регистры, а нагрузка прерывания мала. Но параметры нужно преобразовать в числа с плавающей запятой, а затем рассчитать.
• hard: значение по умолчанию, используемое архитектурой armhf (соответствующий компилятор gcc-arm-linux-gnueabihf), вычисляется fpu, а параметры также передаются регистром с плавающей запятой в fpu, что сохраняет преобразование. Производительность самая лучшая, но прерывание загрузки высоко.

Жесткое плавание

Компилятор непосредственно компилирует код и передает его на аппаратный сопроцессор с плавающей запятой (арифметический блок с плавающей запятой FPU) для исполнения. FPU обычно имеет набор дополнительных регистров для завершения передачи параметров с плавающей запятой и вычислений.
Использование реального аппаратного блока FPU с плавающей запятой, конечно, приведет к повышению производительности. Потому что часто для вызова функции с плавающей запятой требуется несколько или десятки тактов.

Мягкий поплавок

Компилятор преобразует операции с плавающей запятой в вызовы арифметических функций с плавающей запятой и вызовы библиотечных функций.Нет вызова инструкций FPU и передачи параметров регистра с плавающей запятой. Передача параметров с плавающей запятой также осуществляется через регистры или стеки ARM.
Текущая система Linux предпочитает использовать по умолчанию для компиляции жесткое с плавающей запятой, даже если в системе нет процессора с плавающей запятой, это приведет к возникновению недопустимых инструкций и исключений. Поэтому в общих системных образах используется мягкая плавающая точка для совместимости с процессорами без VFP.

armel ABI и armhf ABI

В armel есть три соглашения для вычислений с плавающей запятой. Взяв в качестве примера gcc, есть три соответствующих значения параметра -mfloat-abi: soft, softfp и hard.

• Soft означает, что все операции с плавающей запятой реализуются на программном уровне. Конечно, эффективность невысока. Будут ненужные преобразования из чисел с плавающей запятой в целые числа и из целых чисел в числа с плавающей запятой. Это подходит только для ранних процессоров ARM без вычислительных блоков с плавающей запятой;
• Softfp в настоящее время является настройкой armel по умолчанию. Он передает вычисления с плавающей запятой в FPU для обработки, но для передачи параметров функции используются общие целочисленные регистры вместо регистров FPU;
• Hard использует регистры с плавающей запятой FPU для передачи параметров функции в FPU для обработки.

Следует отметить, что с точки зрения совместимости soft и два последних совместимы, но два режима softfp и hard несовместимы.

• По умолчанию armel использует softfp, поэтому armel в жестком режиме используется только как abi, называемый armhf.
  В жестком режиме каждый раз при вызове функций, связанных с плавающей запятой, можно сохранить в среднем 20 циклов ЦП. Для архитектуры, которая важна для каждого цикла, такой как ARM, это улучшение, несомненно, огромно.
• В некоторых приложениях без изменения исходного кода и конфигурации использование armhf может улучшить производительность на 20-25%. Для некоторых программ, которые в значительной степени полагаются на операции с плавающей запятой, можно добиться повышения производительности на 300%.

Источник