Linux aarch64 что это
Сегодняшний мир — это amd64, armv7 и aarch64. Всё остальное мертво, Джим
Вашему вниманию предлагается перевод прощального письма Миода Валлата, разработчика OpenBSD в течение 15+ лет, покинувшего проект неделю назад. Письмо, изначально адресованное лично некоему Джиму, рассказывает историю о том, куда порой приводят благие намерения, и вызвало резонанс среди пользователей Reddit и HackerNews. Учтите — высказанное мнение субъективно, и, по словам самого автора, «вы имеете право с ним не согласиться».
Поддержка устаревшей платформы на плаву — это весело, поскольку это напоминает тебе о 90-ых, когда существовал большой выбор «железных» платформ, с приблизительно одинаковым соотношением цены/мощности. В конце концов, дешевые PC убили практически всю конкуренцию, а рынок смартфонов дал ARM нездоровую долю рынка в мире встраиваемых систем.
Затем, спустя некоторое время, веселье подходит к концу, поскольку никто не пишет код, держа в уме твою платформу, — ведь она не считается достаточно мощной, а современные компиляторы больше ее не поддерживают (или они генерируют для нее нерабочий код, что на деле еще хуже). У твоей платформы есть аппаратные границы в несколько сотен MB физической памяти? Тебе не удастся запустить на ней веб-браузер или даже программу для просмотра PDF. Кто-нибудь все еще запускает testsuite из последней версии gcc на твоей платформе? Нет? Прости, чувак, но вот тебе «никель» (5 центов), сходи купи себе уже компьютер получше…
На деле, поддержка платформы в жизнеспособном состоянии — это настоящая командная работа. Она требует серьезных обязательств от проектов, являющихся «строительными блоками»: не слишком сильно «забагованного» тулчейна (as/ld/gcc), поддержки в флагманских проектах (emacs, python, X11, mozilla, libreoffice. ), а также аккуратной и актуальной документации, доступной бесплатно.
Ни один из перечисленных пунктов не является истиной для всех платформ, исключая amd64, armv7 и aarch64.
Из-за всего этого стремление поддерживать «жизнь» какой-либо другой платформы — это на самом деле попытка плыть против течения.
Конечно, ты все еще можешь встретить нескольких безумцев, готовых выполнить невероятный объем работы для предотвращения упадка их любимой платформы и умело создающих впечатление того, что эти платформы — все еще «пассажиры первого класса». Но эти ребята — те же самые люди, что были и десять лет назад. Рано или поздно, они устают и сдаются. Как, например, я.
Самое худшее во всем этом — это когда ты оглядываешься назад и понимаешь, что после всех этих лет, свободное ПО проиграло. Компаниям, занимающимся созданием не-свободного ПО, хватило достаточно ума и смекалки, чтобы поймать «импульс» разработчиков свободного ПО, направленный на работу над встраиваемыми платформами, и использовать его для того, чтобы максимально сократить собственные расходы на разработку ПО, получив при этом еще и позитивную реакцию прессы.
Я потратил 20 лет своей жизни, пытаясь продвигать правильный взгляд на свободное программное обеспечение, его ценности и его этику; сражался за него, всегда был активно вовлечен, старался показывать другим пример, и сегодня я чувствую так, словно все мои усилия были лишь пустой тратой времени, и ничего из того, что я сделал, не принесло пользы.
С этим трудно смириться, но лучше сдаться сейчас, чем продолжать попытки и только еще больше расстраиваться.
СОДЕРЖАНИЕ
ARMv8-A
Соглашения об именах
Возможности AArch64
Расширение: подсказка для сбора данных (ARMv8.0-DGH)
AArch64 был представлен в ARMv8-A и включен в последующие версии ARMV8-A. AArch64 не входит в ARMv8-R или ARMv8-M, поскольку они обе являются 32-разрядными архитектурами.
Форматы инструкций
Основной код операции для выбора группы, к которой принадлежит инструкция A64, находится в битах 25–28.
ARMv8.1-A
В декабре 2014 года было объявлено об обновлении ARMv8.1-A с «дополнительными преимуществами по сравнению с v8.0». Усовершенствования делятся на две категории: изменения набора инструкций и изменения модели исключений и преобразование памяти.
Усовершенствования набора инструкций включали следующее:
Улучшения для модели исключений и системы перевода памяти включали следующее:
ARMv8.2-А
В январе 2016 года был анонсирован ARMv8.2-A. Его улучшения делятся на четыре категории:
Масштабируемое векторное расширение (SVE)
512-битный вариант SVE уже реализован на суперкомпьютере Fugaku с использованием процессора Fujitsu A64FX ARM. Он нацелен на то, чтобы стать самым производительным суперкомпьютером в мире с «целью начать полноценную работу примерно в 2021 году».
ARMv8.3-А
В октябре 2016 года был анонсирован ARMv8.3-A. Его улучшения делятся на шесть категорий:
Архитектура ARMv8.3-A теперь поддерживается (по крайней мере) компилятором GCC 7.
ARMv8.4-А
В ноябре 2017 года был анонсирован ARMv8.4-A. Его улучшения попали в следующие категории:
ARMv8.5-А
В сентябре 2018 года был анонсирован ARMv8.5-A. Его улучшения попали в следующие категории:
2 августа 2019 года Google объявил, что Android примет расширение Memory Tagging Extension (MTE).
ARMv8.6-A
В сентябре 2019 года был анонсирован ARMv8.6-A. Он добавляет:
Например, мелкие прерывания, инструкции ожидания события (WFE), EnhancedPAC2 и FPAC. Расширения Bfloat16 для SVE и Neon в основном предназначены для глубокого обучения.
ARMv9-A
ARMv8-R (архитектура реального времени)
В профиль ARMv8-R была добавлена дополнительная поддержка AArch64, причем первым ядром ARM, реализующим ее, было Cortex-R82. Он добавляет набор инструкций A64 с некоторыми изменениями в инструкциях по ограничению памяти.
Русские Блоги
1. Введение
Модель программирования системы ARMV8 системы в основном включает в себя ненормальный уровень, статус эксплуатации, состояние безопасности, синхронное исключение, асинхронное исключение, отладку
Эта статья в основном делает обзор модели программирования уровня системы
2. Ненормальный уровень
2.1 Обзор уровня исключения
ELX (X 64bit, в противном случае => 32 бит
Hcr_l2.rw Определяет состояние выполнения EL1, 1 => 64bit, в противном случае => 32 бит
Scr_el3.rw Определяет состояние выполнения EL2 или EL1, 1 => 64bit, в противном случае => 32 бит
4. Secure state
Non-secure
EL0 / EL1 / EL2, только доступ к небезопасному физическому адресу пространства
Secure
EL0 / EL1 / EL3, вы можете получить доступ к непроференным физическим адресным пространством и безопасным физическим адресным пространством, может использоваться для физической барьерной безопасности.
4.1 Воздействие EL3 на безопасное состояние
Внедрить EL3.
Не реализуйте EL3
4.2 EL3 влияет на влияние Aarch64 или Aarch32
Пользовательский режим (Aarch32 только) только в небезопасных EL0 или безопасных EL0
SCR_EL3.Ns определяется статусным состоянием низкого уровня EL, чтобы не определить свой собственный
EL2 только небезопасное состояние
EL0 имеет оба не защищенное состояние, также имеет безопасное состояние
Если scr_el3.ns == 0, переключитесь в безопасный статус EL0 / EL1, в противном случае переключитесь на небезопасное состояние EL0 / EL1
Защищенное состояние имеет безопасную EL0 / EL1 / EL3
Защищенное состояние только безопасно EL0 / EL3, без безопасного EL1
5. Сообщение состояния исполнения с безопасным состоянием
Рисунок EL3 Исполнение состояния и защищенная государственная комбинация при использовании Aarch64
Рисунок EL3 использует AARCH32 при выполнении состояния и защищенной государственной комбинации
Портирование ОС на Aarch64
Aarch64 — это 64-битная архитектура от ARM (иногда её называют arm64). В этой статье я расскажу, чем она отличается от «обычных» (32-битных) ARM и насколько сложно портировать на него свою систему.
Эта статья — не детальный гайд, скорее обзор тех модулей системы, которые придётся переделать, и насколько сильно архитектура в целом отличается от обычных 32-битных ARM-ов; всё это по моему личному опыту портирования Embox на эту архитектуру. Для непосредственного портирования конкретной системы так или иначе придётся разбираться с документацией, в конце статьи я оставил ссылки на некоторые документы, которые могут оказаться полезны.
На самом деле, различий больше, чем сходств, и Aarch64 — это скорее новая архитектура, чем 64-битное расширение привычных ARM. Предшественником Aarch64 во многом является Aarch32 (это расширение обычного 32-битного ARM), но так как у меня не было опыта работы с ним, писать о нём я и не буду 🙂
Далее в статье, если я пишу о «старом» или «прежнем» ARM, я имею ввиду 32-битный ARM (с набором команд ARM).
Кратко пройдусь по списку изменений по сравнению с 32-битным ARM, а затем разберу их поподробнее.
Теперь подробнее по пунктам.
Регистры и набор команд
Регистры общего назначения — r0-r30, при этом обращаться можно к ним как к 64-битным (x0-x30) или как к 32-битным (w0-w30, доступ к младшим 32 битам).
Набор инструкций для Aarch64 называется A64. Ознакомиться с описанием инструкций можно тут. Базовые арифметические и некоторые другие команды на языке ассемблера остались прежними:
Теперь немного о различиях:
Состояние программы теперь отображает не 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).
На 64-битной ОС можно выполнять и 32-битные, и 64-битные приложения; на 32-битной ОС можно выполнять только 32-битные приложения.
Переходы между EL совершаются либо при помощи исключений (системные вызовы, прерывания, ошибка доступа к памяти), либо при помощи команды возврата из исключения ( eret ).
Каждый EL имеет свои регистры SPSR, ELR, SP (т.е. это «banked registers»).
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
Было 16 регистров по 128 бит:
Стало 32 регистра по 128 бит:
Подробнее про NEON можно почитать в этой статье, перечень доступных команд для Aarch64 можно найти тут.
Базовые операции с регистрами с плавающей точкой:
Базовые операции SIMD:
Платформы
Что приятно, для этой платформы используется куча периферии, драйвера для которой уже были в Embox — например PL011 для консоли, ARM Generic Interrupt Controller и т. д. Само собой, у этих устройств другие базовые адреса регистров и другие номера прерываний, но главное — код драйверов без изменений работает на новой архитектуре. При старте системы управление находится в EL1.
Из-за этой железки и было затеяно портирование на 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, можно из нашего репозитория, если есть какие-то вопросы — пишите в комментах, или в рассылку, или в чат в Телеграме (есть ещё канал).
Полезные ссылки
24-25 августа мы будем выступать на TechTrain, слушайте наши выступления раз два три, приходите к стенду — ответим на ваши вопросы 🙂
В чем разница между различными реализациями arm64 / aarch64 для Linux или другого программного обеспечения для запуска?
Для процессоров архитектуры x86_64, независимо от того, сделаны ли они Intel, AMD или VIA. Программное обеспечение для этой архитектуры может работать на нем должным образом.
Однако, что касается arm64 / aarch64 (здесь есть разница с arm64 / aarch64), есть много поставщиков. Для дистрибутивов Linux для arm64 / arch64 существует большая ориентация.
Вот список платформ поддержки ARCH для Linux.
Но для Debian такого большого выбора нет (только arm64, а для little endian есть только armel).
Q1. Чем отличаются эти платформы поддержки от Archlinuxarm?
Затем я открываю Termux и набираю:
К сожалению, говорят, что интерпретатор оболочки не является исполняемым (в другой архитектуре).
Q2. Если я установлю систему archlinuxarm для платформы A на платформу B. Это просто не может быть максимально оптимизировано или совсем не совместимо?
Q3. Существуют ли дистрибутивы для разных платформ, просто разные по их драйверам или по разнице параметров при компиляции ядер Linux?
Q4. Что меня смущает, так это причина, по которой сообщество archlinuxarm не предоставляет tar-архив stage-rootfs только для arm64 armel и т. Д. Вместо разных продуктов разных производителей? Означает ли это, что, например, набор команд в DragonBoard 410c отличается от Raspberry Pi 3? Или, другими словами, если я установлю Archlinuxarm для DragonBoard 410c в Raspberry Pi 3, что произойдет? Это может загрузиться правильно?
Ваш вопрос может быть истолкован как довольно широкий, но я думаю, что вы на самом деле спрашиваете, является чрезвычайно конкретным. Принципиальная разница между различными реализациями arm64 и aarch64.
Наборы инструкций
В основе каждого микропроцессора лежит набор инструкций, которые он может выполнять. Интерфейс к наборам команд – это то, что компиляторы преобразуют языки программирования более высокого уровня, такие как C / C ++, в машинный код. Этот машинный код является инструкциями из набора команд процессора. Кстати, инструкции в наборе команд обычно выглядят так:
ПРИМЕЧАНИЕ. Вы также услышите машинный код, называемый языком ассемблера.
arm64 против aarch64
Таким образом, aarch64 и arm64 относятся к одному и тому же.
Некоторые из ваших вопросов
Вы задаете вопросы, которых слишком много, чтобы ответить на один вопрос. Я постараюсь ответить на самое важное, хотя.
Q4. Что меня смущает, так это причина, по которой сообщество archlinuxarm не предоставляет tar-архив stage-rootfs только для arm64 armel и т. Д. Вместо разных продуктов разных производителей? Означает ли это, что, например, набор команд в DragonBoard 410c отличается от Raspberry Pi 3? Или, другими словами, если я установлю Archlinuxarm для DragonBoard 410c в Raspberry Pi 3, что произойдет? Это может загрузиться правильно?
Чтобы узнать подробности, вам нужно спросить сообщество Arch, почему они решили сделать что-то в рамках этого проекта. С точки зрения вашего вопроса о запуске Archlinuxarm, созданной специально для 410c на Raspberry Pi 3, я бы посоветовал попробовать.
Оба этих процессора являются процессорами ARM, как показано здесь:
Поэтому я ожидаю, что вы сможете использовать одни и те же двоичные файлы на обоих. Наконец, я бы, вероятно, в качестве дополнительного вопроса на сайте Raspberry Pi Stackexchange. Есть множество вопросов в соответствии с тем, что вы там задаете, например: