Linux armv8l что это

Обновлено: 07.07.2024

Вместо того, чтобы пытаться описать всё разнообразие аппаратных конфигураций, которое существует на 64-bit ARM , эта глава содержит общую информацию и указания, где можно найти дополнительную информацию.

2.1.1. Поддерживаемые архитектуры

Debian GNU/Linux 11 поддерживает 9 основных архитектур и несколько вариаций каждой архитектуры, известных как « варианты (flavors) » .

Архитектура	Обозначение в Debian	Субархитектура	Вариант
AMD64 & Intel 64	amd64
основанные на Intel x86	i386	машины x86 по умолчанию	по умолчанию
основанные на Intel x86	i386	только домены Xen PV	xen
ARM	armel	Marvell Kirkwood и Orion	marvell
ARM с аппаратным FPU	armhf	multiplatform	armmp
64-битные ARM	arm64
64-битные MIPS (с обратным порядком байтов)	mips64el	MIPS Malta	5kc-malta
		Cavium Octeon	octeon
		Loongson 3	loongson-3
32-битные MIPS (с обратным порядком байтов)	mipsel	MIPS Malta	4kc-malta
		Cavium Octeon	octeon
		Loongson 3	loongson-3
Power Systems	ppc64el	машины IBM POWER8 или новее
64-битный IBM S/390	s390x	IPL с VM-reader и DASD	generic

Этот документ содержит описание установки на архитектуру 64-bit ARM . Если вы ищете информацию по любой другой архитектуре, поддерживаемой Debian, посмотрите на странице переносов Debian.

Это первый официальный выпуск Debian GNU/Linux для архитектуры 64-bit ARM . Мы его готовым к выпуску. Однако, поскольку эта архитектура не так сильно распространёна (и, следовательно, не протестирована пользователями), как другие, вы можете встретить некоторые ошибки. Используйте нашу Систему отслеживания ошибок, чтобы сообщить о любой проблеме; убедитесь, что вы упомянули тот факт, что ошибка возникла на архитектуре 64-bit ARM , использующей ядро Linux . Возможно, также придётся воспользоваться списком рассылки debian-arm.

2.1.2. Три разных переноса ARM

Архитектура ARM постоянно развивается и современные процессоры ARM предоставляют возможности, которые недоступны в старых моделях. Поэтому Debian предоставляет три переноса ARM, что даёт улучшенную поддержку широкому диапазону различных машин:

Debian/armel нацелен на старые 32-битные процессоры ARM без поддержки блока аппаратной плавающей запятой (FPU),

Debian/armhf работает только на новых 32-битных процессорах ARM, в которых реализована, как минимум, архитектура ARMv7 версии 3 из спецификации векторной плавающей запятой ARM (VFPv3). Он позволяет использовать расширенные возможности и повышенную производительность, доступные на этих моделях.

Debian/arm64 работает на 64-битных процессорах ARM, в которых реализована, как минимум, архитектура ARMv8.

Технически, все доступные в настоящее время процессоры ARM могут работать с любым порядком адресации памяти (прямым или обратным), но практически подавляющее большинство использует обратную адресацию. Debian/arm64, Debian/armhf и Debian/armel поддерживают только системы с обратной адресацией.

2.1.3. Разнообразие конструкций процессоров ARM и сложность поддержки

Системы ARM намного разнообразнее, чем архитектура ПК на основе i386/amd64, поэтому ситуация с поддержкой может оказаться намного сложнее.

В архитектуре ARM используется так называемая « система на кристалле » (SOC). Эти SOC, разрабатываемые многими разными компаниями, содержат сильно отличающиеся аппаратные компоненты, используемые даже в таких основных задачах как запуск системы. Старые версии архитектуры ARM имеют много отличий между поколениями SoC, но ARMv8 (arm64) намного стандаризованнее и поэтому её легче поддерживать в ядре Linux и другом ПО.

Серверные версии аппаратного обеспечения ARMv8, обычно, настраиваются с помощью стандартных универсального интерфейс расширяемой микропрограммы (UEFI) и улучшенного интерфейса настройки и управления электропитанием (ACPI). Они предоставляют общие, независимые от устройств способы запуска и настройки компьютерного оборудования. Также, они поддерживаются и в мире ПК x86.

2.1.4. Платформы, поддерживаемые Debian/arm64

Аппаратное обеспечение Arm64/AArch64/ARMv8 появилось в конце цикла выпуска Debian Bullseye, так как в этот момент немногие платформы поддерживались основной версией ядра; это является основным требованием для работы debian-installer . Далее перечислены платформы, которые поддерживаются в этом выпуске Debian/arm64. Есть только один образ ядра, который поддерживает все перечисленные платформы.

Платформа разработки ARM Juno

При использовании debian-installer на системах без UEFI вам придётся вручную сделать систему загрузочной в конце установки, например запустив необходимые команды оболочки, запущенной из debian-installer . flash-kernel позволяет настроить загрузку системы X-Gene через U-Boot.

2.1.4.1. Другие платформы

Мультиплатформенная поддержка в ядре Linux arm64 также позволяет запускать debian-installer на системах arm64, не описанных выше. Если в ядре, используемом debian-installer , есть поддержка аппаратных частей и файла дерева устройств целевой машины, то новая целевая система сможет прекрасно работать. В этих случаях программа установки, обычно, способна предоставить работающую пользовательскую установку и при условии использования UEFI, вероятно, сможет сделать систему загрузочной. Если UEFI не используется, то вам также может понадобиться выполнить несколько ручных действий для загрузки системы.

2.1.5. Несколько процессоров

На этой архитектуре поддерживается нескольких процессоров — так называемая « симметричная многопроцессорная обработка (symmetric multi-processing) » или SMP. Раньше, несколько процессоров имелось только в высокопроизводительных серверных системах, но в настоящее время так называемые « многоядерные » процессоры встраивают почти по всё. В них содержится один ЦП с двумя и более вычислительными блоками, называемыми « ядрами » .

Стандартный образ ядра Debian 11 собран с поддержкой SMP. Он также без проблем работает в системах без SMP.

2.1.6. Поддержка видеокарт

Почти все машины ARM содержат встроенную графику, не в виде отдельной графической карты. У некоторых машин есть слоты расширения, в которые можно вставить карту, то это редко. Также распространены машины вообще без графики. Базовые графические возможности через фреймбуфер, предоставляемые ядром, должны работать на всех устройствах с графикой, для работы 3D ускорения всем без исключения требуются двоичные драйверы. Ситуация быстро меняется, но в выпуск bullseye включены свободные драйверы nouveau (процессор Nvidia Tegra K1) и freedreno (процессоры Qualcomm Snapdragon). Другим чипам требуются несвободные драйверы производителя.

2.1.7. Аппаратура для подключения к сети

Почти любая сетевая плата (NIC), поддерживаемая ядром Linux, должна поддерживаться системой установки; драйверы модулей должны загрузиться автоматически.

На 64-bit ARM поддерживается большинство встроенных устройств Ethernet и предоставляются модули для дополнительных устройств PCI и USB.

2.1.8. Периферия и другое оборудование

Linux поддерживает много разных устройств, таких как мыши, принтеры, сканеры, PCMCIA/CardBus/ExpressCard и USB устройства. Однако, большинство этих устройств не требуется для установки системы.

в Intel я знаю, что могу посмотреть на результат uname -m , если моя ОС будет 32- или 64-битной, но в ARM это дает:

что я на 32-битной ОС, но как я могу узнать это проще?

@ Richard Я так и думал, но тогда как называется 64-битный вариант? У меня нет доступа к машине ARM, но каковы результаты uname -a и gcc -v ? Это может быть полезно. Arm был последним из 32-битных процессоров, которые стали 64-битными (исключая тех, кто умер). Большинство перешло на 64-битную версию, а затем умерло из-за плохого маркетинга - предполагая, что лучше быть достаточно. Intel x86 был вторым по продолжительности, хотя это была AMD, которая добавила 64 бит.

