Dtb img что это
[Инструкции] Что такое загрузчик [Продолжение]
Всем привет, с вами как всегда  |
avatar.png (23.52 KB, Downloads: 81)
2020-02-27 07:16:12 Upload
avatar.png (88.29 KB, Downloads: 73)
2020-02-27 07:17:17 Upload
На самом деле, по моими изучениями, это не программа, а программатор (для накопителей eMMC) и образ (для накопителей UFS)
• Накопители eMMC
Для данных накопителей, Fastboot, или загрузчик (объясняю так, чтоб вы поняли) является программатором, под названием appsboot.mbn, а на самом деле, этот Fastboot, называется ABOOT, или ABL, или Android Bootloader, который адаптируется, в зависимости от того, какие команды получает от PBL=Основной загрузчик (О нём попозже), то есть, если мы выполняем команду входа в Fastboot, тогда, Основной загрузчик, отправляет команду в форме кодовых блоков, к Вторичным загрузчикам (SBL) в зависимости от производителя, может быть или один, или два, или три, или четыре вторичных загрузчика, которые отправляют дальше команду к ABL. Но, ирония судьбы, в том что эти Вторичные Загрузчики, запакованы в один программатор, под названием sbl.mbn. На Xiaomi, их два в каждой прошивке, в одном программаторе, под названием sbl2.mbn Далее, ABL, принимает команду, в кодовые блоки и заходит в Fastboot.
Но, если мы выполняем Запуск телефона, тогда, получается очень интересная схема:
PBL, всегда стоит на готове, для выполнения команд, даже если телефон выключен. При нажатии кнопки питания, выполняется команда запуска, тоже в кодовые блоки. При этом, PBL дает команду запуска, далее, команду принимает программатор SBL, который разделяется по двум загрузчикам: один для подтверждения команд, второй, для выполнения и отправки команд дальше, потом, команду, принимает ABOOT, или ABL, затем ABL принимает команду, считает её, подтверждает её и отправляет к ядру Kernel, который проверяет, подтверждает и запускает распаковку RAM диска, после чего, RAM диск, выполняет инициализацию раздела DATA, который, в свою очередь, выполняет запуск Android.
• Накопители UFS
Для обычного запуска смартфона, PBL, даёт команду образу XBL, который, проверяет, выполняет и передает команду запуска к образу ABL, который, проверяет, выполняет и передает команду запуска, ядром Kernel, который, выполняет запуск образа DTBO, или Data Bootloader (загрузчик образа User Data/Раздел DATA), который, выполняет распаковку RAM Диск, далее, RAM диск, выполняет команду инициализации раздела Data, далее, производится запуск Android.
2. Почему производитель блокирует загрузчик
Производитель, блокирует загрузчик, с целью защиты телефона, от кражи или от утечек, Ваших данных, при этом, есть ещё одна причина-если не знаешь, не надо лезть, в корень прошивки, так как прошивка сделана, под директории Linux, а данная директория, очень сложная, для рядового пользователя, но, если вы Техноманьяк, вроде меня, пожалуйста, ковыряйтесь в прошивке, но производитель, не несёт ответственности, после чего, вы разблокировали загрузчик.
3. Как проходит разблокировка загрузчика на Xiaomi
Конечно, изначально, Вы должны входить под Вашем Именем в ваш Mi Аккаунт, как на телефоне, так и в утилите Mi Unlock. Потом, вводите смартфон в Fastboot и подключайте его к ПК, далее, вы кликните по кнопке Unlock и ждете, но за кулисами, происходит, данный процесс:
Изначально, проверяется какое у вас устройство, выполняются команды:
fastboot getvar product
fastboot getvar soc-id
fastboot getvar soc_id
fastboot getvar board_version
После чего проверяется, статус загрузчика (Разлочен/блокирован) выполняется одну из команд:
fastboot oem LKS или
fastboot oem device-info
Если загрузчик блокирован, тогда, утилита, получает и отправляет регистрационный код=токен, затем, проверяется если данный токен, регистрирован в Mi Аккаунт, на серверях Xiaomi. Если токен не зарегистрирован в ваш Mi Аккаунт, тогда, вам придется ждать пока регистрирует токен, потом сможете разлочить сколько раз вы хотите, в день причем. А когда проходит регистрация токена в ваш Mi аккаунт, тогда, сервера Xiaomi, генерируется код разлочки под бинарным фаилом sig.data. Далее, данный фаил шиется в образе ABL, под постоянным регистрацонным кодом, для этого, на ПК, запускается скрипт Fastboot.exe, который разблокирует загрузчик выполняется команда:
fastboot oem unlock, или команды:
fastboot flashing unlock
fastboot flashing unlock critical
После чего утилита проверяет если регистрированный токен совпадает с тем токеном, котооый регистрирован в аккауте. Если совпадают, тогда, происходит разблокировка, если нет, ждем таймер.
Далее, утилита Mi Unlock, получает результаты от устройства и отправляет их не серверах Xiaomi. После чего, перезапускается устройство, выполняется команда:
4. Сколько типов загрузчика есть в прошивке Android. И за чео они отвечают.
Их несколько, давайте я вам их представляю:
•PBL=Primary Bootloader(Основной Загрузчик) Он отвечает за всю прошивку. В прошивке он в форме образа, под названием boot.img, что на накопители eMMC, что на накопители UFS.
•SBL=Secondary Bootloader (вторичный загрузчик) он отвечает за проверку и передачи команд от PBL. Их могут от одного, до четырех загрузчиков, которые запакованы в один программатор, под названием sbl.mbn (на Xiaomi два вторичных загрузчиков: один для проверки и выполнения команд, второй, для передачи команд к ABOOT. Данный программатор, работает только с накопителями eMMC.
•XBL= External Bootloader (Внешний Загрузчик) здесь, чуть по другому, он один проверяет, выполняет и передает команду к ABL. XBL, является образом, под названием xbl.img. данный образ, работает, только с накопителями UFS.
•ABL=ABOOT=Android Bootloader/Fastboot (Загрузчик Android) он отвечает, за запуска рекавери, за запуска системы (через ядро Kernel) за прошивки смартфона. Для накопители eMMC, ок является программатором, под названием appsboot.mbn, а для накопителей UFS, является образом под названием abl.img
•DTBO=Data Bootloader (Загрузчик раздела/образа DATA/userdata.img) он отвечает за запуска раздела/образа данных смартфона, для того, чтоб дальше запустить систему Android. Он является образом под названием dtbo.img.
P.S. Данная тема, является продолжением этой темы
Запуск ОС Андроид с SD-карты для устройств на процессоре Amlogic S912
В статье детально, с приведением исходного кода, описывается работа, проведенная по переносу и запуску с SD-карты программной прошивки с ОС Андроид для устройств на процессоре Amlogic S912.
Мне нравятся миниатюрные компьютеры, выполненные по технологии система на чипе (SOC). За крошечные размеры и небольшое энергопотребление по сравнению с персональными компьютерами. Используя такие устройства, можно решать широкий круг задач. На миникомпьютеры можно установить как ОС Android (так делает большинство производителей данных «игрушек»), так и различные дистрибутивы Linux или Chrome OS.
Моя текущая работа — это разработка приложений для Андроид. В этой работе очень желательны тесты на реальных устройствах на различных версиях системы. Есть у меня пара миникомпьютеров от компаний Rockchip и Amlogic, на которых я также выполняю свои тесты. Андроид, как операционная система, довольно динамично развивается и сейчас на рынке используются ее модификации от 4.4 до 10 версии. А на подходе уже Андроид 11-й версии.
Многие компании, занимающиеся разработкой телеприставок на базе Андроид, вынуждены иметь недолгий срок сопровождения свои детищ в виду быстрого развития как аппаратных, так и программных средств. Один из моих основных рабочих инструментов для тестов — это приставка KM8P на процессоре S912 с двумя гигабайтами ОЗУ и предустановленной операционной системой Андроид версии 7.1. Время идет, и за пару-тройку лет на рынке последовательно появились версии 8.1, 9.0 и 10.0 ОС Андроид.
Очень хотелось бы потестировать свое приложение под этими самыми версиями. Но что делать? Или нужно покупать зверушки на новых процессорах и версиях Андроид, или заниматься самостоятельной адаптацией новых версий Андроида на имеющихся устройствах. Первый путь легок и прост: заплатив не очень большую сумму, проблема легко решается. Но легких путей мы не ищем, поэтому выбираем второй путь. Второй путь гораздо труднее, но интереснее. К тому же, и сам чип S912 является отличным 8-ядерным процессором, не намного уступающим по производительности новейшим процессорам Amlogic на чипе S905x.
Итак, был выбран второй вариант, как более интересный и отвечающий моим потребностям. Встал вопрос: а каким путем пойти? Текущая версия Андроид 7.1 под капотом имеет ядро Linux 3.14.29 и ПЗУ NAND на чипе SK Hynix H27UCG8T2ETR, для которого Amlogic разработала собственный драйвер aml_nftl_dev.ko.
Все новейшие версии Андроид базируются на ядре 4.9. И желательно использовать именно его. Однако, политика Amlogic такова, что последние несколько лет SDK Android компания предоставляет только юридическим компаниям, занимающимся производством устройств на базе чипов Amlogic.
Тем не менее, на просторах github’а можно найти исходники ядра 4.9 на основе SDK Android от Amlogic 2017-18 года. Например, git-репозитарий компании Khadas. Однако, дело, в том, что драйвер aml_nftl_dev для версии ядра 4.9 отсутствует. Что делать? Адаптировать данный драйвер для ядра 4.9? Но помимо адаптации драйвера, придется также править так называемое дерево устройств ядра. Это трудный путь.
Множество устройств на процессоре S912 имеет более современное ПЗУ с контроллером EMMC. К счастью, для обладателей таких устройств совсем недавно (в июне-июле 2020 года) появились прошивки на Андроид 9, собранные энтузиастами (ознакомиться можно здесь и здесь). Я не мог воспользоваться данными прошивками в виду отсутствия на моем устройстве чипа EMMC. Однако, прекрасно понимал, что имея на приставке слот для SD-карточки, для работы с которым используется все тот же драйвер MMC, что и для работы с микросхемой EMMC, можно попытаться использовать SD-карту вместо ПЗУ.
К сожалению, ситуация осложнялась тем, что Amlogic изначально не предусмотрел старт системы с SD-карты. Тем не менее, кое-что было. Amlogic реализовала возможность обновления прошивок с SD-карты. Эта и другие возможности были достигнуты компанией Amlogic путем существенной доработки загрузчика u-boot под свои нужды. В частности, имеется возможность запустить ядро системы с FAT-раздела SD-карты. Итак, было принято решение выяснить, можно ли адаптировать драйвер MMC для возможности старта с SD-карты. Я погрузился в изучение исходного кода драйвера.
Изучая исходный код, я выяснил, во-первых, что драйвер для монтирования загрузочного раздела ограничивается работой только с микросхемой EMMC, а остальные устройства игнорирует. А такими устройствами как раз является SDMMC-слот и SDIO-порт. А почему бы не изменить код так, чтобы драйвер не пропускал устройство SDMMC, а продолжал бы с ним работать, как с EMMC?
Во-вторых, было определено, что разработчики Amlogic используют собственную структуру данных для хранения таблицы разделов диска и записывают ее по некоторому смещению на диске. Структура данных несложная, в ней хранится смещение, имя, размер и некоторые другие характеристики раздела. После определения типа устройства, драйвер читает таблицу разделов на диске и создает блочные устройства в системе согласно этой таблице.
Получается, что разрешив драйверу работать с SDMMC, как с EMMC и записав таблицу разделов по заранее известному адресу на SD-карте, я смогу, таким образом, сымитировать EMMC и загрузить систему с SD-карты! Подумал, почему бы не сделать утилиту, которая будет записывать таблицу разделов в нужном формате и при необходимости проверять ее корректность. Сказано — сделано. Тем более, что сделать ее было несложно, благо практически вся инфраструктура уже была описана в исходном коде драйвера. Исходный код утилиты размещен на github’е, репозиторий amlpt. Утилита создана в ОС Ubuntu. Но, думаю, при необходимости, ее не сложно будет перенести и на Windows.
Для начала нужно заполнить параметры таблицы разделов в файле mmcparts_a9.c, указав там имена, смещения, размеры и тип разделов. Для обычных разделов указывается тип — 0x1, для разделов типа cache — 0x2, а для разделов типа data — 0x4. За начальное смещение первого раздела я взял значение 0x2800000 (40Мб). Далее заполнил имена, размеры и типы разделов в структурах partitions согласно таблице разделов из дерева устройств. Для 9-го Андроида таких разделов насчиталось 17.
Заполнив данные в файле mmcparts_a9.c, создаем утилиту для записи таблицы разделов, запустив скрипт make_amlptwrt.sh. Данный скрипт создает исполняемый файл amlptwrt, с помощью которого можно сформировать двоичный файл mmc_parts.bin. Это и есть наша таблица разделов, которую читает драйвер MMC. Аналогично запускаем скрипт make_amlptrdr.sh для создания утилиты чтения таблицы разделов amlptrdr, с помощью которой мы можем проверить правильность заполнения данной таблицы. После запуска amlptrdr в консоли отобразится таблица разделов с именами, смещениями и размерами в мегабайтах. Примерно так:
Для того, чтобы драйвер MMC заработал с устройством SDMMC, я внес два небольших исправления в исходный код драйвера, в файл drivers/amlogic/mmc/emmc_partitions.c:
а) Во-первых, разрешаем драйверу работать с устройствами, отличными от EMMC. Для этого меняем функцию is_card_emmc следующим образом:
Конечно, это самое никчемное изменение, которое можно было придумать, но для достижения моей цели этого достаточно. Как говорится, матушка-лень впереди планеты всей.
б) Определяем смещение, по которому будет читаться таблица разделов. Правку делаем в функции mmc_read_partition_tbl:
Если посмотрим на исходный код драйвера, то сумма констант MMC_BOOT_PARTITION_SIZE + MMC_BOOT_PARTITION_RESERVED равна 36 Мб. Следует отметить, что данные правки подходят для моего варианта, когда в устройстве отсутствует чип EMMC или в дереве устройств он отключен. Для других случаев придется придумывать более корректный вариант правок.
Итак, смещение, по которому будет записана таблица разделов на SD-карте равна 36 Мб. Для того, чтобы разместить нашу таблицу разделов, созданную утилитой amlptwrt, на SD-карте достаточно выполнить команду:
При этом предполагается, что /dev/sdb — это SD-карта.
Далее компилируем ядро, создаем boot.img с нулевым initrd и примерно такими параметрами ядра:
Вспомним, что u-boot от Amlogic умеет стартовать ядро Linux c SD-карты с раздела FAT. Создаем на SD-карте в самом начале раздел FAT размером 32 Мб. Этого вполне достаточно для размещения нашего boot.img и dtb.img. В дереве устройств dtb.img необходимо отключить EMMC, чтобы нашей SD-карте было присвоено имя /dev/mmcblk0. Или не отключать, но тогда нужно будет изменить в boot.img параметры ядра, чтобы ядро смогло успешно подключить системный раздел, который в данном случае будет иметь имя /dev/mmcblk0p14.
И, как заключительная часть марлезонского балета, осталось записать разделы Андроид-прошивки на SD-карту. Для этого распаковываем прошивку и записываем на SD-карту подходящие разделы согласно смещениям в таблице разделов:
Те разделы, которые отсутствуют в прошивке, я просто заполнял нулями. Некоторые разделы, такие как system или vendor и некоторые другие, могут являться sparse-разделами. Их предварительно необходимо преобразовать в обычные разделы:
С разделами cache и data нужно поступить немного по-другому. Смотрим нашу таблицу разделов, созданную утилитой amlptwrt, и с помощью программы fdisk создаем соответствующие разделы с нужными смещениями и размерами на SD-карте и форматируем их в файловую систему ext4:
После форматирования, с помощью той же утилиты fdisk, удаляем уже ненужные разделы /dev/sdb2 и /dev/sdb3.
Чтобы загрузчик u-boot распознал, что нужно загрузиться именно с SD-карты, размещаем в FAT-разделе файл aml_autoscript. Сам файл aml_autoscript может быть создан с помощью утилиты mkimage из простого текстового файла следующего содержания:
Вот и все, что необходимо для переноса прошивки с Андроид на борту на SD-карту.
Несколько прошивок, которые были сделаны по данному методу, опубликованы в соответствующей теме на форуме 4PDA. Если что-то непонятно, задавайте вопросы в комментариях. Чем смогу — помогу.
За сим позвольте откланяться и удачи всем в переносе прошивок!
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 процессорами, построение системы может сильно отличаться. Например, на малинке, вообще сначала стартует графический процессор, который затем запускает все остальное.
По поводу же заявленных в начале драйверов, взаимодействия с внешними устройствами, автоматизации сборки и некоторого полезного функционала, пойдет рассказ в следующей статье.