Linux arm что это

Установка Linux на ARM. Подробная пошаговая инструкция и советы

Установка Linux на ARM — это довольно интересная тема. Даже принимая только то, что это довольно-таки необычно. Почему необычно? П отому что в ARM-процессорах совсем другая архитектура, чем у тех, для которых рассчитано большинство дистрибутивов Линукс.

Основная масса больших и привычных ПК имеют архитектуру х86 или AMD64. Данные процессоры рассчитаны на трудо- и ресурсоемкие задачи:

Но в т о ж е время ARMка имеет более низкое энергопотребление при должной производительности, а это как раз очень важно для небольших устройств. И поэтому она распространена в «маленьких» устройствах.

Какие операционные системы подходят для ARM?

Итак, из семейства Linux для ARM можно подобрать конфигурации у следующих дистрибутивов:

При полной «перепрошивке» вы потеряете весь предустановленный производителем функционал. Вряд ли это будет то, чего вы добиваетесь. Поэтому тут можно воспользоваться вторым способом и установить Linux, не удаляя основную операционную систему вашего устройства. Для этого нужно будет настроить запуск chroot-окружения внутри Андроид. Но зато на выходе вы получите 2 параллельно установленные операционные системы и сможете использовать то одну, то другую. С т ак им подход ом можно поэкспериментировать на смартфонах или планшетах, где есть экран. А на простых безэкранных устройствах с таким способом могут возникнуть трудности.

Сама технология установки Linux на ARM еще в довольно «сырой» форме. Да, есть какие-то наработки и отдельные дистрибутивы. Есть умельцы, которые делают это и говорят, что это круто. Но в целом материала и стабильности в этом мало. Это не касается тех устройств, в которых Linux предустановлен производителем!

Мы будем очень благодарны

если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.

Источник

Чем архитектура ARM отличается от x86

Обе архитектуры имеют свои плюсы и минусы, а также сферы применения, но есть и общие черты. Многие специалисты говорят, что за ARM будущее, но у нее остаются некоторые недостатки, которых нет в x86. В нашей сегодняшней статье мы рассмотрим чем архитектура arm отличается от x86. Рассмотрим принципиальные отличия ARM или x86, а также попытаемся определить что лучше.

Что такое архитектура?

Архитектура x86

Первый процессор Intel 8086 имел разрядность 16 бит, далее в 2000 годах вышел процессор 32 битной архитектуры, и еще позже появилась архитектура 64 бит. Мы подробно рассматривали разрядность процессоров в отдельной статье. За это время архитектура очень сильно развилась были добавлены новые наборы инструкций и расширения, которые позволяют очень сильно увеличить производительность работы процессора.

Архитектура ARM

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

В отличие от x86, разработчики изначально пытались получить минимальные затраты на ресурсы, они имеют меньше инструкций процессора, меньше транзисторов, но и соответственно меньше всяких дополнительных возможностей. Но за последние годы производительность процессоров ARM улучшалась. Учитывая это, и низкое энергопотребление они начали очень широко применяться в мобильных устройствах, таких как планшеты и смартфоны.

Отличия ARM и x86

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

Производство

Производство x86 vs arm отличается. Процессоры x86 производят только две компании Intel и AMD. Изначально эта была одна компания, но это совсем другая история. Право на выпуск таких процессоров есть только у этих компаний, а это значит, что и направлением развития инфраструктуры будут управлять только они.

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

Количество инструкций

Это главные различия архитектуры arm и x86. Процессоры x86 развивались стремительно, как более мощные и производительные. Разработчики добавили большое количество инструкций процессора, причем здесь есть не просто базовый набор, а достаточно много команд, без которых можно было бы обойтись. Изначально это делалось чтобы уменьшить объем памяти занимаемый программами на диске. Также было разработано много вариантов защит и виртуализаций, оптимизаций и многое другое. Все это требует дополнительных транзисторов и энергии.

ARM более прост. Здесь намного меньше инструкций процессора, только те, которые нужны операционной системе и реально используются. Если сравнивать x86, то там используется только 30% от всех возможных инструкций. Их проще выучить, если вы решили писать программы вручную, а также для их реализации нужно меньше транзисторов.

Потребление энергии

Из предыдущего пункта выплывает еще один вывод. Чем больше транзисторов на плате, тем больше ее площадь и потребление энергии, правильно и обратное.

За последние годы потребление энергии процессорами x86 очень сильно уменьшилось, например, новые процессоры Intel Haswell могут работать дольше от батареи. Сейчас разница arm vs x86 постепенно стирается.

Тепловыделение

Производительность процессоров

ARM изначально не были заточены для максимальной производительности, это область преуспевания x86. Отчасти этому причина меньше количество транзисторов. Но в последнее время производительность ARM процессоров растет, и они уже могут полноценно использоваться в ноутбуках или на серверах.

Выводы

В этой статье мы рассмотрели чем отличается ARM от x86. Отличия довольно серьезные. Но в последнее время грань между обоими архитектурами стирается. ARM процессоры становятся более производительными и быстрыми, а x86 благодаря уменьшению размера структурного элемента платы начинают потреблять меньше энергии и выделять меньше тепла. Уже можно встретить ARM процессор на серверах и в ноутбуках, а x86 на планшетах и в смартфонах.

А как вы относитесь к этим x86 и ARM? За какой технологией будущее по вашему мнению? Напишите в комментариях! Кстати, Линус Торвальдс предпочитает x86.

На завершение видео о развитии арихтектуры ARM:

Источник

Загрузка ОС на ARM

Недавно попросили в двух словах рассказать серьезным людям о загрузке операционной системы на ARM и дать оценку угроз безопасности этого процесса. Вообще ARM-процессоров и вообще ОС. Вы понимаете, все ведь слышали про эти ARM, и что такое ОС тоже все знают. Желательно, на уровне квадратиков со стрелками.

Загрузка ARM в четырех прямоугольниках — под катом.

Сразу ограничим уровень детализации. Нас интересует, что происходит, а не как, то есть конкретные инструкции процессора оставим в стороне. Постараемся найти общее у всех процессоров и всех ОС. Поищем угрозы безопасности.

Разновидности процессоров ARM

Если вы знаете про ARM, то этот раздел можно смело пропустить.

В производстве и эксплуатации сейчас встречаются процессоры ARM пяти архитектур: ARMv4, ARMv5, ARMv6, ARMv7 и ARMv8. Компания ARM дает этим архитектурам коммерческие названия, поэтому ARMv4 называется, например, ARM7, ARMv5 – ARM9, а название Cortex имеют процессоры на архитектурах ARMv6, v7, v8. Следующая таблица перечисляет основные разновидности.

Например, кнопочные телефоны в основном используют ARM7, а смартфоны – Cortex-A. Современные смартфоны строятся преимущественно на ARMv8, единственных 64-битных. Процессоры ARM7 и ARM9 широко применялись в различных промышленных контроллерах, сетевом оборудовании, а сейчас фокус переходит на использование в них Cortex-A. В различной бытовой технике, мелких электронных приборах, в области безопасности и т.п. применяются микроконтроллеры Cortex-M.

Вообще все устройства ARM можно условно разбить на микроконтроллеры и Application Processor.

Виды ОС

Какие есть варианты запуска ОС:

В дальнейшем мы будем говорить только о запуске ОС (Linux, Android) или RTOS на ARM. По способу запуска “большие” RTOS попадают в одну группу с Linux, а “малые” RTOS объединяются с программами без ОС.

Для запуска Linux хорошо подходят процессоры ARM9, ARM11, Cortex-A. Усеченную версию Linux также можно загрузить на ARM7, Cortex-M4 и Cortex-M7, но это нецелесообразно.

Для запуска малых RTOS подходят микроконтроллеры и процессоры ARM7, ARM9, Cortex-M. В некоторых случаях для RTOS используют начальные модели Cortex-A, например, Cortex-A5. Большинство же процессоров Cortex-A столь сложны, что их возможности можно использовать только совместно с поставляемым производителем Linux/Android SDK, что и определяет выбор в пользу Linux.

Загрузчик ОС

С точки зрения разработчика системное ПО устройства делится на загрузчик и ОС. Основную функцию всегда выполняет программа, работающая под управлением ОС или RTOS.

Загрузчик обеспечивает загрузку ОС и сервисные функции, такие, как:

Таким образом, с точки зрения разработчика изделия запуск ОС выглядит следующим образом:

Здесь знаком // отмечен момент подачи питания или сброса процессора. Такой простой способ запуска был у некоторых процессоров ARM7. В последовавших за ними версиях процесс запуска в реальности сложнее, чем на приведенной схеме, но для разработчика конечного решения это обычно не существенно.

Схема “Загрузчик-ОС” очень удобна из практических соображений, ведь загрузчик берет на себя всю низкоуровневую работу:

В то же время, загрузчик зачастую слабо защищен или не защищен вовсе. В большинстве домашних роутеров достаточно открыть крышку и подключиться к разъему UART, чтобы войти в меню управления загрузчиком. В телекоммуникационном оборудовании более высокого класса вход в меню загрузчика зачастую возможен по недокументированной комбинации клавиш или нажатой кнопке в момент включения устройства. Иными словами, зачастую загрузчик не защищен от локального нарушителя.

Рассмотрим работу загрузчика на примере u-boot, загружающего Linux, по шагам.

Запуск загрузчика – предзагрузчик

Однако в реальности почти никогда не бывает, чтобы команды загрузчика выполнялись первыми после включения или сброса процессора. Это еще было на процессорах ARM7, но почти не встречалось далее.

Любое ядро процессора ARM при сбросе начинает исполнение с адреса 0, где записан вектор “reset”. Старые серии процессоров буквально начинали загружаться с внешней памяти, отображенной по нулевому адресу, и тогда первая команда процессора была командной загрузчика. Однако для такой загрузки подходит только параллельная NOR Flash или ROM. Эти типы памяти работают очень просто – при подаче адреса они выдают данные. Характерный пример параллельной NOR Flash – микросхема BIOS в персональных компьютерах.

В современных системах используются другие виды памяти, потому что они дешевле, а объем больше. Это NAND, eMMC, SPI/QSPI Flash. Эти типы памяти уже не работают по принципу: подал адрес — читаешь данные, а значит, для прямого исполнения команд из них не подходят. Даже для простого чтения тут требуется написать драйвер, и мы имеем проблему «курицы и яйца»: драйвер нужно откуда-то заранее загрузить.

По этой причине в современные процессоры ARM интегрировано ПЗУ с предзагрузчиком. ПЗУ отображено в памяти процессора на адрес 0, и именно с него начинает исполнение команд процессор.

В задачи предзагрузчика входят следующие:

Подобный предзагрузчик устанавливается как в процессорах ARM, таких, как Cortex-A, так и в микроконтроллерах, даже таких маленьких, как Cortex-M0. Вместе с предзагрузчиком процедура запуска ОС выглядит так:

Анализ угроз на этом этапе

Исходный код предзагрузчика пишется производителем процессора, а не компанией ARM, является частью микросхемы как продукта компании-производителя и защищен авторским правом. Например, в процессорах ARM компаний Atmel и NXP предзагрузчики написаны, соответственно, Atmel и NXP.

В некоторых случаях предзагрузчик можно прочитать из ROM и проанализировать, но иногда доступ к нему ограничен. Например, предзагрузчик процессора серии Psoc4000 компании Cypress был закрыт несколькими слоями защиты (но был взломан талантливым хакером).

Использования предзагрузчика в большинстве сценариев избежать нельзя. Можно рассматривать его как вариант BIOS, которого в ARM-системах нет.

Сам по себе предзагрузчик в ROM несет в себе угрозу нарушения порядка загрузки и выполнения произвольного кода. Но после того как управление передано загрузчику ОС, предзагрузчик уже безвреден. Мы можем просто не передавать ему управление, перенастроить все обработчики прерываний и так далее.

В некоторые небольшие микроконтроллеры производители интегрируют в ROM-библиотеки для работы с периферийными устройствами, которые требуется вызывать на протяжении всей работы микроконтроллера. В этом случае системное ПО (загрузчик и ОС) само периодически передает управление куда-то в область предзагрузчика, и схема передачи управления получается следующей:

Это в общем случае небезопасно, но встречается только в некоторых микроконтроллерах на архитектуре ARM. На таких микроконтроллерах обычно запускаются программы без ОС или малые RTOS, и дизайнер системы может оценить риски.

Загрузка с TrustZone

В процессоры ARM Cortex-A и Cortex-R встраивается технология TrustZone. Эта технология позволяет на аппаратном уровне выделить два режима исполнения: Secure (Безопасный) и Non-Secure (Гостевой).

Эти процессоры в основном нацелены на рынок смартфонов и планшетных компьютеров, и TrustZone используется для создания в режиме Secure доверенной “песочницы” для исполнения кода, связанного с криптографией, DRM, хранением пользовательских данных.

В режиме Secure при этом запускается специальная ОС, называемая в общем случае TEE (Trusted Execution Environment, доверенная среда исполнения), а нормальная ОС, такая, как Linux, Android, iOS, запускается в режиме Non-Secure. При этом права доступа к некоторым устройствам ограничены для нормальной ОС, поэтому ее еще называют гостевой ОС.

Из-за наложенных ограничений гостевая ОС вынуждена время от времени вызывать функции TEE для исполнения некоторых операций. TEE продолжает существовать параллельно с гостевой ОС все время, и гостевая ОС не может ничего с этим поделать.

Например, гостевая ОС использует функции TEE для:

Почему же разработчики систем соглашаются на такой режим функционирования? В процессоры с поддержкой TrustZone встроен и механизм Secure Boot в том или ином виде.

С Secure Boot предзагрузчик проверяет подпись загружаемого образа с помощью прошитого на этапе производства открытого ключа. Таким образом, гарантируется, что загружен будет только подписанный образ. Это функция безопасности.

То есть загрузка ОС становится следующей:

Далее действует лень — c TEE все работает, а без TEE даже не запускается. Разработчики используют SDK с TEE, вызывают закрытый бинарный код из ядра Linux и не волнуются.

Как проверить свой проект на обращения к TrustZone

Может даже показаться, что всей этой TrustZone не существует, по крайней мере, в вашей конкретной разработке. Проверить это совсем несложно.

Дело в том, что все процессоры с TrustZone стартуют в режиме Secure, а только потом переключаются в Normal. Если ваша ОС запущена в режиме Normal, то какая-то Secure OS (TEE) существует в системе и перевела ее в этот режим.

Лакмусовой бумажкой является обращение к TEE для включения кэш-памяти 2-го уровня. По какой-то причине архитектура ARM не позволяет этого делать из Normal World. Поэтому для включения кэша ядру ОС потребуется сделать хоть один вызов к TrustZone. Делается это единственной командой: smc #0, и вы можете поискать ее сами в ядре Linux или Android.

Разумеется, мы и сами поискали, и нашли такие вызовы в коде поддержки ряда процессоров Qualcomm, Samsung, Mediatek, Rockchip, Spreadtrum, HiSilicon, Broadcom, Cavium.

Загрузка ARM Cortex-A и анализ угроз

На схеме пунктиром обозначен путь обращения из ядра ОС в TEE.

В двух блоках — неизвестный нам код. Посмотрим, чем это грозит.

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

Предзагрузчик работает на самом раннем этапе, когда схема подключения к процессору различных периферийных устройств еще не известна, никакие коммуникационные устройства (WiFi, 3G и т.д.) не настроены, коммуникационные протоколы не работают. При этом предзагрузчик – небольшая программа, с размером кода порядка нескольких десятков килобайт, и сложно представить размещение в нем полных стеков протоколов или серьезной эвристики по определению подключенных устройств. Поэтому предзагрузчик вряд ли таит в себе серьезные закладки, связанные со слежкой, передачей данных и т.п.

