[spongebob 0]

Всем привет!

Подскажите, пожалуйста, как понять, подходит ли компилятор для определенного процессора или нет.
Где конкретно в документации указаны процессоры, совместимость?

К примеру.
Есть gcc-linaro-7.5.0-2019.12-x86_64_arm-linux-gnueabihf для Raspberry.
Подойдет ли он для Orange?
Нужны ли какие-нибудь особые опции?

[aaarrr 63]

Подойдет для Orange, если он 32 битный. Особых опций не нужно.

[spongebob 0]

Ранее собирал этим компилятором для Малины (Raspberry Pi 3 B+) - https://www.raspberrypi.com/products/raspberry-pi-3-model-b-plus/ Она 64 бит Cortex-A53 (armv8).
Теперь нужно собирать для Апельсины (Orange Pi PC) - http://www.orangepi.org/orangepipc/ Она 32 бит Cortex-A7 (armv7).

Объясните, пожалуйста, где и что смотреть... где указаны процессоры, архитектуры и т. п. для компилятора.
Посмотрел доки на свой компилятор (опции для ARM), вроде, есть там и armv8 для Малины и armv7 для Апельсины, но не уверен... буквы там всякие еще... я не понимаю, как сопоставить поддерживаемые архитектуры (конкретные процессоры?) компилятором определенным процессорам (их архитектурам, они ведь обычно в описании для плат указываются?).
В общем, вопрос-то по сути сводится к тому, как подобрать компилятор к процессору...

Spoiler

-march=name

This specifies the name of the target ARM architecture. GCC uses this name to determine what kind of instructions it can emit when generating assembly code. This option can be used in conjunction with or instead of the -mcpu= option. Permissible names are: ‘armv2’, ‘armv2a’, ‘armv3’, ‘armv3m’, ‘armv4’, ‘armv4t’, ‘armv5’, ‘armv5e’, ‘armv5t’, ‘armv5te’, ‘armv6’, ‘armv6-m’, ‘armv6j’, ‘armv6k’, ‘armv6kz’, ‘armv6s-m’, ‘armv6t2’, ‘armv6z’, ‘armv6zk’, ‘armv7’, ‘armv7-a’, ‘armv7-m’, ‘armv7-r’, ‘armv7e-m’, ‘armv7ve’, ‘armv8-a’, ‘armv8-a+crc’, ‘armv8.1-a’, ‘armv8.1-a+crc’, ‘armv8-m.base’, ‘armv8-m.main’, ‘armv8-m.main+dsp’, ‘iwmmxt’, ‘iwmmxt2’.

Architecture revisions older than ‘armv4t’ are deprecated.

-march=armv6s-m is the ‘armv6-m’ architecture with support for the (now mandatory) SVC instruction.

-march=armv6zk is an alias for ‘armv6kz’, existing for backwards compatibility.

-march=armv7ve is the ‘armv7-a’ architecture with virtualization extensions.

-march=armv8-a+crc enables code generation for the ARMv8-A architecture together with the optional CRC32 extensions.

-march=armv8.1-a enables compiler support for the ARMv8.1-A architecture. This also enables the features provided by -march=armv8-a+crc.

-march=armv8.2-a enables compiler support for the ARMv8.2-A architecture. This also enables the features provided by -march=armv8.1-a.

-march=armv8.2-a+fp16 enables compiler support for the ARMv8.2-A architecture with the optional FP16 instructions extension. This also enables the features provided by -march=armv8.1-a and implies -mfp16-format=ieee.

-march=armv8.2-a+dotprod enables compiler support for the ARMv8.2-A architecture with the optional Dot Product instructions extension. This also enables the features provided by -march=armv8.1-a.

-march=armv8.2-a+fp16+dotprod enables compiler support for the ARMv8.2-A architecture with the optional FP16 and Dot Product instructions extension. This also enables the features provided by -march=armv8.1-a and implies -mfp16-format=ieee.

-march=native causes the compiler to auto-detect the architecture of the build computer. At present, this feature is only supported on GNU/Linux, and not all architectures are recognized. If the auto-detect is unsuccessful the option has no effect.

-mtune=name