Существует несколько градаций, поскольку вы можете запускать 32-битную или смешанную операционную систему на 64-битном процессоре. Посмотрите 64-битное ядро, но все 32-битные исполняемые ELF-процессы, как это? для подробного обсуждения (написано для x86, но большая часть относится и к arm).

Вы можете найти модель процессора в /proc/cpuinfo . Например:

ARMv7 (и ниже) является 32-битным. ARMv8 представляет 64-битный набор команд.

Если вы хотите узнать, поддерживает ли ваша система 64-битные двоичные файлы, проверьте архитектуру ядра:

Я не оспариваю ваш ответ, но, к сожалению, android - это LINUX, так что, предположим, есть какая-то команда, ГДЕ-ТО, которая показывает его локально и не читает документацию на какой-то странице @THESorcerer Android использует ядро Linux, но это не система Linux. У него нет пользовательских инструментов Linux (только очень небольшое подмножество). На Android, я думаю, что поддержка 64-битной операционной системы в базовой ОС является постоянной, поэтому cat /proc/$$/maps вы сможете узнать, является ли система 64-битной или 32-битной из командной строки adb. Я полагаю, что Raspberry Pi 3, который является ARMv8 (CRC, без дополнительного Crypto), сообщит, armv7l даже если его ARMv8. Так что я уверен, что о неправильном процессоре будет сообщено. @jww Если он сообщает armv7l , это означает, что вы используете 32-битное ядро. Вы можете запустить 32-битное ядро на 64-битном процессоре. Если вам нужна информация о процессоре, прочитайте /proc/cpuinfo . uname -m просто возвращает "aarch64". / proc / cpuinfo также не всегда содержит имя для процессора.

Как указывает Ричард, armv7 все варианты 32-битные, поэтому нет избыточной метки armv7-32 и т. Д.

В системе linux вы можете легко, хотя и не совсем точно, проверить, изучив общий исполняемый файл:

Я говорю «не окончательно», потому что можно запускать 32-битные исполняемые файлы в 64-битной системе.

Там, кажется, нет ничего надежного в /proc или /sys ; вывод из /proc/cpuinfo может предоставить некоторые важные подсказки. Если по какой-либо причине вам нужна автоматическая проверка, создание таблицы, сопоставленной с полем «имя модели», кажется одним из потенциально надежных методов (другие поля, включая «модель», «семейство процессоров» и т. Д. Выглядят необязательными - они не у меня вообще нет процессора Broadcom 2708 ARMv6).

Часто при загрузке Андроид-приложений на сайтах предлагающих такую возможность, у пользователей есть возможность выбора файлов для различных архитектур системы. И тут возникают сложности — какую из загрузок нужно скачивать и устанавливать.

Архитектура процессора — это, простыми словами, схема по которой работают части процессора между собой, а также набор команд с помощью которых они «общаются» с другими частями устройства.

Многие разработчики делают универсальные приложения и игры, которые подходят под любые архитектуры процессоров. Но некоторые из них создают несколько версий программ специально «заточенных» под ту или иную архитектуру. При установке такого продукта из Google Play, сервис автоматически определяет все необходимые параметры установки и загружает на пользовательское устройство необходимые файлы. Пользователю не нужно думать над тем какой файл скачать.

Если же установка (по той или иной причине) из Google Play невозможна или нежелательна, пользователь может скачать файл APK на стороннем сайте. С его помощью можно установить приложение или игру «в ручном режиме». Вот тут-то, если на сайте есть несколько вариантов таких файлов, и появляются муки выбора.

На сегодняшний день, сайты предлагающие файлы для установки приложений и игр могут распространять APK-файлы следующих архитектур: armeabi-v7a, arm64-v8a, x86 и x86_64.

armeabi-v7a — файлы работающие на устройствах с архитектурой ARM и 32-разрядным процессором. Самые распространенный тип архитектуры.
arm64-v8a — файлы работающие на устройствах с архитектурой ARM и 64-разрядным процессором. Сейчас все больше девайсов используют такие процессоры.
x86 — файлы работающие на устройствах с архитектурой от компании Intel с 32-разрядным процессором. Довольно мощные, но плохо оптимизированные для работы с батареей чипы. В основном используются в планшетах.
x86_64 — файлы работающие на устройствах с архитектурой от компании Intel с 64-разрядным процессором. Такие процессоры используются в некоторых мощных планшетах. Также файлы этого типа можно запускать на эмуляторах Андроид для ПК.

Исходя из вышесказанного, можно составить такие правила совместимости:

На устройства с архитектурой armeabi-v7a можно ставить только файлы armeabi-v7a.
На устройства с архитектурой arm64-v8a можно ставить файлы armeabi-v7a и arm64-v8a.
На устройства с архитектурой x86 можно ставить только файлы x86.
На устройства с архитектурой x86_64 можно ставить файлы x86 и x86_64.

В большинстве случаев телефоны используют архитектуру ARM. Более дешевые устройства используют версию armeabi-v7a, более мощные — версию arm64-v8a. Поэтому, если сомневаетесь в том, какую версию файла выбрать, выбирайте ту, которая имеет отметку «armeabi-v7a».

Определение архитектуры процессора устройства

Теперь, когда мы разобрались с теоретической частью, пора определить — на какой архитектуре разработан ваш телефон или планшет.

Для этого можно воспользоваться инструкцией к устройству (но в ней не всегда можно найти нужную информацию) или же найти данные в интернете. Но лучше всего это сделать с помощью специального приложения.

Самый простой способ!

Если у вас установлено приложение Telegram ( то самое ) вы можете узнать архитектуру процессора буквально за пару кликов. Для этого войдите в меню приложения и нажмите «Настройки». В самом низу открывшегося меню будет черным по белому (или белым по черному, в зависимости от настроек) прописаны нужные нам данные.

Droid Hardware Info

Если вышеописанный способ вас чем-то не устраивает или же вы хотите получить более расширенные данные о системе вашего устройства, воспользуйтесь приложением Droid Hardware Info.

Установите эту утилиту в Google Play или с помощью APK-файла (скачав его на сайте Biblprog). Для получения нужной нам информации запустите Droid Hardware Info, перейдите на вкладку «Система» и обратите свое внимание на раздел «Процессор».

В самой первой строке с названием «Архитектура процессора» вы увидите одно из значений: ARMv7, AArch64 или x86, а в строке «Набор инструкций»: armeabi-v7a, arm64-v8a или x86abi. Этого вам должно хватить для того, чтобы решить какой APK-файл скачивать и устанавливать на свой смартфон или планшет.

Нужные данные можно получить и с помощью других приложений, доступных на Google Play, например Inware или My Device .

Как вам данная инструкция? Все ли понятно? Если у вас появились дополнительные вопросы или же возникли замечания к информации выложенной на данной странице — не стесняйтесь. Напишите в комментариях!

С момента своего релиза в 2011 году процессорная архитектура ARMv8 получила достаточно широкое распространение на рынке мобильных устройств. По прогнозам главы компании ARM Limited, к 2020 году процессоры этого поколения займут до 25% мирового рынка. Вполне закономерно, что и программная составляющая сформирована и развивается, наследуя черты и общие принципы исторически сложившейся инфраструктуры.

Принципиально иная ситуация сложилась в серверном сегменте. На этом рынке уже продолжительное время доминируют серверы на базе x86, и ARMv8 только начинает проникновение на него, причём речь пока идёт только об определённых специфических нишах. Новизна этого рынка для ARM и тот факт, что большая часть принятых стандартов и спецификаций (в первую очередь ACPI и UEFI) до недавнего времени не были адаптированы для ARM-систем, накладывает свой отпечаток на развитие программной инфраструктуры.

Данная статья сфокусирована на рассмотрении особенностей серверных ARM-систем и процессов и не претендует на исчерпывающее описание. Авторы хотели бы обратить внимание также на том, что изложенные здесь данные могут достаточно быстро устареть, поскольку уже в обозримом будущем новые процессоры будут сопровождаться новыми техническими решениями, которые потребуют иного подхода к реализации программной инфраструктуры.

Прежде всего следует указать, что нынешние реализации микропрограммных средств для серверных систем на ARMv8 состоят из нескольких относительно независимых компонентов. Это даёт ряд преимуществ, например возможность использования одних и тех же компонентов в микропрограммных средствах как серверных, так и встраиваемых систем, а также относительную независимость вносимых изменений.

Итак, какие же модули и компоненты используются в рассматриваемых системах, и каковы их функции? Общая схема загрузки и взаимодействия модулей показана на рис. 1. Процесс начинается с инициализации оборудования таких подсистем, как оперативная память и межпроцессорные интерфейсы. В текущих реализациях она исполняется отдельным модулем в режиме EL3S сразу после включения питания. Таким образом, данный компонент системы обладает максимально возможными привилегиями. Он обычно не взаимодействует с ОС непосредственно.

Рис. 1. Процесс загрузки и общая схема взаимодействия микропрограммных модулей ARMv8

Далее управление передаётся следующему компоненту, чаще всего модулю ARM Trusted Firmware (ATF), исполняемому в том же режиме. Управление ATF может передаваться как непосредственно от загрузчика 0-го уровня, рассмотренного в предыдущем абзаце, так и опосредованно через специальный модуль UEFI, который реализует так называемую процедуру загрузки PEI (PreEFI Initialization). ATF состоит из нескольких модулей, получающих управление в разные моменты времени. Стартовый модуль BL1 выполняет инициализацию частей платформы, связанную с доверенным (secure) режимом работы процессора. Поскольку в системах на базе ARMv8 применяется аппаратное разделение доверенных и обычных ресурсов, включая оперативную память, то модуль BL1 создаёт такое окружение, в котором мог бы функционировать доверенный код. В частности, к этому типу инициализации относится настройка контроллеров памяти/кэша (чаще всего доверенные и обычные зоны размечаются путём программирования регистров в этих устройствах) и разметка накристалльных устройств (контроллеры энергонезависимой памяти). Такая разметка также вводит и фильтрацию DMA-транзакций на основе типа устройства (доверенный/недоверенный). При этом запись/чтение памяти возможны только в область/из области того же типа, что и устройство.

Реализация доверенного окружения может быть достаточно сложной, например включающей отдельную ОС. Однако описание подобных реализаций выходит за рамки данной статьи. Модуль BL1 настраивает таблицу преобразования адресов MMU, а также таблицу обработчиков исключений, самым важным элементом которой является обработчик исключения от инструкции вызова доверенного окружения (Secure Monitor Call, SMC). На данном этапе обработчик минимален и способен фактически только передавать управление загруженным в оперативную память образам. В процессе исполнения модуль BL1 загружает в ОЗУ следующую стадию, BL2, и передаёт управление на неё. Модуль BL2 работает с пониженными привилегиями, в режиме EL1S. Соответственно, передача управления этому модулю производится с помощью инструкции ERET.

Предназначение модуля BL2 — загрузка остальных микропрограммных модулей (частей BL3) и передача им управления. Пониженный уровень привилегий используется для того, чтобы не повредить код и данные EL3S, уже находящиеся в памяти. Управление этим частям передаётся путём вызова кода EL3S, размещённого на стадии BL1, с помощью инструкции SMC.

Третья стадия загрузки и инициализации ATF может состоять из трёх этапов, но довольно часто второй этап пропускается, так что на деле и их остаётся только два. Модуль BL3-1 представляет собой ту часть доверенного кода, которая доступна обычному ПО (ОС и т.д.) во время его исполнения. Ключевая часть этого модуля – функция обработки исключения, вызванного инструкцией SMC. В самом модуле располагаются функции реализации стандартных вызовов SMC: код, реализующий стандартизированный интерфейс PSCI (предназначен для управления всей платформой: включения/отключения процессорных ядер, питания всей платформы, перезагрузки и т. д.), а также отвечающий за вызовы, зависящие от производителя и конкретной реализации платформы (получение информации о платформе, управление некоторыми встроенными устройствами и т.п.).

Наличие модуля BL3-2, как мы уже отмечали выше, не является обязательным; его код (в случае наличия модуля) выполняется в режиме EL1S. Обычно он служит в качестве специализированного сервиса/монитора событий, происходящих во время работы платформы (прерывания от некоторых таймеров, устройств и т.п.).

BL3-3, по сути, модулем ATF не является. Это образ прошивки (firmware), исполняемой в незащищённом режиме. Запускается он обычно в режиме EL2 и представляет собой образ либо загрузчика наподобие широко известного U-Boot, либо окружения UEFI, стандартного для серверных систем.

Общая схема загрузки модулей ATF показана на рис. 2.

Рис. 2. Схема загрузки в оперативную память модулей ATF

На ряде серверных систем на базе ARMv8 применяется другая схема загрузки: ATF запускается во время фазы UEFI PEI, после чего происходит переход на фазу UEFI DXE.

UEFI для ARMv8 значительно отличается от такового для x86. Фазы PEI (Pre-EFI initialization) и DXE (Driver) используются и для x86, и для ARMv8. Однако на многих системах ARMv8 фаза PEI значительно сокращена и во время неё не выполняется никакой инициализации оборудования. Этот этап сводится к настройке таблиц трансляции MMU, настройке контроллера прерываний и таймера (согласно спецификации UEFI, единственным обрабатываемым прерыванием для этого окружения является прерывание от таймера), построению блоков конфигурационной информации (EFI Hand-off block, HOB) и запуску модуля DXE Core. На данном этапе платформозависимые модули UEFI достаточно широко используют специфические для платформы вызовы SMC, описанные ранее.

На этапе DXE выполняется основной объём работы UEFI. Прежде всего это развёртывание и запуск драйверов аппаратного обеспечения — как встроенных в кристалл блоков, так и внешних устройств, подключаемых по интерфейсам PCIe, USB, SATA и пр.

Следует отметить, что системы на базе ARMv8 демонстрируют довольно серьёзные отличия от подобных систем на основе архитектуры x86 в плане конфигурации, механизмов обнаружения устройств, и т.п. Так, для x86 основным механизмом обнаружения устройств является механизм обхода конфигурационного пространства PCI с назначением устройствам адресов памяти, которые они должны декодировать. В случае систем на базе ARMv8 встроенные блоки практически всегда имеют фиксированные адреса в пространстве памяти (пространство портов не используется, так как не является частью архитектуры) и в некоторых случаях не отображаются в конфигурационном
пространстве PCI. Для таких систем используется описание аппаратуры, составленное в виде так называемой Flattened Device Tree — древовидной базы данных, описывающей иерархию подключения аппаратных блоков, а также такие ресурсы, как области памяти, номера прерывания и т.п., связанные с этими блоками.

В более продвинутых системах блоки, входящие в состав SoC, поддерживают доступ через конфигурационное пространство PCI, и соответственно обладают контроллерами, реализующими доступ к этому пространству посредством механизма ECAM (Enhanced Configuration Access Mechanism). Поскольку адреса памяти у таких блоков всё равно фиксированные, поддержка обычного механизма конфигурирования устройств PCI не представляется целесообразной. Специально для систем с фиксированными адресами PCI-устройств было разработано расширение Enhanced Allocation, разрешающее этот конфликт. Уникальные свойства этого расширения достойны отдельной публикации, но вкратце оно может быть описано как расширение, состоящее из набора альтернативных регистров, в которых содержится информация об адресах памяти, номерах шин (для встроенных мостов PCI—PCI) и т.д.

UEFI неотделимо от другого метода передачи информации о конфигурации платформы — ACPI. В настоящее время мы наблюдаем поступательное развитие и доработку спецификаций ACPI в интересах более полной поддержки именно архитектуры ARMv8. По имеющейся информации, ACPI должна стать основным методом передачи базовой информации о платформе (прежде всего о числе и конфигурации процессорных ядер, контроллеров PCI/PCIe) и управления ею для ARMv8. Некоторые из планируемых к выпуску на ARMv8 ОС поддерживают исключительно ACPI.

Итак, на этапе DXE выполняется обнаружение устройств (в тех системах, с которыми приходилось встречаться авторам, для этого используется механизм PCI ECAM), их инициализация и регистрация в UEFI, а также подготовка к запуску ОС. Последняя заключается в подготовке карты памяти системы и конфигурационной информации, то есть в загрузке, генерации и публикации таблиц ACPI, внесении в загруженные таблицы изменений, отражающих текущую конфигурацию платформы, внесении подобных же изменений в FDT, проверке и генерации контрольных сумм. Ряд модулей, загруженных на этом этапе, реализует так называемые UEFI Runtime Services — функции, доступные для вызова из ОС во время её исполнения.

По завершении этого этапа начинается этап выбора устройства для загрузки (Boot Device Selection, BDS). Обычно на этой стадии используется отдельный модуль, обрабатывающий значения переменных BootOrder, BootNext и т.д. Часто такой модуль реализует (псевдо)графический интерфейс. На этом этапе можно заметить большое сходство с системами на базе x86: используются те же самые методы загрузки – PXE, iSCSI, блочные устройства (такие как SATA/SAS/USB диски, SSD, NVME устройства) и т.п.

Отдельно хотелось бы обратить внимание на драйверы внешних устройств (обычно это устройства PCIe) для ARMv8 UEFI. Они могут быть реализованы как в виде модулей, расположенных на устройствах хранения (с файловой системой FAT32), так и располагаться непосредственно на самом устройстве (Option ROM). Добавление в список поддерживаемых архитектур ARMv8 в некоторых случаях вызывает проблемы для производителей. Простой перекомпиляции исходного кода для ARMv8 не всегда достаточно, так как ряд таких модулей не рассчитан на работу в полном 64-битном адресном пространстве. Также некоторые сложности порой вызывает тот факт, что на системах ARMv8 широко используется трансляция шинных адресов PCI в процессорные и наоборот. Это связано с тем, что при разработке решено было отказаться от унаследованных «окон», располагающихся в пределах младших 32 бит. В плане расширения поддержки могли бы помочь драйверы, скомпилированные в байт-код EBC, но на момент написания этой статьи интерпретатор EBC для ARMv8 находился на ранних стадиях разработки.

Передача управления загруженному в память модулю (загрузчик или непосредственно ядро ОС) выполняется в соответствии со спецификацией UEFI: уникальный указатель в регистре X0, указатель на системную таблицу в X1, и адрес возврата в X30 (LR).

Ядро ОС выполняет некоторые подготовительные процедуры, используя сервисы UEFI, затем устанавливает собственные таблицы трансляции и вызывает метод UEFI SetVirtualAddressMap(). Необходимость этих процедур обусловлена тем обстоятельством, что код UEFI выполняется в том же адресном пространстве, что и ОС, а также необходимостью отключения прерываний таймера. Следует отметить, что в случае использования архитектуры ARMv8 для ОС Linux, есть один нюанс: основной код ядра работает в режиме EL1, тогда как в режиме EL2 вместе с сервисами UEFI выполняется только часть кода гипервизора KVM. После этого ядру из сервисов UEFI становятся доступны только так называемые Runtime Services – подмножество всех сервисов UEFI. Ядро Linux на ARMv8 широко использует интерфейс PSCI (при его наличии), реализуемый одним из модулей ATF, как было указано ранее. Это особенно характерно для многоядерных систем. Сам интерфейс и процесс инициализации процессорных ядер можно кратко описать как вызов SMC с номеров функции PSCI и точкой входа в функцию инициализации в качестве одного из параметров. Собственно, вызовы сервисов UEFI и SMC и являются в настоящее время основным способом взаимодействия ОС и микропрограммы (firmware). Существуют черновые спецификации способа уведомления ОС о различных событиях из микропрограммы, но на текущий момент (2015) о каких-либо готовых реализациях не сообщалось.

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

Читайте также: