Aarch64 что это

Портирование ОС на Aarch64

Aarch64 — это 64-битная архитектура от ARM (иногда её называют arm64). В этой статье я расскажу, чем она отличается от «обычных» (32-битных) ARM и насколько сложно портировать на него свою систему.

Эта статья — не детальный гайд, скорее обзор тех модулей системы, которые придётся переделать, и насколько сильно архитектура в целом отличается от обычных 32-битных ARM-ов; всё это по моему личному опыту портирования Embox на эту архитектуру. Для непосредственного портирования конкретной системы так или иначе придётся разбираться с документацией, в конце статьи я оставил ссылки на некоторые документы, которые могут оказаться полезны.

На самом деле, различий больше, чем сходств, и Aarch64 — это скорее новая архитектура, чем 64-битное расширение привычных ARM. Предшественником Aarch64 во многом является Aarch32 (это расширение обычного 32-битного ARM), но так как у меня не было опыта работы с ним, писать о нём я и не буду 🙂

Далее в статье, если я пишу о «старом» или «прежнем» ARM, я имею ввиду 32-битный ARM (с набором команд ARM).

Кратко пройдусь по списку изменений по сравнению с 32-битным ARM, а затем разберу их поподробнее.

Регистры общего назначения стали в 2 раза шире (теперь они по 64 бита), и количество их удвоилось (т.е. теперь их не 16, а 32).
Отказ от концепции сопроцессорных регистров, теперь к ним можно обращаться просто по имени, например msr vbar_el1, x0 (против прежнего mcr p15, 0, %0, c1, c1, 2 )
Новая модель MMU (со старой никак не связана, придётся писать заново).
Раньше было два уровня привилегий: пользовательский (соответствует режиму процессора USR) и системный (соответствует режимам SYS, IRQ, FIQ, ABT, . ), теперь всё одновременно проще и сложнее — режима теперь 4.
AdvSIMD пришёл на смену NEON, операции с плавающей точкой делаются через него же.

Теперь подробнее по пунктам.

Регистры и набор команд

Регистры общего назначения — r0-r30, при этом обращаться можно к ним как к 64-битным (x0-x30) или как к 32-битным (w0-w30, доступ к младшим 32 битам).

Набор инструкций для Aarch64 называется A64. Ознакомиться с описанием инструкций можно тут. Базовые арифметические и некоторые другие команды на языке ассемблера остались прежними:

 mov w0, w1 /* Записать значение регистра w1 в w0 */ add x0, x1, 13 /* Записать в x0 сумму x1 и числа 13 */ b label /* "Прыгнуть" на метку "label" bl label /* "Прыгнуть" на метку "label", запомнив адрес возврата в x30 */ ldr x3, [x1, 0] /* Записать в x3 значение, на которое указывает x1 */ str x3, [x0, 0] /* Записать значение x3 по адресу, который лежит в x0 */

Теперь немного о различиях:

Появился специальный «zero»-регистр rzr/xzr/wzr , который равен нулю при чтении (можно применять запись в регистр, но результат вычисления не будет никуда записан).

subs xzr, x1, x2 /* Вычесть x1 и x2 и обновить флаги NZCV, сам результат вычитания никуда не записывается */

Нельзя складывать в стэк сразу много регистров ( stmfd sp!, ), придётся делать это парами:

 stp x0, x1, [sp, 16]! stp x2, x3, [sp, 16]!

Регистр PC (Program counter, указатель на текущую выполняемую инструкцию) теперь не регистр общего назначения (раньше это был R15), следовательно, к нему нельзя обращаться обычными командами ( mov , ldr ), только через ret , bl и так далее.
Состояние программы теперь отображает не CPSR (этого регистра попросту нет), а регистры DAIF (содержит маску IRQ, FIQ и т.д., AIF — те самые биты A, I, F из CPSR), NZCV (биты negative, zero, carry, oVerflow — внезапно, те самые NZCV из CPSR) и System Control Register (SCTLR, для включения кэширования, MMU, endianness и так далее).

Вроде бы, этих команд достаточно, чтобы написать простенький загрузчик, который сможет передать управление в платформо-независимый код 🙂

Режимы исполнения и переключение между ними

Про режимы исполнения хорошо написано в Fundamentals of ARMv8-A, я здесь кратко перескажу суть этого документа.

В Aarch64 есть 4 уровня привилегий (Execution level, дальше сокращённо EL).

EL3 — Secure Monitor (предполагается, что на этом уровне исполняется прошивка)
EL2 — Гипервизор
EL1 — ОС
EL0 — Приложения

На 64-битной ОС можно выполнять и 32-битные, и 64-битные приложения; на 32-битной ОС можно выполнять только 32-битные приложения.

Переходы между EL совершаются либо при помощи исключений (системные вызовы, прерывания, ошибка доступа к памяти), либо при помощи команды возврата из исключения ( eret ).

Каждый EL имеет свои регистры SPSR, ELR, SP (т.е. это «banked registers»).

Многие системные регистры также разделены по EL — например, регистр контекста MMU ttbr0 — есть ttbr0_el2 , ttbr0_el1 , и на соответствующем EL нужно осуществлять доступ к своему регистру. Это же относится к регистрам состояния программы — DAIF, NZCV, SCTLR, SPSR, ELR.

MMU

Armv8-A поддерживает MMU ARMv8.2 LPA, подробнее про это можно почитать в главе D5 ARM Architecture Reference Manual для Armv8, Armv8-A.