This option specifies the name of the target ARM processor for which GCC should tune the performance of the code. For some ARM implementations better performance can be obtained by using this option. Permissible names are: ‘arm2’, ‘arm250’, ‘arm3’, ‘arm6’, ‘arm60’, ‘arm600’, ‘arm610’, ‘arm620’, ‘arm7’, ‘arm7m’, ‘arm7d’, ‘arm7dm’, ‘arm7di’, ‘arm7dmi’, ‘arm70’, ‘arm700’, ‘arm700i’, ‘arm710’, ‘arm710c’, ‘arm7100’, ‘arm720’, ‘arm7500’, ‘arm7500fe’, ‘arm7tdmi’, ‘arm7tdmi-s’, ‘arm710t’, ‘arm720t’, ‘arm740t’, ‘strongarm’, ‘strongarm110’, ‘strongarm1100’, ‘strongarm1110’, ‘arm8’, ‘arm810’, ‘arm9’, ‘arm9e’, ‘arm920’, ‘arm920t’, ‘arm922t’, ‘arm946e-s’, ‘arm966e-s’, ‘arm968e-s’, ‘arm926ej-s’, ‘arm940t’, ‘arm9tdmi’, ‘arm10tdmi’, ‘arm1020t’, ‘arm1026ej-s’, ‘arm10e’, ‘arm1020e’, ‘arm1022e’, ‘arm1136j-s’, ‘arm1136jf-s’, ‘mpcore’, ‘mpcorenovfp’, ‘arm1156t2-s’, ‘arm1156t2f-s’, ‘arm1176jz-s’, ‘arm1176jzf-s’, ‘generic-armv7-a’, ‘cortex-a5’, ‘cortex-a7’, ‘cortex-a8’, ‘cortex-a9’, ‘cortex-a12’, ‘cortex-a15’, ‘cortex-a17’, ‘cortex-a32’, ‘cortex-a35’, ‘cortex-a53’, ‘cortex-a57’, ‘cortex-a72’, ‘cortex-a73’, ‘cortex-r4’, ‘cortex-r4f’, ‘cortex-r5’, ‘cortex-r7’, ‘cortex-r8’, ‘cortex-m33’, ‘cortex-m23’, ‘cortex-m7’, ‘cortex-m4’, ‘cortex-m3’, ‘cortex-m1’, ‘cortex-m0’, ‘cortex-m0plus’, ‘cortex-m1.small-multiply’, ‘cortex-m0.small-multiply’, ‘cortex-m0plus.small-multiply’, ‘exynos-m1’, ‘marvell-pj4’, ‘xscale’, ‘iwmmxt’, ‘iwmmxt2’, ‘ep9312’, ‘fa526’, ‘fa626’, ‘fa606te’, ‘fa626te’, ‘fmp626’, ‘fa726te’, ‘xgene1’.

Additionally, this option can specify that GCC should tune the performance of the code for a big.LITTLE system. Permissible names are: ‘cortex-a15.cortex-a7’, ‘cortex-a17.cortex-a7’, ‘cortex-a57.cortex-a53’, ‘cortex-a72.cortex-a53’, ‘cortex-a72.cortex-a35’, ‘cortex-a73.cortex-a53’.

-mtune=generic-arch specifies that GCC should tune the performance for a blend of processors within architecture arch. The aim is to generate code that run well on the current most popular processors, balancing between optimizations that benefit some CPUs in the range, and avoiding performance pitfalls of other CPUs. The effects of this option may change in future GCC versions as CPU models come and go.

-mtune=native causes the compiler to auto-detect the CPU of the build computer. At present, this feature is only supported on GNU/Linux, and not all architectures are recognized. If the auto-detect is unsuccessful the option has no effect.

-mcpu=name

This specifies the name of the target ARM processor. GCC uses this name to derive the name of the target ARM architecture (as if specified by -march) and the ARM processor type for which to tune for performance (as if specified by -mtune). Where this option is used in conjunction with -march or -mtune, those options take precedence over the appropriate part of this option.

Permissible names for this option are the same as those for -mtune.

-mcpu=generic-arch is also permissible, and is equivalent to -march=arch -mtune=generic-arch. See -mtune for more information.

-mcpu=native causes the compiler to auto-detect the CPU of the build computer. At present, this feature is only supported on GNU/Linux, and not all architectures are recognized. If the auto-detect is unsuccessful the option has no effect.

 

[Eddy_Em 1]

Что значит "подойдет ли"? Ты просто ставишь gcc из репозитория - и всë!

Если же нужно собрать систему из виртуалки, подними в qemu'вском чруте систему, там и собирай. Если нужна  инструкция, могу скинуть ссылку (но это элементарно гуглится). Я себе генту для одноплатников так и собирал: на самом одноплатнике это будет длиться вечность, поэтому просто на нормальном серваке в 64 потока собирал под эмулятором. А после всего записал готовый образ на флешку и воткнул в одноплатник — вуаля!

[spongebob 0]

1 hour ago, Eddy_Em said:

Что значит "подойдет ли"? Ты просто ставишь gcc из репозитория - и всë!

Если же нужно собрать систему из виртуалки, подними в qemu'вском чруте систему, там и собирай. Если нужна  инструкция, могу скинуть ссылку (но это элементарно гуглится). Я себе генту для одноплатников так и собирал: на самом одноплатнике это будет длиться вечность, поэтому просто на нормальном серваке в 64 потока собирал под эмулятором. А после всего записал готовый образ на флешку и воткнул в одноплатник — вуаля!