Гораздо более интересной точкой атаки является TEE, так как его функции вызываются в процессе работы ОС, когда все периферийные устройства работают, а коммуникационные протоколы настроены. Создание шпионской закладки в коде TEE позволяет практически неограниченно следить за пользователем СВТ.

В небольшом исследовании мы показали реализуемость закладки в TEE, незаметно перехватывающей системные вызовы ОС Linux. Для активации закладки нужно только одно обращение из ядра Linux в TEE (например, то самое, для кэша второго уровня), после чего система становится полностью управляемой. Это позволяет:

Выводы

Мы рассмотрели процесс загрузки различных микроконтроллеров и процессоров ARM.

У микроконтроллеров наиболее уязвимым местом в процессе загрузки является загрузчик ОС.

Современные процессоры ARM Cortex-A включают в себя TrustZone — и от этого никуда не уйти. TrustZone предполагает запуск перед ОС доверенной среды исполнения TEE.

TEE является самой уязвимой точкой в процессе загрузки ОС на ARM Cortex-A, потому что обращения к TEE приводят к выполнению закрытого системного кода, известного производителю, но скрытого от нас.

Без контроля над TEE невозможно обеспечить безопасность и доверенность исполнения любой ОС на ARM Cortex-A.

Источник

Заводим GNU/Linux на ARM-плате с нуля (на примере Kali и iMX.6)

Если вы покупали какой-нибудь не очень популярный одноплатник, то могли столкнуться с отсутствием для него образа любимого дистрибутива. Приблизительно то же самое случилось с планируемым Flipper One. Kali Linux под IMX6 просто нету (я готовлю), поэтому собирать приходится самостоятельно.

Процесс загрузки достаточно простой:

Сборка корневой файловой системы

LABEL=ROOTFS / auto errors=remount-ro 0 1
LABEL=BOOT /boot auto defaults 0 0

Наконец, можно примонтировать загрузочный раздел, он нам понадобится для ядра: `mount /dev/mmcblk0p1 /mnt/boot/`

Сборка Linux

Das U-Boot

Так как загрузчик интерактивный, для проверки его работы достаточно самой платы, запоминающего устройства и опционально устройства USB-to-UART. То есть, можно ядро и ОС отложить на потом.

Абсолютное большинство производителей предлагают использовать Das U-Boot для первичной загрузки. Полноценная поддержка обычно обеспечивается в собственном форке, но и в апстрим контрибьютить не забывают. В моём случае плата поддерживается в мейнлайне, поэтому форк я проигнорировал.

Cобираем сам загрузчик:

Готово, можно загрузиться. Загрузчик должен сообщить собственную версию, некоторую информацию о плате и попытаться найти образ ядра на разделе. В случае неудачи будет пытаться загрузиться по сети. В целом вывод довольно подробный, можно найти ошибку в случае проблемы.

Вместо заключения

А вы знали, что лоб у дельфина не костистый? Это буквально третий глаз, жировая линза для эхолокации!

Источник

Embedded Linux в двух словах. Первое

В этой небольшой серии статей я попытаюсь пролить свет на тему построения Embedded Linux устройств, начиная от сборки загрузчика и до написания драйвера под отдельно разработанный внешний модуль с автоматизацией всех промежуточных процессов.

Платформой послужит плата BeagleBone Black с процессором производства Техасских Инструментов AM3358 и ядром Arm Cortex-A8, и, чтобы не плодить мигающие светодиодами мануалы, основной задачей устройства будет отправка смайлов в топовый чат, широко известного в узких кругах, сайта, в соответствии с командами от смайл-пульта. Впрочем, без мигания светодиодами тоже не обошлось.

Топовые чаты, пульты и светодиоды будут позже, а сейчас на плату подается питание и плата отвечает CCCCCCCCCCC