Если говорить коротко, то этот MMU поддерживает страницы по 4KiB (4 уровня таблиц виртуальной памяти), 16KiB (4 уровня) и 64KiB (3 уровня). На любом из промежуточных уровней можно задать блок памяти, таким образом указывая не на следующий уровень таблицы, а на целый кусок памяти такого размера, какой должна «покрывать» таблица следующего уровня. У меня есть давнишняя статья про виртуальную память, там можно почитать про таблицы, уровни трансляции и вот это всё.

Из небольших изменений — от доменов (domain) отказались, зато добавили флажки вроде dirty bit.

В целом, кроме «блоков» вместо промежуточных таблиц трансляции, особых концептуальных изменений не замечено, MMU как MMU.

Advanced SIMD

Есть существенные AdvSIMD отличия у старого NEON, как при работе с плавающей точкой, так и с векторными операциями (SIMD). Например, если раньше D0 состоял из S0 и S1, а Q0 — из D0 и D1, то теперь это не так: Q0 соответствует D0 и S0, для Q1 — D1 и S1 и так далее. При этом поддержка VFP/SIMD обязательна, по соглашению о вызовах теперь нет никакой программной передачи параметров (то, что раньше называлось «soft float ABI», в GCC — флаг -mfloat-abi=softfp ), так что придётся реализовывать аппаратную поддержку плавающей точки.

Было 16 регистров по 128 бит:

Стало 32 регистра по 128 бит:

Подробнее про NEON можно почитать в этой статье, перечень доступных команд для Aarch64 можно найти тут.

Базовые операции с регистрами с плавающей точкой:

 fadd s0, s1, s2 /* s0 = s1 + s2 */ fmul d0, d1, d2 /* d0 = d1 * d2 */

Базовые операции SIMD:

 /* Для примера, было: NEON, постфикс у команды */ /* q0 = q1 + q2, каждый регистр -- вектор из 4 чисел с плавающей точкой */ vadd.s32 q0, q1, q2 /* Стало: AdvSIMD, постфиксы у регистров */ /* v0 = v1 + v2, каждый регистр -- вектор из 4 чисел с плавающей точкой */ add v0.4s, v1.4s, v2.4s /* Сложить вектор v1 (в нём 2 64-битных числа) и записать в d1 */ addv d1, v1.ds /* Записать в каждый из 4 элементов вектора 0 */ movi v1.4s, 0x0

Платформы

QEMU

В QEMU есть поддержка Aarch64. Одна из платформ — virt , для того, чтобы она запускалась в 64-битном режиме, нужно дополнительно передать флаг -cpu cortex-a53 , примерно так:

qemu-system-aarch64 -M virt -cpu cortex-a53 -kernel ./embox -m 1024 -nographic # ./embox -- ELF-образ ядра

Что приятно, для этой платформы используется куча периферии, драйвера для которой уже были в Embox — например PL011 для консоли, ARM Generic Interrupt Controller и т. д. Само собой, у этих устройств другие базовые адреса регистров и другие номера прерываний, но главное — код драйверов без изменений работает на новой архитектуре. При старте системы управление находится в EL1.

i.MX8

Из-за этой железки и было затеяно портирование на Aarch64 — i.MX8MQ Nitrogen8M.

В отличие от QEMU, u-boot передаёт управление образу в EL2, и, более того, зачем-то включает MMU (вся память мэпируется 1 к 1), что создаёт некоторые дополнительные проблемы при инициализации.

Embox уже поддерживал i.MX6, и, что хорошо, в i.MX8 часть периферии та же самая — например, UART и Ethernet, которые также заработали (пришлось подправить пару мест, где была жёсткая привязка к 32-битным адресам). С другой стороны, контроллер прерываний там другой — ARM GICv3, который достаточно сильно отличается от первой версии.

Заключение

На данный момент поддержка Aarch64 в Embox не полная, но минимальный функционал уже есть — прерывания, MMU, ввод-вывод через UART. Многое ещё предстоит доработать, но первые шаги было сделать проще, чем казалось с самого начала. Документации и статей заметно меньше, чем по ARM, но информации больше, чем достаточно, чтобы со всем разобраться.

В целом, если у вас есть опыт работы с ARM, портирование на Aarch64 — посильная задача. Хотя, как обычно, можно споткнуться на какой-нибудь мелочи 🙂

Скачать проект, чтобы потыркать его в QEMU, можно из нашего репозитория, если есть какие-то вопросы — пишите в комментах, или в рассылку, или в чат в Телеграме (есть ещё канал).

Полезные ссылки

Инструкции A64
Fundamentals of ARMv8-A
ARM Architecture Reference Manual для Armv8, Armv8-A
Aarch64 ABI (соглашение о вызовах)
Migrating code from ARM to ARM64 — небольшая презентация с рекомендациями по написанию портируемого кода

P.S.

24-25 августа мы будем выступать на TechTrain, слушайте наши выступления раз два три, приходите к стенду — ответим на ваши вопросы 🙂

Architectures/ARM/AArch64/ru

Процессоры АРМ успешно находят применение в различных встраиваемых решениях, сотовые телефоны и планшетные устройства, но до не давнего времени архитектура ARM была только 32-х битная адресация физической памяти. Большим толчком в развитии стало выходом на рынок серверных систем (Hyperscale) (а также использование в более мощных традиционных встраиваемых решениях), 32-х битная архитектура ARM получила поддержку 40-битной адресации физической памяти в процессоре Cortex-A15. Это было большим шагом, и несколько производителей стали успешно отгружать 32-битные ARM серверные платформы основанных на LPAE (Large Physical Address Extension),40-битной технологии реализованной на Cortex-A15, старшие модели процессоров Cortex-A9, также использующие нестандартное исполнение работали только на 32-битной архитектуре.