Забыл уточнить, нужен именно кросс-компилятор. Т. е., нужно собирать на простой рабочей машине, под Линухом. Собираю для Малины и нужно теперь собирать для Апельсины.

[Eddy_Em 1]

Честно говоря, я не понимаю, зачем это делать: почему не собрать прямо на одноплатнике? Все равно ведь исходный код распространяется по GPLv3…

[spongebob 0]

49 minutes ago, Eddy_Em said:

Честно говоря, я не понимаю, зачем это делать: почему не собрать прямо на одноплатнике? Все равно ведь исходный код распространяется по GPLv3…

Неудобно на одоплатнике, IDE на рабочем компе, бинари копирую.

[Eddy_Em 1]

Достаточно монтировать по sshfs директорию с исходниками и запускать спокойно IDE. А вот чтобы ускорить время тестовых сборок, действительно, можно делать их на ПК, но для этого придется не только поставить нужный arm-gcc, но еще и все используемые библиотеки собрать. А если зависимостей много, то проще будет сразу систему в qemu-чруте запускать, в ней и делать тестовые сборки и отладку. А как ошибок нет - уже перебрасывать на одноплатник.

[VladimirG 0]

set(TARGET_ROOT /mnt/Data/cross_rootfs/orange_pc_plus_armb)
set(TOOLCHAIN_ROOT /opt/toolchains/gcc-linaro-7.5.0-arm-linux)

set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_CROSSCOMPILING true)
set(CMAKE_SYSTEM_PROCESSOR arm)

set(CMAKE_STAGING_PREFIX ${CMAKE_SOURCE_DIR}/bin/arm_armbian/)

SET(CMAKE_C_COMPILER
        ${TOOLCHAIN_ROOT}/bin/arm-linux-gnueabihf-gcc
        )
SET(CMAKE_CXX_COMPILER
        ${TOOLCHAIN_ROOT}/bin/arm-linux-gnueabihf-c++
        )

link_directories([BEFORE] ${TARGET_ROOT}/lib/ )
SET(CMAKE_EXE_LINKER_FLAGS "-Wl,-rpath-link=${TOOLCHAIN_ROOT}/arm-linux-gnueabihf/libc/lib\
:${TARGET_ROOT}/lib/")



SET(CMAKE_FIND_ROOT_PATH ${TARGET_ROOT}/)
SET(CMAKE_SYSROOT ${TARGET_ROOT})

set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)

-DCMAKE_TOOLCHAIN_FILE=arm_pipc_armbian/CMakeLists.txt

/mnt/Data/cross_rootfs/orange_pc_plus_armb содержимое рута таргета

 

[spongebob 0]

Я собрал на рабочем компе сначала тестовую программу, залил на Апельсину, проверил. Работает.
Потом основную софтину залил - тоже работает.
Получается, что на Апельсине работает то, что я собрал для Малины...
Объясните, пожалуйста, почему?
Разные процессоры, разные архитектуры, никаких платформозависимых ключей при сборке не было...

[aaarrr 63]

27 minutes ago, spongebob said:

Объясните, пожалуйста, почему?

Потому что собрали для armhf. aarch64 имеет обратную совместимость с ним.

[spongebob 0]

1 hour ago, aaarrr said:

Потому что собрали для armhf. aarch64 имеет обратную совместимость с ним.

Если не сложно, объясните, пожалуйста, подробнее... путаюсь я в этих архитектурах и совместимостях...

Я вот к AVRам привык, там понятнее :)

Изменено 13 мая, 2022 пользователем spongebob

[Obam 30]

Честно говоря, я не понимаю, зачем это делать: почему не собрать прямо на одноплатнике? Все равно ведь исходный код распространяется по GPLv3…

"Малина" в некоторых ситуациях не совсем компьютер (в смысле, не настоящий): сборка (make) питона 3.9 с задействованием всех 4-ёх ядер (ну да, пожадничал) "уложила ягодку" напрочь - комп не может не откликаться на действия пользователя. На 3-ёх ядрах нормально; если без ошибок, то даже можно и подождать (один раз ;-) ).

Если не сложно, объясните, пожалуйста, подробнее... путаюсь я в этих архитектурах и совместимостях...Я вот к AVRам привык, там понятнее :)

Ядро "Малины" -3, -4 - CA53 64-битное, архитектура aarch64, но может исполнять и 32-битный код от архитектуры armhf (hard float), ядро CA8 (?) (была у "Малины" -1, -2): снизу вверх совместимость.

PS: чай, xmega позаковыристее classic будет ;-)