В переводе с бутлоадерского это означает, что первичному загрузчику, зашитому в ROM процессора, нечего загружать. Ситуацию проясняет Reference Manual, где на странице 5025 в разделе 26.1.5 описана процедура начальной загрузки. Процедура такая: первичный загрузчик проводит некоторую инициализацию: тактирование процессора, необходимой периферии, того же UART, и, в зависимости от логических уровней на выводах SYSBOOT, строит приоритетный список источников где можно взять следующий загрузчик, т.е. посмотреть сначала на MMC карте, SPI-EEPROM или сразу ждать данных по Ethernet.

Я использую способ загрузки с помощью SD карты, вот что говорит об этом раздел RM 26.1.8.5.5 на странице 5057: первичный загрузчик сначала проверяет несколько адресов 0x0/ 0x20000/ 0x40000/ 0x60000 на наличие так называемой TOC структуры, по которой он может определить загрузочный код, если так код не найти, то первичный загрузчик, предполагая на SD карте наличие файловой системы FAT, будет искать там файл с названием MLO, как это расшифровывается в RM не сказано, но многие склоняются что Master LOader. Возникает резонный вопрос, где же взять этот MLO?

Das U-Boot

Перед скачиванием U-Boot, стоит сходить в репозиторий и найти тег последней версии, далее

U-Boot содержит больше тысячи конфигураций, в том числе нужную:

Это конфигурация платы AM335x evaluation module, этот модуль лежит в основе других плат, в том числе BeagleBone Black, что можно видеть, к примеру, по Device Tree, но о нем позже. Настраивается и собирается U-Boot с помощью Kconfig, то же, что используется и при сборке ядра Linux.

Установка нужного конфига:

Можно, к примеру, убрать, установленную по умолчанию, 2-х секундную задержку при загрузке платы с U-Boot

В вышеуказанных командах, используется компилятор по умолчанию, если таковой в системе установлен, и, скорее всего, он не подходит для ARM процессоров, и здесь пора упомянуть о кросскомпиляции.

ARM Toolchain

Один из видов кросскомпиляции это сборка на одной архитектуре, как правило x86-64, именуемой HOST, исходного кода для другой, именуемой TARGET. Например, для TARGET архитектуры ARMv7-A, ядра ARM CortexA-8 процессора AM3358, платы BeagleBone Black. К слову, чтобы не запутаться в ARM’ах, даже есть свой справочник, так их много и разных.

Теперь для успешной сборки U-Boot, нужно указать в переменных ARCH и CROSS_COMPILE требуемые архитектуру и путь к кросскомпилятору соответственно, например так

После сборки U-Boot, в папке появятся необходимые файлы, а именно

Для успешной загрузки с SD карты, нужно ее некоторым образом разметить. Карта должна содержать минимум два раздела, первый, отмеченный как BOOT, с файловой системой FAT, второй раздел с ext4. Разметить карту можно, к примеру, программой fdisk.

Теперь нужно просто скопировать результаты сборки U-Boot в FAT раздел, вставить карту в BeagleBone Black и в терминале наблюдать уже более осознанный ответ платы

В ответе платы есть такие строки

Failed to load ‘boot.scr’

Failed to load ‘uEnv.txt’

U-Boot, во время загрузки, смотрит наличие дополнительных команд, сначала в файле boot.scr, при его наличии, затем, если boot.scr не нашлось, в uEnv.txt. Эти файлы, помимо очередности при поиске, отличаются тем, что в файле uEnv.txt, дополнительные команды представлены в текстовом виде, т.е. он проще для восприятия и редактирования. U-Boot не создает файлы с дополнительными командами, делать это нужно самостоятельно.

Ядро Linux

Прежде чем приступать к любым действиям с ядром, стоит заглянуть сюда и убедится в наличии необходимых пакетов. Следующим шагом нужно определиться с тем, какую версию ядра использовать. Здесь я использую версию 5.4.92 и вот по каким соображениям. Одной из основных причин того, что не стоит брать просто последнюю версию ядра, доступную на данный момент, наряду с наличием драйверов, является невозможность быстро протестировать это ядро на всем разнообразии платформ поддерживаемых Linux, а значит можно потратить кучу сил и времени на исправление неполадок, если что-то пойдет не так, и не факт что это вообще получится сделать. BeagleBone Black имеет официальный репозиторий, где можно найти версию ядра, протестированную на данной платформе, и long term версия 5.4.92 была последней на тот момент.

Сам конфиг пока остается без изменений, поэтому можно просто его установить и запустить компиляцию ядра(zImage), модулей(modules) и дерева устройств(dtbs)

Проходит некоторое время.

Результат сборки, в виде zImage, находится в /arch/arm/boot, там же в папке /dts находится скомпилированное дерево устройств am335x-boneblack.dtb, оба отправляются на SD карту к файлам загрузчика. На этом FAT раздел SD карты можно считать скомплектованным. Итого, там присутствуют:

Еще при сборке ядра заказывались модули ядра, но они уже относятся к корневой файловой системе.

Корневая файловая система. BusyBox

Ядро получает корневую файловую систему путем монтирования блочного устройства, заданного в, переданном при запуске ядра, аргументе root=, и далее, первым делом, исполняет оттуда программу под названием init.

Если запустить BeagleBone Black, имея только вышеуказанные файлы для FAT раздела, то ядро будет паниковать по причине отсутствия init и, в целом, по причине пустой rootfs, т.е. корневой файловой системы.

Можно шаг за шагом создать все минимально необходимые компоненты корневой файловой системы, такие как оболочка, различные демоны запускаемые init, сам init, конфигурационные файлы, узлы устройств, псевдофайловые системы /proc и /sys и просто системные приложения. Для желающих совершать подобные подвиги, существует проект Linux From Scratch, здесь же я воспользуюсь швейцарским ножом встроенных систем с Linux, утилитой BusyBox.

Скачивание последней, на тот момент, версии:

Настройка конфигурации по умолчанию:

Чтобы не думать сейчас о разделяемых библиотеках, стоит установить статическую сборку BusyBox:

Установка в папку по умолчанию _install:

Теперь в папке _install можно видеть будущую корневую файловую систему, в которую нужно добавить некоторые вещи.

Папки, помимо созданных BusyBox:

Стартовый скрипт. Дело в том, что, запускаемая в первую очередь, программа init, делает много полезного, например, выводит в консоль приглашение, но до выдачи приглашения, init проверяет наличие стартового скрипта /etc/init.d/rcS, и, при наличии, запускает его.

Этот скрипт монтирует псевдофайловые системы proc и sysfs, и ничего не мешает ему запускать, к примеру, пользовательскую программу, отвечающую за функционал устройства, но лучше будет делать это в отдельных скриптах, скомпонованных по функциональному назначению.

Стоит сказать, что работа init, на самом деле, начинается с чтения конфигурационного файла /etc/inittab, но BusyBox’овская init включает таблицу inittab по умолчанию, если таковой не окажется в корневой файловой системе.

Теперь пора вспомнить про модули ядра. Их также нужно разместить в корневой файловой системе в /lib/modules/5.4.92/, но сейчас они разбросаны по всей папке в которой собиралось ядро. Чтобы собрать модули в кучу, нужно в папке с ядром выполнить

Где в INSTALL_MOD_PATH указать путь к папке с корневой файловой системой, кросскомпилятор указывать не нужно, т.к. здесь модули ядра просто копируются по месту назначения. В результате папка /lib корневой файловой системы пополнится разделом /lib/mudules/5.4.92/ содержащим модули ядра, полученные при компиляции ядра.

Осталось скопировать все содержимое папки _install во второй раздел SD карты, тот который с ext4, и поменять владельца всего содержимого на root.

После запуска BeagleBone Black с корневой файловой системой, через 1.910315 секунды после старта ядра, система предложит активировать консоль и начать работу.

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

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

Источник