Более мощным толчком, для перехода в категорию решений Enterprise, будет 64-битная архитектура. Это произойдёт с внедрением нового AArch64, исполнения 8 версии архитектуры ARM. AArch64 это не просто продолжение 32-битной архитектуры, это скорее новая архитектура внутри ARMv8, полностью законченная с новым набором команд A64. Это результат многих лет исследований в разработке современных архитектур. Важно, AArch64 является отдельным исполнением, это значит что, некоторые выпущенные в будущем процессоры возможно не будут поддерживать старшие исполнения AArch32. Хотя внутренне, 64-битные процессоры ARM будут полностью обратно совместимы, и это смелый и перспективный шаг в отношении AArch64, которая будет только в процессорах версии ARMv8. 32-х битные системы больше не будут поддерживаться. Это позволит реализовать множество полезных компромиссных решений, таких как использование по умолчанию более крупных размеров страниц в 64K и как результат чистая 64-битная серверная архитектура ARM, свободная от наследования кода. Это очень важно

It is important to make this distinction immediately such that there is an opportunity for 64-bit only server systems to emerge within the next few years. Not having to implement a full 32-bit pipeline in addition to the newer 64-bit architecture will increase energy efficiency in future ARM server systems. Think of AArch64 as part of a natural progression of supported ARM Architectures in the Fedora ARM project: armv5tel, armv7hl, aarch64. The new architecture is named aarch64 consistent with ARM’s own choice of upstream naming, and in respect of ARM’s desires to separate the ARM trademark from the architecture name.

Более подробную информацию о | Архитектуре ARMv8 можно на сайте ARM.

Эта статья описывает инициативу переноса поддержки Fedora в состояние выполнения AArch64 на ARMv8 архитектурах, начиная с процесса загрузки Fedora 17. Будущие релизы Fedora будут поддерживать обе ARM-реализации 64-битных процессорных ядер, в частности как новые Cortex-A57, так другие модели 64-битных процессоров сторонних производителей, на подобии Applied Micro. Демонстрация первоначальной загрузки на последних уже прошла, и ожидается, что будет доступна уже в 2013 году. Основной целью является загрузка Fedora 19 remix на настоящем чипе ARMv8, и соответственно более совместимым релизом Fedora 20. Как только будет возможность приобрести производственные серверы для PHX, то будет создана новая сборачная система на ARMv8 в Фениксе. До тех пор, Red Hat будет предоставлять свои внутренние ресурсы для сборки по мере загруженности. In the initial bootstrap, the software Foundation Models are used, as described below. We will also collaborate with both Linaro and the Linaro Enterprise Group, as part of a broader Linux community effort to support the new 64-bit architecture.

Bootstrap Process

Essentially, AArch64 bootstrap is following the same process as that used for Fedora 15 on ARM: ARM HardFP Bootstrap. The older F15 process was intentionally designed with AArch64 bootstrap in mind, and so this similarity is also intended.

The purpose of the effort is to enable Fedora on ARMv8, using the standard 64-bit ABI as defined by ARM. The good news is that unlike ARMv7 and earlier, there is only one ABI (see AAPCS for 64-bit).

Everything Is Saved In One Place
Please note that all of the files and repositories for the ARMv8 bootstrap work are stored at http://fedorapeople.org/groups/armv8. Contact the maintainer Al Stone if you need to have write access.

Goals

Our goals are to complete the bootstrap «stages» (1,2,3,4,5,6) at which we anticipate certain levels of functionality from the root filesystem, beginning with very basic cross compilation, proceeding to native builds, and ultimately to a working mock and Koji configuration able to build production packages.

CURRENT STAGE: We have completed stages 1-3, and are progressing through stage4.

Bootstrap Tools

Again capitalizing on the HardFP port work previously done, we re-used and modified as necessary several scripts written earlier by DJ Delorie. These scripts are stored in a git repository and can be retrieved as follows:

$ git clone http://fedorapeople.org/groups/armv8/bootstrap.git

Patches are of course welcome.

Short term git problem
If the URI above does not work, please try:

$ git clone git://fedorapeople.org/~ahs3/bootstrap.git

Stage 1 — make

Status: mostly complete

Stage 1 was an initial bootstrap using cross compilation from source (not from SRPMs) on x86_64 hosts, for a minimal set of aarch64 packages. The goal was to create a minimal chroot environment which was sufficient for building the more complex packages of stage2. This implies providing native versions of GCC, binutils, glibc, plus some basic tools such as gzip, patch and awk, along with a few others. Stage1 results include these tools and a BusyBox environment (in lieu of requiring the use of a chroot, which is another possibility, using the OpenEmbedded Linaro images and running the rootfs within those, for example) that provides most of the normal and expected Linux commands. It does not include packages beyond the very minimal set required to get to a native building stage (still without RPM).

If you have access to cross-compilers for ARMv8 in your PATH, and those cross-compilers are named aarch64-redhat-linux-gnu-*, you should be able to recreate all of stage1 with the following:

$ git clone http://fedorapeople.org/groups/armv8/bootstrap.git $ cd bootstrap $ mkdir f17-local $ scp username@fedorapeople.org:/project/armv8/SRPMs/f17/changed/* f17-local $ ln -s f17-local SRPMlocal $ mkdir f17-sources $ scp username@fedorapeople.org:/project/armv8/SRPMs/f17/unchanged/* f17-sources $ ln -s f17-sources SRPMs $ ./stage1

If you do not have cross-compilers with names of the form given above, you will need to edit the stage1 script to point at the right places.

Stage1 Notes
Task list:
- [ahs3] Package and make available the Linaro aarch64 cross-toolchain [INPROGRESS]
- Kernel needs to be brought up to date — either upstream 3.7 with patches, Linaro AArch64, or something similar [TODO]
- Binutils has had several aarch64 patches added in the last few weeks [TODO]
- GCC patches should be re-examined for possible updates [TODO]
- Glibc patches probably need to be updated to latest upstream [TODO]
- Investigate and resolve additional rpath info needed for cloog. Why? [TODO]
- Investigate and resolve additional rpath info needed for libselinux. Why? [TODO]
- Investigate and resolve additional rpath info needed for sed. Why? [TODO]
- [ahs3] Make sure any changes made go back into upstream, where appropriate [INPROGRESS]
- [jcm, ahs3] Resolve cross-distribution compatibility issues, switch fully to /lib64; now rebuilding with updated toolchain [DONE]
- [jcm] Resolve issues with architecture features in binutils/toolchain
Stage 2 — rpmbuild

Status: DONE

Stage 2 has the goal of getting a working native build of RPM (rpmbuild) running within the rootfs. This includes enough packages built from source (not from SRPMs, but on the target) to get a working «rpmbuild» binary sufficient to rebuild RPM and other packages. The output from this is the ability to build native RPM packages.
- Stage2 Notes
- How To Use the ARM Foundation Model — instructions for using what is currently the only publicly available platform simulator for ARMv8 with the rootfs built in stage1 (which is how one builds stage2 results)
- Task list (these all need to be built in dependency order):
  - [ahs3] publish patchify scripts [DONE] — see git://fedorapeople.org/~ahs3/patchify.git
  - [ahs3] Gdb FTBFS — newer upstream patches available? NB: latest rebuild worked fine for no obvious reason [DONE]
  - [ahs3] Upstream patches? Perl, nspr, to date [INPROGRESS]
  - [ahs3] Gettext FTBFS [DONE]
  - [ahs3] Build chkconfig [DONE]
  - [ahs3] Build sqlite [DONE]
  - [ahs3] Build pth [DONE]
  - [ahs3] Build openssl [DONE]
  - [ahs3] Build popt [DONE]
  - [ahs3] Build libffi [DONE]
  - [ahs3] Build pkgconfig [DONE]
  - [ahs3] Build glib2 [DONE]
  - [ahs3] Build nss-util [DONE]
  - [ahs3] Build nss-softokn [DONE]
  - [ahs3] Build nss [DONE]
  - [msalter] Build elfutils [DONE]
  - [msalter] Build rsync [DONE]
  - [msalter] Build fakechroot [DONE]
  - [msalter] Build file [DONE]
  - [msalter] Build ustr [DONE]
  - [msalter] Build libusb1 [DONE]
  - [msalter] Build libusb [DONE]
  - [msalter] Build tzdata [DONE]
  - [msalter] Build redhat-rpm-config DONE]
  - [msalter] Build rpm [DONE]
  - [msalter] Build cracklib [DONE]
  - [msalter] Build libsepol [DONE]
  - [msalter] Build attr [DONE]
  - [msalter] Build acl [DONE]
  - [msalter] Build libsemanage [DONE]
  - [msalter] Build pam [DONE]
  - [msalter] Build shadow-utils [DONE]
  - [msalter] Build strace [DONE]
  - [msalter] Build filesystem [DONE]
  - [msalter] Build iso-codes [DONE]
  Stage 3 — mock
  
  Status: Done. Not all packages built but close enough to start building with mock.
  
  Stage 3 is the effort to get a minimal set of useful buildroot RPMs sufficient to rebuild the buildroot and have a working yum, mock configuration. RPMs will be manually built with rpmbuild and uploaded to a shared central rootfs repository.
  
  At stage3, it may be necessary to intentionally disable certain unnecessary features of RPMs, and GNU autotools (and so on) will automatically exclude certain features dependent on non-present functionality. Consequently, these RPMs will not be final and must be rebuilt in the following stages.
  
  Stage3 rootfs currently contains dependencies needed to run mock. Current effort is focused on adding packages needed in the mock chroot. Complicating this is a desire to update to glibc 2.17 and gcc 4.8 which are the first upstream releases with AArch64 support. See glibc notes in Stage3 Notes for details. Because of switch to glibc 2.17, all previously built stage3 packages need to be rebuilt. Also, packages built without rpmbuild will need to be rebuilt as RPMs so they can be part of the stage4 repo used by mock. In parallel with building packages needed for base mock chroot, some packages are being built in an effort to be able to build documentation. This generally needs a number of X packages, etc. These packages are not strictly necessary but will allow more packages to be built without patches to avoid docs.
  
  The current rootfs still uses busybox for /sbin/init and is a general mess because of the nature of the bootstrap. Packages have been installed with —nodeps and —force and in non-standard order. The rootfs does include a build of systemd but /sbin/init is still linked to busybox. Using the systemd /sbin/init does boot to a login prompt but the login fails for some reason. This could be something simple or something more complicated due to missing packages or other issues with the rootfs. It may not be worth fixing in the current rootfs because we have, or almost have, enough packages to replace the current root with one created by a yum install of aarch64 RPMs.
  - List of desired packages:
    - [msalter] kernel-headers [DONE]
    - [msalter] glibc-2.17 [DONE]
    - [msalter] gcc-4.8 [DONE]
    - [msalter] filesystem [DONE]
    - [msalter] bzip2 [DONE]
    - [msalter] coreutils [DONE]
    - [msalter] bash [DONE]
    - [msalter] cpio [DONE]
    - [msalter] swig [DONE]
    - [msalter] libcap-ng [DONE]
    - [msalter] audit [DONE]
    - [msalter] shadow-utils [DONE]
    - [msalter] diffutil [DONE]
    - [msalter] dbus [DONE]
    - [msalter] libxslt [DONE]
    - [msalter] libutempter [DONE]
    - [msalter] util-linux [DONE]
    - [msalter] opensp [DONE]
    - [msalter] openjade [DONE]
    - [msalter] glib2 [DONE]
    - [msalter] ncurses [DONE]
    - [msalter] acl [DONE]
    - [msalter] attr [DONE]
    - [msalter] byacc [DONE]
    - [msalter] bison [DONE]
    - [msalter] zlib [DONE]
    - [msalter] chrpath [DONE]
    - [msalter] check [DONE]
    - [msalter] cracklib [DONE]
    - [msalter] curl [DONE]
    - [msalter] deltarpm [DONE]
    - [msalter] e2fsprogs [DONE]
    - [msalter] binutils [DONE]
    - [msalter] elfutils [DONE]
    - [msalter] expat [DONE]
    - [msalter] fipscheck [DONE]
    - [msalter] gawk [DONE]
    - [msalter] procps-ng [DONE]
    - [msalter] make [DONE]
    - [msalter] libICE [DONE]
    - [msalter] libSM [DONE]
    - [msalter] libXau [DONE]
    - [msalter] gettext [DONE]
    - [msalter] gnupg2 [DONE]
    - [msalter] libxcb [DONE]
    - [msalter] libXdmcp [DONE]
    - [msalter] gpgme [DONE]
    - [msalter] texinfo [DONE]
    - [msalter] keyutils [DONE]
    - [msalter] libX11 [DONE]
    - [msalter] freetype [DONE]
    - [msalter] libXt [DONE]
    - [msalter] krb5 with ldap [DONE]
    - [msalter] libarchive [DONE]
    - [msalter] libassuan [DONE]
    - [msalter] libcap [DONE]
    - [msalter] libcroco [DONE]
    - [msalter] fontconfig [DONE]
    - [msalter] libXrender [DONE]
    - [msalter] libXft [DONE]
    - [msalter] libXext [DONE]
    - [msalter] libXfixes [DONE]
    - [msalter] libXdamage [DONE]
    - [msalter] libdb [DONE]
    - [msalter] libXmu [DONE]
    - [msalter] libgcrypt [DONE]
    - [msalter] libgpg-error [DONE]
    - [msalter] tk [DONE]
    - [msalter] libksba [DONE]
    - [msalter] gdbm [DONE]
    - [msalter] libpng [DONE]
    - [msalter] libsepol [DONE]
    - [msalter] readline [DONE]
    - [msalter] libtool [DONE]
    - [msalter] libffi [DONE]
    - [msalter] libunistring [DONE]
    - [msalter] libuser [DONE]
    - [msalter] libxml2 [DONE]
    - [msalter] lua [DONE]
    - [msalter] lzo [DONE]
    - [msalter] m4 [DONE]
    - [msalter] nss-util [DONE]
    - [msalter] nss-softokn [DONE]
    - [msalter] ruby [DONE]
    - [msalter] nss [DONE]
    - [msalter] libselinux [DONE]
    - [msalter] popt [DONE]
    - [msalter] qrencode [DONE]
    - [msalter] pciutils [DONE]
    - [msalter] pth [DONE]
    - [msalter] usbutils [DONE]
    - [msalter] sed [DONE]
    - [msalter] gperf [DONE]
    - [msalter] sharutils [DONE]
    - [msalter] pigz [DONE]
    - [msalter] pkgconfig [DONE]
    - [msalter] systemd [DONE]
    - [msalter] pcre [DONE]
    - [msalter] libidn [DONE]
    - [msalter] imake [DONE]
    - [msalter] gc [DONE]
    - [msalter] cmake [DONE]
    - [msalter] wayland [DONE]
    - [msalter] libpciaccess [DONE]
    - [msalter] openssl [DONE]
    - [msalter] cyrus-sasl [DONE]
    - [msalter] openldap [DONE]
    - [msalter] libXpm [DONE]
    - [msalter] libjpeg-turbo [DONE]
    - [msalter] gd [DONE]
    - [msalter] xz [DONE]
    - [msalter] patch [DONE]
    - [msalter] tar [DONE]
    - which
    - [msalter] chkconfig [DONE]
    - cloog
    - [msalter] llvm [DONE]
    - [msalter] dwz [DONE]
    - [msalter] file [DONE]
    - gdb
    - [msalter] gnutls [DONE]
    - kmod
    - [msalter] libssh2 [DONE]
    - p11-kit
    - [msalter] pam [DONE]
    - [msalter] perl [DONE]
    - pinentry
    - policycoreutils
    - [msalter] python [DONE]
    - [msalter] shared-mime-info [DONE]
    - [msalter] sqlite [DONE]
    - [msalter] tcp_wrappers [DONE]
    - [msalter] ustr [DONE]
    - ? others ?
    Stage 4 — distribution bootstrap
    
    Status: In progress.
    
    At Stage 4 we will run a complete mock rebuild of the distribution, identifying and solving dependency and platform build issues. With those out of the way, we will switch over to koji while waiting for the koji and yum changes needed to correctly support the new architecture type. This stage will absolutely require the presence of real ARMv8 hardware for completion.
    
    The result of Stage 4 is threefold:
    1. The set of packages needed for running Koji
    2. A set of SRPMs which actually can build some form of F19, or sufficiently large part of it.
    3. A set of binary RPMs that can be used initially by koji while doing the first koji rebuild of the distribution
    - AArch64 Quickstart
    - Stage 4 Patched Packages
    - Stage 4 Problem Packages
    Stage 5
    
    Status: TODO
    
    Complete rebuild of the distribution using koji
    
    Объяснение терминологии Arm: Arm ARM, Armv9, ARM9, ARM64, Aarch64, A64, A78…
    
    Если вы новичок в экосистеме Arm, то считайте это кратким введением в терминологию, которую вы могли видеть раньше, но понимаете не до конца.
    
    Архитектура Arm — это семейство архитектур с набором упрощённых команд (Reduced Instruction Set Architecture, RISC) с режимами простой адресации. Обработка данных выполняется над регистровыми операндами, в противном случае используются загрузки и сохранения для перемещения данных в регистры и из них.
    
    Arm Limited — это британская компания, занимающаяся разработкой и поддержкой архитектуры Arm.
    
    ARM — это устаревшая аббревиатура Acorn RISC Machine, а позже — Advanced RISC Machines. Как мы увидим ниже, в случае развития архитектуры предыдущую терминологию иногда переименовывают.
    
    The Arm Architectural Reference Manual for A-profile architecture, также называемое Arm ARM — это главное руководство по программированию архитектуры. Если вы что-то делаете с Arm, то, вероятно, держите под рукой этот документ.
    
    Armv9 — это самое новое семейство архитектуры, в которое добавлены такие возможности, как новые масштабируемые векторные SIMD (SVE2) и матричные (SME/SME2) операции, а также функциональность трассировок.
    
    Armv9.4-A — это последний набор расширений Armv9. Эти расширения задокументированы в Arm ARM. Некоторые расширения были опциональными при их внедрении, а многие стали обязательными в дальнейших ревизиях.
    
    A в Armv9-A обозначает «Application Profile». Этот профиль поддерживает виртуальную память при помощи блоков управления памятью; скорее всего, вы обнаружите его в любых системах Arm, будь то телефон, ноутбук или сервер. Также есть профиль «R» для приложений с требованиями системы реального времени и профили «M», которые чаще всего используют в микроконтроллерах, где отсутствуют блоки управления памятью. A, R и M — это три архитектурных профиля.
    
    AArch64 — это режим исполнения, ставший одним из самых серьёзных дополнений с появления ARMv8; он добавил поддержку 64-битных регистров (31 регистр общего назначения, специализированный 64-битный указатель стека, 64-битный счётчик команд, запись в который возможна только ветвлением или исключениями, а также имеющий нулевое значение псевдорегистра) и адресации. В то же время был создан режим исполнения AArch32 для работы с 32-битной легаси-функциональностью, знакомой разработчикам по ARMv7 (15 32-битных регистров общего назначения, отсутствующий SP, PC с возможностью записи).
    
    Любопытно, что в Arm ARM не упоминается термин ARM64; похоже, его предпочитают Apple, Microsoft и Линус Торвальдс. В конечном итоге, это название логично: порт ядра Linux arm64 может исполнять код пользовательского пространства в режимах исполнения AArch64 или AArch32, хотя само ядро исключительно для AArch64).
    
    Если вы хотите узнать о стандартах вызовов (то есть о том, каким регистрам передаются аргументы), применяемых в этих системах Arm, то можете прочитать Procedure Call Standard for the Arm Architecture (AAPCS), который опубликован с другой документацией, относящейся к ABI, здесь. После этой публикации предыдущие стандарты APCS и TPCS стали устаревшими. Платформы Apple определённым образом отклоняются от Arm ABI. У Microsoft тоже есть документация (начинающаяся с удобного списка определений, похожего на мой пост) по ABI компании для Windows.
    
    A64 — это набор команд, добавленный в AArch64. На самом деле, это единственный набор команд, поддерживаемый AArch64. Хотя регистры в режиме исполнения AArch64 являются 64-битными, сами команды всё равно только 32-битные (фиксированной ширины). Теперь под A32 подразумевается старая ISA, которая тоже имела фиксированную 32-битную ширину, а под T32 подразумеваются смешанные 32-битные и 16-битные команды Thumb2. Возможно, вы знакомы с этими ISA, если работали с ARMv7 или более старыми устройствами. A64 разрывает связи с A32, это похожая, но иная ISA. Например, в A64 гораздо меньше команд с поддержкой предикации, чем в A32.
    
    Ядро часто называют A78 или более формально Cortex-A78, не стоит путать это с A64. Arm проектирует архитектуру не только Arm, но и реализаций архитектуры, которые мы называем микроархитектурами. Часто упоминаются термины Cortex или
    Neoverse, сопровождаемые числом, это спроектированные Arm микроархитектуры архитектуры Arm. Например, Cortex-A78 реализует расширения вплоть до ARMv8.3. В Википедии есть шаблон, являющийся кратким справочником по последним микроархитектурам Arm. Прежде чем подробнее говорить о микроархитектурах Arm, нужно обсудить топологии. DynamIQ (а до неё big.LITTLE) создана на основе идеи использования в многоядерных системах гетерогенных (разных) ядер вместо гомогенных (схожих) ядер. Не уверен, можно ли по-прежнему называть это симметричной многопроцессорностью. Преимущество такого дизайна заключается в хорошей гибкости в разных задачах в различное время. Когда нам нужно повысить производительность, мы хотим использовать мощные и энергозатратные процессоры out-of-order, но для снижения энергопотребления нам могут понадобиться более медленные ядра in-order (это позволит увеличить время работы от аккумулятора). Любопытно, что Intel делает нечто смутно похожее, внедрив производительные и эффективные ядра в свою микроархитектуру Alder Lake.
    
    Изучив руководства Technical Reference Manual, опубликованные Arm для различных микроархитектур, мы можем наблюдать интересную эволюцию поддержки разных режимов исполнения относительно различных уровней исключений.
    - A55: режимы исполнения AArch32 и AArch64 находятся на всех уровнях исключений (с EL0 по EL3).
    - X1: режим исполнения AArch32 находится только на уровне исключений EL0. Режим исполнения AArch64 находится на всех уровнях исключений (с EL0 по EL3)
    - X3: режим исполнения AArch64 находится на всех уровнях исключений, с EL0 по EL3. [То есть отсутствует поддержка AArch32.]
    Ниже представлены чуть более устаревшие термины. Если вы поддерживаете старые системы, они могут быть для вас релевантны.
    
    ARM9 (не путать с версией архитектуры Armv9) — это семейство ядер, часть из которых реализует ARMv4t, а некоторые ARMv5.
    
    StrongARM — это серия процессоров ARMv4, разработанная Digital Equipment Corporation; Intel приобрела эту интеллектуальную собственность в рамках судебного разбирательства и позже разработала собственную микроархитектуру ARMv5 под названием XScale. В конечном итоге Intel продала семейство SoC PXA, использовавшее XScale, компании Marvell. Можно пофантазировать, каким бы был мир, если бы Intel продолжила развивать XScale параллельно с Atom или вместо него.
    
    ARMv4t привнесла набор сжатых команд под названием Thumb. Команды имели фиксированную 16-битную ширину (тем не менее, существовали и странности, например BL и BLX на самом деле кодировались как пара 16-битных команд; реализациям необходимо было обращать внимание на правильность работы возвратов исключений на случай, если исключение происходит посередине пары).
    
    В ARMv6t2 появилась Thumb2, добавившая новые команды, в том числе команды шириной 32 бита для поддержки более широких immediate, новые суффиксы команд, чтобы различать узкие и широкие кодировки, а также Unified Assembly Language (UAL), который упростил написание ассемблерного кода, валидного на Arm или в режиме Thumb. Однако из-за этого Thumb больше не имел фиксированной ширины. Из-за внедрения режимов исполнения вместе с ARMv8 набор команд Thumb был переименован T32; когда эти команды только появились, термина T32 ещё не существовало!
    
    Возможно, вам встретится термин aarch64be, используемый в контексте тулчейнов, он относится к big-endian. Arm поддерживал big-endian и little-endian со времён ARMv4, однако большинство платформ сегодня использует Arm в конфигурации little-endian. Big-endian чаще используется в сетевых устройствах, так как сетевой порядок байтов — это BE. -mlittle-endian и -mbig-endian — это флаги компилятора, которые можно использовать для управления генерацией кода. ARMv4 и v5 поддерживают порядок байтов шины BE-32. Код, скомпонованный с флагом —be32 , создавал код и данные в формате big-endian. В ARMv6 появился новый порядок байтов шины под названием BE-8. Флаг —be8 создавал код little-endian и данные big-endian (компилятор выдавал код big-endian для релоцируемых файлов при сборке с флагом -big-endian , а затем компоновщик преобразовывал их в little endian при использовании —be8 . Это позволяло компиляторам ценой повышения сложности компоновщика не беспокоиться о переворачивающем порядок байтов коде, вне зависимости от используемого порядка байтов шины). У ARMv6 имелись оба порядка байтов шины, и BE-32, и BE-8 (более старый BE-32 стал опциональным), однако в ARMv7 поддержка BE-32 была убрана. В этом посте показано, почему BE-8 заменил BE-32; он упрощал поддержку систем с обоими форматами endian, если мы использовали команды little endian, а шина памяти при доступе изменяла порядок байтов. ELF использует идентификаторы форматов файлов elf64-littleaarch64, elf64-bigaarch64, elf32-littlearm и elf32-bigarm; однако эти идентификаторы не используются в ELF for the Arm Architecture.
    
    Итак, это был краткий глоссарий распространённых терминов, связанных с экосистемой Arm. В следующем посте мы рассмотрим такие термины, как VFP, Neon, OABI и EABI, но пока этого достаточно.
    
    Огромная благодарность моим друзьям Питеру Смиту, Кристофу Бейлсу и Марку Брауну из Arm, Арнду Бергманну из Linaro и Арду Бешовелю из Google за вычитку черновиков поста и полезные отзывы. По случайности, пока я редактировал этот пост, мой друг и коллега Фангри Сонг опередил меня, выпустив ещё один потрясающий пост, касающийся очень похожих тем.
    - arm
    - архитектура процессоров
    - isa
    - instruction set architecture
    - armv9
    - Компьютерное железо
    - Процессоры
    Aarch64 что это
    
    Russian Fedora
    
    cообщество русскоязычных участников
    международного проекта Fedora
    
    ARM64, т.е. AArch64, и непростой путь перехода ARM на новые стандарты
    
    Это архивная статья
    
    Как вы могли заметить, в RHEL 7 забросили поддержку 32-битных микропроцессоров, в т.ч. x86. К сожалению, это означает, что для 32-битных ARM RHEL 7 не будет. Конечно, неофициальные пересборки будут существовать, но официально Red Hat будет заниматься только 64-битным ARM, вся архитектура которых спроектирована с участием нашего коллеги, инженера Red Hat, участника Fedora ARM SIG Jon Masters.
    
    Коммьюнити тяжело принимало рекомендации Red Hat — ACPI, UEFI, как обязательные стандарты для ARM. Очевидные недостатки ARM-систем (не микропроцессоров, а систем, построенных на базе лицензируемых у ARM Holdings технологий) некоторыми виделись, не как недостатки, а как преимущества — свобода выбора и свобода реализации. В принципе так оно и есть, потому что любое следование стандартам и правилам, это отказ от некоторых свобод. Но понятно, что это не то, что нам, как разработчикам дистрибутива, и нашим коллегам, разработчикам и архитекторам серверных платформ, хочется. Заметьте, очень характерно то, что не существует ARM-дистрибутива — есть ARM-сборки для той машинки, для другой, для третьей, и т.п., с зачастую общим userland, но различными ядрами, и методами установки и последующей загрузки. Как курьез можно привести архитектурное решение, использованное в Raspberry Pi — в процессе загрузки используется видеопроцессор.
    
    Стандартизация ARM-систем, начавшаяся с Device Tree и unified kernel и продолжившая с UEFI, ACPI была принята разработчиками дистрибутивов как манна небесная, хотя разработчики ядра и были недовольны свалившейся на них работой и новыми проблемами.
    
    Так или иначе, вроде коммьюнити в целом успокоилось по поводу перехода на новые стандарты, как вдруг все началось снова. Мы уже говорили, что инженер Google, Olof Johansson, был недоволен ACPI-кодом, но свое недовольство он выражал в ленте Google+. Внезапно он написал в мэйллист пост, в котором предложил вообще отказаться от ACPI в ARM.
    
    Вместо него он предложил разработать тонкую прослойку перед ядром, которая бы читала ACPI-таблицы, и формировала бы на ее основе DeviceTree. Чуть позже, он предложил кое-что еще более удивительное — подождать, пока Microsoft отладит и допишет стандарт на ACPI для ARM.
    
    У многих в этот момент, при словах «Майкрософт разработает стандарт», проснулись болезненные воспоминания — Russell King и Mark Rutland почти одновременно высказались о том, что было б очень наивно ожидать, что Microsoft разработает хороший открытый стандарт, который потом можно будет беспроблемно реализовать в открытом ПО. Russel высказался еще об одном моменте — сейчас Linux доминирует в ARM-мире, и отдавать это преимущество просто потому что кто-то из разработчиков Google не хочет следовать стандарту, стратегически неверно. К диалогу присоединился Jon Masters и мастерски завоевал всеобщую любовь, сказав, что решать уже нечего, т.к. серверные производители у себя, за речкой, все давно решили в пользу ACPI, потому что ваш DT — глючный отстой, [STRIKEOUT:и сами вы все дураки]. Чуть позже он закрепил успех сказав, что Red Hat тоже хочет ACPI на ARM, хотя не планирует выпускать коммерческий продукт в ближайшее время, так что разработчикам ARM надо все переписывать с DT на ACPI прямо сейчас. Проблема усугубилась тем, что оказалось, что Jon подписал какое-то адское NDA, запрещающее ему рассказывать публично, что же такого хорошего в ACPI по сравнению с DT? С таким вот настроением разработчики приступили к обсуждению того, все таки, как работать ядру с ACPI на ARM? Основные проблемы в том, что ACPI — это немаленькая (особенно по меркам разработчиков ARM) виртуальная машина в ядре, и в том, что реализация еще очень далека от стабилизации.
    
    Идея Olof о трансляции ACPI в DT, хотя и будет работать в каких-то случаях, не будет работать, когда в ACPI будут использоваться скрипты на ACPI Machine Language (AML), порой используемые для инициализации сложного оборудования. Увы, но аналогов в DT просто нет. Так или иначе придется реализовывать ACPI для ARM, и теперь уже понятно, что этот скандал был не последним в LKML — впереди еще UEFI.
    
    Корни сложившейся ситуации в том, что в организациях, ответственных за стандарты ARM, из авторитетных Linux-компаний есть лишь Red Hat и коллектив участников Linaro. Пока коммьюнити радовалось свободе выбора и сотням форков Linux — по одному на каждое ARM-устройство, индустрия требовала стандартов, и недождавшись конструктивного диалога с любителями «поковыряться с девайсом», решила двигаться сама. Хорошо хоть вес Red Hat в Linaro Enterprise Group сделал свое дело, и коммьюнити постепенно начало переходить к стандартизированным технологиям.
    
    Вдоволь наругавшись, начали писать код. Недавно инженерами Linaro была добавлена возможность загрузки ядра с UEFI, реализованы сервисы UEFI, и включен базовый функционал ACPI для ARM64. Этак дело пойдет, и не придется пересобирать ядро 2.6.17.4 и старые версии U-Boot с out-of-tree патчами!
    Похожие публикации: