Зачастую в процессе разработки собственных устройств или моддинга уже существующих, встаёт задача выполнения стороннего кода: будь то ваши собственные программы с SD-флэшек, или программы, написанные другими пользователями с помощью SDK для вашего устройства. Тема компиляторов и кодогенерации достаточно сложная: чтобы просто загрузить ELF или EXE (PE) программу, вам нужно досконально разбираться в особенностях вашей архитектуры: что такое ABI, релокации, GOT, отличие -fPIE от -fPIC, как писать скрипты для ld и т. п. Недавно я копал SDK для первых версий Symbian и основываясь на решениях из этой ОС понял, каким образом можно сделать крайне «дешевую» загрузку любого нативного кода практически на любом микроконтроллере, совершенно не вникая в особенности кодогенерации под неё! Сегодня мы с вами: узнаем, что происходит в процессе загрузки программы ядром Linux, рассмотрим концепцию, предложенную Symbian Foundation и реализуем её на практике для относительно малоизвестной архитектуры — XTensa (хотя она используется в ESP32, детали её реализации «под капотом» для многих остаются загадкой). Интересно? Тогда добро пожаловать под кат!

❯ Как это работает?

Думаю, для многих моих читателей реализация процесса загрузки exe-программ и dll-библиотек в память процесса оставалась эдаким чёрным ящиком, в детали реализации которого вдаваться не нужно. Отчасти это так и есть: современные ОС разруливают процесс загрузки бинарников в память сами, не требуя от программиста вообще ничего, даже понимания того, куда будет загружена его библиотека или программа.

Давайте для общего понимания вкратце разберемся, как происходит загрузка программ в Windows/Linux:

1. Система создаёт процесс и загружает в память программы секции из ELF/PE. Обычные программы для своей работы используют 3 секции: .text (код), .data (не-инициализированный сегмент памяти для глобальных переменных), .bss (сегмент памяти для инициализированных переменных). Каждому процессу выделяется собственное адресное пространство, называемое виртуальной памятью, которое не позволяет программе испортить память ядра, а также позволяет не зависеть от разметки физической памяти на выполняющей машине. Концепцию виртуальной памяти реализует специальной модуль в процессоре, называемый MMU.

2. Если бы наши программы не использовали никаких зависимостей в виде динамических библиотек, то на этом процесс загрузки можно было бы закончить: каждая программа имеет свой адрес загрузки, относительно которого линкер строит связи между обращениями к коду/данным программы. Фактически, для самых простых программ линкеру остаётся лишь прибавить адрес загрузки программы (например, 0x100) к каждому абсолютному обращению к памяти.
Однако современные программы используют десятки библиотек и для всех предусмотреть собственный адрес загрузки не получится: кто-то где-то всё равно будет пересекаться и вероятно, портить память. Кроме того, современные стандарты безопасности в Linux рекомендуют использовать позиционно-независимый код, дабы использовать преимущества ASLR (Address Space Layout Randomization, или простыми словами возможность загрузить программу в случайное место в памяти, дабы некоторые уязвимости, завязанные на фиксированном адресе загрузки программы перестали работать).

3. Поэтому для решения этой проблемы придуман т. н. динамический линкер, который уже на этапе загрузки программы или библиотеки патчит программу так, чтобы её можно было загрузить в любой участок памяти. Для этого используются данные, полученные от обычного линкера а этапе компиляции программы: помимо .text, .data и .bss, линкер создаёт секции .rel и .rel-plt, которые называются релокациями. Если объяснять совсем условно, то релокации — это просто запись вида «какой абсолютный адрес в коде программы нужно пропатчить» -> «на какое смещение его пропатчить». Самая простая релокация выглядит вот так:

Где по итогу:

.rel-plt же служит для резолвинга вызовов к dll/so: изначально программа ссылается на заранее определенные в процессе компиляции символы, которые уже в процессе загрузки патчатся на физические адреса функций из загруженной библиотеки.

И казалось бы — всё очень просто, пока в дело не вступают GOT (Global Offset Table — глобальная таблица смещений) и особенности реализации конкретного ABI. И ладно бы x86 или ARM, там всё разжевано и понятно, однако на других архитектурах начинаются проблемы и не всегда очевидно что и где за что отвечает.

А ведь чаще всего нужно просто загрузить небольшую программу, которой не нужны комплексные загрузчики: немного кода, немного данных и всё. И тут у нас есть три выхода:

1. Писать полноценный загрузчик ELF-бинарников. ELF может оказаться громоздким для некоторых окружений и его реализация может оказаться тривиальной не для всех.

2. Зарезервировать определенный сегмент в памяти (пусть с 0xFFF по 0xFFFF) и скомпилировать нашу программу с адресом загрузки 0xFFF с параметром -fno-pic. В таком случае, линкер сгенерирует обращения к памяти по абсолютным адресам — если переменная лежит по адресу 0xFFF, то программа будет обращаться сразу к этому адресу памяти, без необходимости что либо динамически линковать. Именно такой подход использовался во времена ZX Spectrum, Commodore 64 и MS-DOS (однако там роль «виртуальной памяти» выполняла такая особенность 8086, как сегменты). У такого подхода есть и минусы: относительная невозможность загрузки сразу нескольких программ одновременно, зарезервированное пространство линейно отъест небольшой кусок памяти у основной прошивки, нет возможности динамической аллокации секций. Зато такой код теоретически будет работать быстрее, чем PIC.
   
   Проблемы реализации такого способа: иногда нужно лезть в систему сборки основной прошивки и патчить скрипт линкера так, чтобы он не трогал определенный регион памяти. В случае esp32, например, это требует патча в сам SDK и возможного «откола» от мейнлайн дистрибутива.

3. Использовать программу с относительной адресацией, однако без сегментов .bss и .data. Самый простой в реализации способ, который к тому же очень экономичен к памяти, позволяет загружать программу в любое место и пользоваться всеми фишками динамического аллокатора и не требует вмешательств в основную прошивку, кроме примитивного загрузчика программ. Именно его я и предлагаю рассмотреть подробнее.

Недавно мы сидели в чате ELF-сцены (разработка нативных программ под телефоны Siemens, Sony Ericsson, Motorola и LG с помощью хаков) и думали, как же можно реализовать загрузчик сторонних программ на практически неизвестных платформах. Кто-то предлагал взять ELF под основу — однако с его реализацией под некоторые платформы есть трудности, а кто-то предлагал писать «бинлоадер» — самопальный формат бинарников, который получается из, например, тех же эльфов.

В это же время я копал SDK для Symbian и хорошо помнил, что в прикладных приложениях для этой ОС нет поддержки глобальных переменных вообще. Да, сегмент .data и .bss полностью отсутствует — переменные предлагается хранить в структурах. Почему так сделано? Всё дело в том, что каждая программа в Symbian — это dll-библиотека, которую загружает EKA и создаёт экземпляр CApaApplication. И дабы была возможность загрузить dll один раз для всех программ (что справедливо для системных библиотек), ребята полностью выкинули возможность использования любых глобальных переменных. А ведь идея интересная!

Однако в таком подходе есть несколько серьезных ограничений:

• Отсутствие глобальных переменных может стать проблемой при портированиии уже существующего софта, хотя вашим программам ничего не мешает передавать в каждую функцию структуру с глобальным стейтом, который можно при необходимости изменять. Кроме того, нет ограничений на использование C++ (за исключением необходимости ручной реализации new/delete и отсутствием исключений).

• Отсутствие преинициализированных данных. Вот это уже может стать относительно серьёзной проблемой, у которой, тем не менее, есть свои обходные решения. Например если вы храните команды для инициализации дисплея в таблице, или какие-либо калибровочные данные — вы не сможете их объявить, просто используя инициализаторы в C. Тоже самое касается и строковых литерал. Тут есть два варианта: часть таблиц можно вынести на стек (если эти самые таблицы достаточно маленькие), либо подгружать необходимые данные из бинарника с помощью основной прошивки (например, LoadString и т. п.).

Давайте же на практике посмотрим, имеет ли право на жизнь такой подход!

❯ Практическая реализация

Формат нашего бинарника будет до безобразия прост: небольшой заголовок в начале файла и просто сырой дамп сегмента .text, который можно экспортировать из полученного elf даже без необходимости писать скрипт для линкера. При этом нужно учесть, что ESP32 — это микроконтроллер частично Гарвардской архитектуры, т. е. шина данных и кода у него расположены отдельно. Однако у чипа есть полноценный MMU, который позволяет маппить регионы физической памяти в виртуальную память, чем мы и воспользуемся в итоге!

Заголовок нашего бинарника будет выглядеть вот так:

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

Концептуально всё очень просто: GetGlobalStateSize сообщает нашему загрузчику размер структуры для хранения глобального стейта, в то время как Start уже фактически заменяет main() в нашей программе. Необходимости в crt0 нет, поскольку весь необходимый инит выполняет бутлоадер ESP32. Впрочем, при желании вы можете выделить отдельный стек для вашей программы — это повысит надежность, если выполняемая программа удумает испортить стек.

Собираем нашу программу:

-fno-pic отключает генерацию кода, зависимого от GOT, -nostdlib и -nostartfiles убирает из билда crt0 и stdlib, благодаря чему мы получаем только необходимый код. --section-start задает смещение для загрузки секции .text на 0x0 (в идеале это делать необходимо из скрипта для ld).
objcopy скопирует из полученного ELF только необходимую нам секцию .text.

Как же это работает на практике? Давайте дизассемблируем выходной бинарник и посмотрим, что у нас дает на выхлопе cc:

Обратите внимание, что Start вызывает подфункции с помощью инструкции CALLX8, которая в отличии от обычного Immediate-версии CALL8, выполняет переход относительно текущего адреса в PC, благодаря чему переход полностью независим от адреса загрузки программы в памяти. А благодаря тому, что все данные, в том числе и указатель на глобальный стейт передаются через стек, нет необходимости релокейтить сегменты данных.

По итогу всё, что нужно от загрузчика бинарников — это загрузить программу в память для инструкций, выделить память для структуры с стейтом программы и передать управление Start. Всё!
Конкретно в случае ESP32, у нас есть два возможных решения задачи загрузки программы в память:

1. Загрузить программу в IRAM. Такая возможность теоретически есть, однако на практике загрузчик ESP32 устанавливает права только на чтение и выполнение на данный регион памяти. Попытка что-то скопировать туда закончится исключением SIGSEGV. Кроме того, сегмент IRAM относительно небольшой — всего около 200Кб.

2. Самопрограммирование. Для этого, в esp32 есть два механизма — Partition API и SPI Flash API. Я выбрал Partition API для простоты реализации.

Для нашей прошивки необходимо будет переразметить флэш-память. Для этого запускаем idf.py menuconfig, идём в Partition Table -> Custom partition table CSV. Создаём в папке проекта partitions.csv, куда пишем:

# ESP-IDF Partition Table
# Name, Type, SubType, Offset, Size, Flags
nvs, data, nvs, 0x9000, 0x6000,
phy_init, data, phy, 0xf000, 0x1000,
factory, app, factory, 0x10000, 1M,
executable, data, undefined, 0x110000, 0x10000

Для заливки программы можно использовать соответствующее Partition API, либо parttool.py:

Переходим к загрузчику программы:

Прошиваем ESP32:

И смотрим результат:

Всё работает!

❯ Заключение

Как видите, ничего сложного в выполнении сторонних программ при условии соблюдении некоторых ограничений нет. Да, в таком подходе есть как серьезные плюсы, так и минусы, однако он делает своё дело и позволяет реализовать запуск игр на кастомных игровых консолях, или сторонних программ на самодельных компьютерах. Ну и конечно же не стоит забывать про плагины! Авось в вашем решении нужна возможность расширения функционала устройства, однако предоставлять исходный код или даже объектные файлы нет возможности — тогда вам может пригодится и такая методика.

Пожалуй, стоит упомянуть ещё один… очень своеобразный метод, который я иногда встречаю при реализации самодельных компьютеров. Люди пишут… эмуляторы 6502/Z80 :)
И если такой подход ещё +- применим к ESP32, то в AVR просадки производительности будут слишком серьезными. Так зачем, если можно использовать все возможности ядра на максимум?

Китайские производители не перестают удивлять: многие видят явные перспективы рынка одноплатных компьютеров и стараются представить целую линейку девайсов на самых разных чипсетах, а разработчики стараются использовать уже привычное и поддерживаемое долгие годы железо. К ним относятся решения на чипсетах AllWinner, RockChip, Tegra. Другие же стараются взять малоизвестный, но дешевый чип для иного круга применений, развести на нем компактную плату и продавать по цене пачки сухарей, подобные решения появляются регулярно. Один из таких одноплатников я недавно купил на AliExpress — некий DongShan Pi Pico W, на базе экзотического чипсета SigmaStar SSD210, всего за 600 рублей. И тут действительно есть на что посмотреть: два ядра Cortex-A7, контроллер TTL матриц, 2D GPU, Wi-Fi, 64Мб ОЗУ и Embedded Linux на борту. Более того, девайс поставляется в виде System on Module с переходной Evaluation-платой, что позволяет использовать это устройство в составе других гаджетов! Что это за красавец и на что он способен? Читайте в статье!!

❯ Что это за девайс?

Думаю, большинство моих читателей когда-либо слышали об одноплатных компьютерах. Это компактные и достаточно мощные устройства, которые можно использовать как в качестве компактных серверов или даже десктопных машин, так и собрать своё устройство на базе готового одноплатного компьютера. Одноплатники используется во многих сферах: вендинговые автоматы, умные экраны, самопальные игровые консоли и смартфоны, DIY-ноутбуки!

Однако чаще всего можно увидеть обзоры и проекты на базе довольно известных устройств: Raspberry Pi, Orange Pi, Olimex. Эти платы, скажем так, достаточно дорогие: и если Orange Pi One/Zero ещё можно ухватить за 1.000 рублей на вторичке (один из таких я купил еще летом. Узнав о моем блоге, продавец стал моим читателем и вместо одного OPi прислал мне целых два — один в подарок!), а за RPi Zero придется выложить как минимум 2.000 рублей. Однако есть ещё один сегмент одноплатных компьютеров: ультра-дешевые, разработанные на базе чипов для конкретного применения. Один из самых известных представителей — MangoPi/CherryPi R3, который работает на базе AllWinner F1C200s — чипа для… электронных книг!

Информации по дешевым, почти неизвестным одноплатникам довольно мало. У них не очень хорошая поддержка (кроме AllWinner, там почти все чипсеты есть в mainline-ветке Linux), в них могут обнаружится аппаратные баги, да и многие люди вообще не замарачиваются с ними, предпочитая переплатить, но купить что-то более стабильное. Но не я! Я просто обожаю различные ультрадешевые девайсики, поэтому недавно по наводке моего активного читателя NutsUnderline, я заказал интереснейший девайс — DongShan Pi Pico-W. Устройство обошлось мне всего в 600 рублей, но в первую очередь, меня привлек форм-фактор устройства и его чипсет. Некий SigmaStar SSD210!

Я заказал сразу два устройства: первую партию очень быстро разобрали, поэтому я взял «с запасом». Сейчас конкретно этот одноплатник пока-что не доступен в магазине продавца, однако у него же продаются другие устройства на базе SSD210. Можете найти их по ключевому слову: «SSD210» (прямые линки публиковать не буду, дабы не сочли за рекламу). Через месяц оба красавца пришли ко мне и я принялся их изучать.

Какое же было моё удивление, когда я обнаружил, что это по сути System on Module, который вручную надо припаять к Evaluation-плате! Вкратце это значит, что на базе таких SoM вы можете развести плату, протравить её, а затем припаять одноплатник поверх нее и сделать своё полноценное устройство, «без соплей»! Производителю плюсик за такую гибкость — я не очень люблю одноплатники с штырьковыми гребенками. Хотя, конечно, это очень сильно помогает при разработке макета устройства.

❯ Характеристики

Но чем он так меня привлек, помимо SoM направленности? Своим крутым чипсетом! Давайте ознакомимся с его характеристиками поближе:

• Процессор: SigmaStar SSD210. 2 ядра Cortex-A7, работающие на частоте до 1ГГц. 16Кб кэш инструкций и 16Кб кэш данных, плюс 128Кб L2-кэша. В процессоре есть FPU и поддержка SIMD-инструкций Neon (альтернатива SSE в x86). Нехило, правда?

• Поддержка дисплеев: У чипсета есть выделенный модуль для работы с внешними матрицами. Поддерживаются TTL дисплеи (до 1024x768), SPI-матрицы с клоком до 54МГц (480x320), а также прямой RGB аналоговый RGB сигнал (этот интерфейс можно использовать для подключения к ТВ с тюльпанами или аналоговым матрицам). Про типы дисплеев, вы можете прочитать в моей статье.

• 2D GPU: Поддержка отрисовки линий, прямоугольников, градиентной заливки, BitBLT, клиппинг, дизеринг, автоматическая конвертация формата пикселя (с RGB888 в RGB565). Это серьёзно снимает нагрузку с ЦПУ при рисовании графики, однако поддерживается ли он в Linux — вопрос другой.

• ОЗУ: 64Мб DDR2 памяти «бутербродом» прямо с чипсетом, плюс поддержка до 512Мб DDR2 внешней памяти, до 1333Мб/с.

• Звук: Один моно-выход DAC, два выходных канала I2S, вход микрофона. Входные каналы поддерживают частоту дискретизации до 96КГц. Можно организовать вывод звука лишь подключив внешний усилитель. Внешний ЦАП не обязателен, если вам не нужен стерео-звук.

• Память: Контроллер NOR/NAND SPI-памяти, до двух параллельно подключенных чипов, плюс поддержка SDIO. BootROM поддерживают загрузку с MicroSD карт.

• Сеть: Ethernet, на DongShan Pi есть Wi-Fi.

• USB: Как хост, так и ведомое устройство

• Периферия: 4 канала ШИМ, GPIO, 4 UART, 2 канала SPI, 2 канала I2C

• Камера: До двух камер по интерфейсу MIPI CSI

• Безопасность: Есть аппаратное шифрование.

• Питание: 0.9В ядро, 1.8В ОЗУ, 3.3В I/O

Очень даже бодро, согласитесь? Вообще, производитель подразумевает SSD210 как чипсет для HMI-дисплеев — т. е. умные дисплеи, которые могут, например, служить стендами в музеях, или служить для заказа билетов в кино. Есть внешние HMI-дисплеи, которыми можно управлять используя другие МК: просто посылая команды и реагируя на нажатия кнопок. Тут мы и видим, как китайский производитель решил применить этот чипсет для другой сферы: одноплатный компьютер для DIY!

На SSD210 есть порт Linux, предлагается использовать Embedded Linux в качестве основной системы. Никаких дистрибутивов по типу Ubuntu для устройства нет — предполагается, что вы сами реализуете весь необходимый для ваших программ функционал (отрисовку графики, обработку ввода, звук и т. п.). Есть Build root и исходный код ядра, а также U-Boot.

Помимо этого, вендор предлагает целое SDK для разработки уже готовых устройств на этом чипсете. Но есть один нюанс: документации практически нет :( Такие пакеты предлагаются крупным коммерческим производителям устройств, поэтому и основная поддержка есть только для них. Есть некоторые сэмплы, как, например, использовать графические дисплеи (показан пример с TTL-матрицей 1024x600), но совершенно не ясно как использовать SPI-матрицы, поскольку они требуют отдельной инициализации.

Но сначала наш одноплатник нужно собрать и запустить. И здесь есть множество тонких моментов, которые необходимо знать перед покупкой такого девайса. Переходим к сборке!

❯ Сборка и запуск

Для более удобного процесса разработки нашего устройства, лучше всего заказывать сразу две платы: одну припаять к переходной плате с штырями, а другую использовать на нашем устройстве. Как я уже говорил ранее, одноплатник предлагается в виде System on Module, которые можно при желании распаять на переходной плате:

Честно сказать, я очень люблю такой тип монтажа и топлю за то, чтобы другие одноплатники не форсировали использование штырьков, а позволяли припаять себя «бутербродом» к другой плате. Обычно SoM дороже чем простые одноплатники, один из примеров — Olimex A20 SoM. Припаиваем основную плату к eval-плате. Обратите внимание, что припой должен находится «скосом» с внешней стороны пинов!

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

Теперь подключаем питание. На плате уже разведены Step-down преобразователи с 5В на 3.3В (основная логика), 1.8В (DDR2), и 0.9В/1.0В (ядро), нам достаточно подключить лишь 5В, либо запитать плату от 3.7В аккумулятора. Устройство стабильно работает и от 0.5А порта ПК (если не юзать Wi-Fi).

Для работы с одноплатником, обязательно нужен COM-преобразователь. Открываем Putty, задаем COM-порт, выставляем бодрейт 115200 и отключаем контроль четности. После подачи питания на устройство, в консоли побегут логи, U-Boot начнет загружать систему… однако, есть один важный нюанс…

Все платы прошиваются на заводе с помощью фирменного флэшера SSD210. Но фирменный флэшер, по каким-то причинам, на некоторых платах не может сохранить U-Boot Environment (переменные окружения, которые в том числе определяют таблицу разделов и коммандлайн ядра).

Поэтому если ваша плата повисла на CRC Error, нужно ввести следующие команды:

setenv mtdids nand0=nand0

setenv mtdparts ' mtdparts=nand0:0x140000(CIS),0x1a0000(BOOT0),0x1a0000(BOOT1),0x40000(ENV),0x40000(ENV1),0x20000(KEY_CUST),0x500000(KERNEL),0x500000(RECOVERY),0x600000(rootfs),0xa0000(MISC),-(UBI)

setenv bootargs ubi.mtd=UBI,0x800 root=/dev/mtdblock8 rootfstype=squashfs ro init=/linuxrc LX_MEM=0x3FE0000 mma_heap=mma_heap_name0,miu=0,sz=0x1E00000 cma=2M highres=off mmap_reserved=fb,miu=0,sz=0x300000,max_start_off=0x3C00000,max_end_off=0x3F00000 ${mtdparts}

setenv bootcmd ' nand read.e 0x22000000 KERNEL ${kernel_file_size}; dcache on ; bootlogo 0 0 0 0; bootm 0x22000000;nand read.e 0x22000000 RECOVERY ${recovery_file_size}; dcache on ; bootm 0x22000000

setenv autoestart 0

setenv sstar_bbm off

setenv ipl_version "##p3##gdf99011IPL_##########

setenv ipl_version "DUALENV=1 SILENT_CONSOLE=1 CFG_SDMMC_DISABLE=n ALK=1 SPINAND=1 CHIP=pioneer3""

saveenv

После этого отправляем плату в ресет и система загружается как ни в чем не бывало!

Поскольку на плате не разведен разъем USB, для прошивки нужно распустить нерабочий кабель для зарядки смартфона, либо купить внешний USB-разъем на плате. VBUS кидаем на вход питания, белый провод на DM-, зелёный на DM+. Не забывайте провести общую землю между UART-преобразователем и основным питанием платы, дабы не потерять логи.

Замыкаем два пина в центре платы пинцетом и жмем RESET. Плата определится как MSDC-флэшка (не удивляйтесь). Прошивальщик глючный и бывает не с первого раза может прошить устройство. Если девайс после прошивки не включается — введите команды в консоль U-Boot выше.

Теперь переходим к самой системе.

❯ Система

Девайс работает на базе ядра Linux 4.9. Тем не менее, производителем заявлена поддержка Mainline-ядра, что даёт надежду на поддержку устройства в будущем.

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

«Из коробки» на устройстве доступен лишь i2cdev, благодаря которому можно свободно общаться с i2c-устройствами из юзерспейса. Хотите получить доступ к SPI? Готовьтесь качать билдрут, вручную включать spidev в конфиге и редактировать DeviceTree, дабы spidev мог получить доступ к физическим spi-устройствам ядра.

Кроме того, конечно же, есть доступ к GPIO из sysfs.

На самой плате, Wi-Fi реализован в виде внешнего USB-хаба + Wi-Fi адаптера. Чипсет также поддерживает Ethernet.

Для разработки устройств, производитель предлагает отдельное SDK для общения с периферией устройства из юзерспейса. С помощью этого SDK, можно получить доступ к камере, аппаратному декодеру, звуку и настроить матрицу. Судя по всему, общение происходит с помощью ioctl к необходимым устройствам. Это сделано для того, чтобы разработчики не копались в низкоуровневых драйверах, ведь например, ALSA, на устройстве нет совсем.

Если включить нужные нам модули в юзерспейс (spidev, i2cdev, gpio), то можно будет проектировать устройства более простым путем. Например, подключить дисплейчик и прямо из юзерспейса выводить на него графическую информацию. Это открывает перспективы для самых разных применений: опрос датчиков и хранение информации в внутренней памяти, умные сигнализации, самодельные часы, DIY игровые консоли, самодельные телефоны и т. п. Применений просто куча!

❯ Заключение

Вот мы и посмотрели с вами на дешевые одноплатники, где используются чипсеты, которые разработаны для использования в совершенно других сферах. Девайсы весьма своеобразные и для полноценной работы с ними нужно обладать навыками прожженного линуксоида и иметь навыки системного программирования. Но, чего уж точно нельзя отрицать, так это перспектив подобных девайсов для своих проектов. Да, под них нет готовых гайдов, как для Raspberry Pi или Orange Pi, информации по ним минимум… но если захочется — то всегда можно «сварганить» самопальное устройство за минимальный прайс!

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

Чуть позже выйдет материал про Repka Pi. Их одноплатник получился не менее интересным и как раз таки метит в нишу одноплатников с хорошей поддержкой, где есть уже готовые гайды, информация и даже сами разработчики могут помочь с решением некоторых проблем. Без косяков не обошлось: есть пару аппаратных проблем, о которых я расскажу открыто, но в целом девайс выглядит интересным!

Материал подготовлен при поддержке TimeWeb Cloud. Подписывайтесь на меня и @Timeweb.Cloud , дабы не пропускать свежие статьи каждую неделю!

• Использование библиотеки Windows.Devices: Эта библиотека предоставляет доступ к различным устройствам, подключенным к компьютеру с операционной системой Windows. Вы можете использовать классы и методы этой библиотеки для работы с устройствами, такими как принтеры, сканеры, камеры и другие.

• Использование библиотеки System.IO.Ports: Если вам нужно работать с устройствами, подключенными через последовательный порт (COM-порт), вы можете использовать классы и методы этой библиотеки. Она позволяет открывать и управлять COM-портами, отправлять и принимать данные.

• Использование API устройства: Некоторые устройства имеют свои собственные API, которые позволяют взаимодействовать с ними через C#. Например, если вы хотите работать с принтером, вы можете использовать API принтера для отправки печатных заданий и получения статуса печати.

• Использование сторонних библиотек: Существуют сторонние библиотеки, которые предоставляют дополнительные функциональные возможности для работы с устройствами через C#. Например, вы можете использовать библиотеку LibUsbDotNet для работы с USB-устройствами.

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

Интересные факты и фичи языков программирования у нас в канале, заходи :)

Для многих разработчиков приложений далеко не секрет, что экосистема Android не предполагает написание полностью нативных приложений: в этой платформе очень многое завязано на Java и без ART можно запустить только простые службы без какого-либо интерфейса. Однако, есть один способ писать практически под «голый» Linux, не перекомпилируя ядро и при этом пользоваться самыми интересными фишками устройства без оверхеда в виде тяжелого Android: ускорение 3D-графики (OpenGLES), микшер звука, ввод с различных устройств, OTG, Wi-Fi и если очень постараться — даже 3G. Это открывает множество разных интересных применений старым устройствам: «железо» смартфонов зачастую гораздо мощнее современных недорогих одноплатников. Сегодня я покажу вам, как написать и запустить программу, которая полностью написанное на C без Android, на No-Name Android-смартфоне практически без модификаций. Интересно? Жду вас в статье!

❯ Что нам нужно знать?

Даже относительно старые устройства флагманского сегмента обладают весьма неплохими характеристиками. Зачастую они гораздо мощнее современных дешевых одноплатников и могут выполнять самые разные задачи: эмуляция консолей, работа в качестве плееров, да даже просто сделать настольные часики самому было бы здорово. Но есть одно но — это Android. Платформа от Google может тормозить даже на достаточно мощном железе, что резко ограничивает потенциально возможные применения подобных гаджетов. Да и многие программисты не особо хотят заморачиваться и учить API Android для реализации каких-то своих проектов.

Но конечно же, есть один способ писать нативные программы, при этом используя все ресурсы смартфона/планшета. Для этого нужно понимание, как работает процесс загрузки на многих Android-гаджетах:

1. Первичный загрузчик (BootROM) инициализирует какую-то часть периферии и загружает вторичный загрузчик (U-boot/LK).

2. Вторичный загрузчик, используя определенные аргументы (например зажата ли какая-то кнопка) выбирает, с какого раздела грузить ядро системы.

3. После загрузки ядра Linux и подключения ramdisk начинается выполнение процессов системы.

Как раз в третьем пункте и лежит ключ к способу, который будем использовать мы. Дело в том, что в смартфоне обычно есть несколько boot-разделов и у каждого свой образ ядра Linux со своим ramdisk. Первый из них — это знакомый моддерамboot.img, который отвечает за загрузку системы и инициализирует железо/монтирует разделы/подготавливает окружение к работе (.rc файлы) и запускает главный процесс Android —zygote. При этом используется собственная реализация init от Android.

Второй, не менее знакомый многим раздел —recovery, отвечает за так называемый режим восстановления, в котором мы можем сбросить данные до заводских настроек/очистить кэши или прошить кастомную прошивку. Вероятно, многие из вас замечали, насколько быстро ваш девайс загружает этот режим, гораздо быстрее, чем загрузка обычного Android. И именно в его реализацию нам нужнозаглянуть(я намеренно выбрал бранч версии 2.3 — т.е Gingerbread для простоты):

А recovery оказывается самой обычной нативной программой, написанной на C со своим небольшим фреймворком для работы с графикой и вводом. В процессе загрузки режима recovery, скрипт запускает одноименную программу в /sbin/, благодаря которому мы видим простую и понятную менюшку. Так почему бы не использовать этот раздел в своих целях и не написать какую-нибудь нативную программу самому?

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

❯ Подготавливаем окружение

В первую очередь, хотелось бы отметить, что программы под «голый» смартфон можно писать не только на C/C++. Нам доступен как минимум FPC, который довольно давно умеет компилировать голые бинарники под Android. Кроме того, мы можем портировать маленькие embedded-версии интерпретаторов таких языков, как lua, micropython и duktape (JS).

Однако в случае нативных программ, есть два важных правила, которые необходимо понимать. Во-первых, в Android используется собственную реализацию стандартной библиотеки libc — bionic, в то время как на десктопных дистрибутивах используется glibc. Между собой они не совместимы — именно поэтому вы не можете просто взять и запустить консольную программу для Raspberry Pi, например.

А второе правило заключается в том, что начиная с версии 4.1, Androidтребует, чтобы все нативные программы были скомпилированы в режиме -fPIE — т. е. выходной код должен не зависеть от адреса загрузки программы в виртуальную память. Для этого достаточно добавить ключ -fPIE, однако учтите, что если вы разрабатываете программу под Android 4.0 и ниже, то fPIE наоборот необходимо убрать — старые версии Androidнеподдерживают такой способ генерации кода и будут вылетать с Segmentation fault.

Для разработки нам понадобится ndk — там есть все необходимые заголовочники и компиляторы для нашей работы. Я используюndk r9c, поскольку в свежих версиях Google регулярно может что-то сломать.
ndk-build, к сожалению, здесь работать не будет, поэтому Makefile придется написать самому. Я составил полностью рабочий Makefile, который без проблем скомпилирует валидную программу, вам остаётся лишь поменять NDK_DIR.

NDK_DIR = D:/android-ndk-r11c/

TOOLCHAIN_DIR = $(NDK_DIR)toolchains/arm-linux-androideabi-4.9/prebuilt/windows-x86_64/bin/

GCC = $(TOOLCHAIN_DIR)arm-linux-androideabi-g++

PLAT_DIR = $(NDK_DIR)platforms/android-17/arch-arm/usr/

LINK_LIBS = -l:libEGL.so -l:libGLESv1_CM.so

OUTPUT_NAME = cmdprog

build:

$(GCC) -I $(PLAT_DIR)include/ -L $(PLAT_DIR)lib/ -fPIE -Wl,-dynamic-linker=/sbin/linker $(LINK_LIBS) -static -o $(OUTPUT_NAME) main.cpp micro2d.cpp

После этого пишем простенькую программу, которая должна вывести «Test» и компилируем её.

❯ Деплоим на устройство

Несмотря на то, что грузиться мы будем в режим recovery, нам всё равно будет доступен adb, через который мы сможем запускать и отлаживать нашу программу. Это очень удобно, однако по умолчанию adb включен только в TWRP, который нужно сначала найти или портировать под ваш девайс (на большинство старых брендовых устройств порты есть, на нонейм придется портировать самому — гайды есть в интернете). Под ваше устройство есть TWRP? Отлично, распаковываете recovery.img с помощью так называемой «кухни» (MTKImgTools как вариант):

Открываете init.recovery.service.rc и убираете оттуда запуск одноименной службы (можно просто оставить файл пустым).

Запаковываем образ обратно тем же MTKImgTools и прошиваем флэшером для вашего устройства — в моём случае, это SP Flash Tool (MediaTek):

Заходим в режим рекавери и видим зависшую заставку устройства и звук подключения устройства к ПК. Если у вас установлены драйвера, то вы сможете без проблем зайти в adb shell и попасть в терминал для управления устройством. Теперь можно закинуть программу — прямо в корень рамдиска (записывается программа в ОЗУ, но при переполнении, телефон уйдет в ребут — осторожнее с этим). Пишем:

adb push cmdprog /: adb shell chmod 777 cmdprog ./cmdprog

И видим результат. Наша программа запускается и работает!

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

❯ Выводим графику

Для вывода графики без оконных систем, мы будем использовать API фреймбуфера Linux, которое позволяет нам получить прямой доступ к массиву пикселей на экране. Однако учтите, что этот способ полностью программный и может оказаться тормозным для вашего приложения: скорость работы прямо-пропорциональна разрешению дисплея вашего устройства. Чем выше разрешение, тем ниже филлрейт. В моём случае, матрица была с разрешением 960x540, 32млн цветов, IPS — очень недурно, согласны?

Фреймбуфер Linux может работать с самыми разными форматами пикселя, имейте это ввиду. На некоторых устройствах может быть 16-битный формат (262 тысячи цветов, RGB565), на моём же оказался 32х-битный с выравниванием по строкам (имейте это также ввиду). 32х битный формат. Работать с ним легко: открываем устройство /dev/graphics/fb0, получаем параметры (разрешение, формат пикселя), делаем mmap для отображения буфера с пикселями на экране в память нашего процесса и выделяем второй буфер для двойной буферизации дабы избежать неприятных мерцаний.

void m2dAllocFrameBuffer()

{

fbDev = open(PRIMARY_FB, O_RDWR);

fb_var_screeninfo vInfo; fb_fix_screeninfo fInfo;

ioctl(fbDev, FBIOGET_VSCREENINFO, &vInfo);

ioctl(fbDev, FBIOGET_FSCREENINFO, &fInfo); fbDesc.width = vInfo.xres;

fbDesc.height = vInfo.yres;

fbDesc.pixels = (unsigned char*)mmap(0, fInfo.smem_len, PROT_WRITE, MAP_SHARED, fbDev, 0); f

bDesc.length = fInfo.smem_len; fbDesc.lineLength = fInfo.line_length;

backBuffer = (unsigned char*)malloc(fInfo.smem_len); memset(backBuffer, 128, fInfo.smem_len);

printf("Framebuffer is %s %ix%ix%i\n", (char*)&fInfo.id, fbDesc.width, fbDesc.height, vInfo.bits_per_pixel, fInfo.type);

}

Если не сделать предыдущий шаг и запускать нашу программу параллельно с recovery, то они обе будут пытаться друг друга «перекрыть» — эдакий race condition:

После этого пишем простенькие функции для блиттинга картинок (в том числе с альфа-блендингом). В инлайнах и критичных к скорости функциям лучше не делать условия на проверку границ нашего буфера — лучше «отрезать» ненужное еще на этапе просчета ширины/высоты:

__inline void pixelAt(int x, int y, byte r, byte g, byte b, float alpha)

{

if(x < 0 || y < 0 || x >= fbDesc.width || y >= fbDesc.height) return;

unsigned char* absPtr = &backBuffer[(y * fbDesc.lineLength) + (x * 4)];

if(alpha >= 0.99f)

{

absPtr[0] = b;

absPtr[1] = g;

absPtr[2] = r;

}

else {

absPtr[0] = (byte)(b * alpha + absPtr[0] * (1.0f - alpha));

absPtr[1] = (byte)(g * alpha + absPtr[1] * (1.0f - alpha));

absPtr[2] = (byte)(r * alpha + absPtr[2] * (1.0f - alpha));

} absPtr[3] = 255; }

for(int i = 0; i < image->height; i++)

{

for(int j = 0; j < image->width; j++)

{

byte* ptr = &image->pixels[((image->height - i) * image->width + j) * 3]; pixelAt(x + j, y + i, ptr[0], ptr[1], ptr[2], alpha);

}

}

И загрузчик TGA:

CImage* m2dLoadImage(char* fileName) {

FILE* f = fopen(fileName, "r");

printf("m2dLoadImage: Loading %s\n", fileName);

if(!f)

{

printf("m2dLoadImage: Failed to load %s\n", fileName);

return 0;

}

CTgaHeader hdr;

fread(&hdr, sizeof(hdr), 1, f);

if(hdr.paletteType)

{

printf("m2dLoadImage: Palette images are unsupported\n");

return 0;

}

if(hdr.bpp != 24) {

printf("m2dLoadImage: Unsupported BPP\n");

return 0;

}

byte* buf = (byte*)malloc(hdr.width * hdr.height * (hdr.bpp / 8));

assert(buf);

fread(buf, hdr.width * hdr.height * (hdr.bpp / 8), 1, f);

fclose(f);

CImage* ret = (CImage*)malloc(sizeof(CImage));

ret->width = hdr.width;

ret->height = hdr.height;

ret->pixels = buf;

printf("m2dLoadImage: Loaded %s %ix%i\n", fileName, ret->width, ret->height);

return ret;

}

И попробуем вывести картинку:

m2dInit();

test = m2dLoadImage("test.tga");

test2 = m2dLoadImage("habr.tga");

while(1)

{

m2dClear();

m2dDrawImage(test, 0, 0, 1.0f);

m2dDrawImage(test2, tsX - (test2->width / 2), tsY - (test2->height / 2), 0.5f);

m2dFlush();

}

Не забываем про порядок пикселей в TGA (BGR, вместо RGB), меняем канали b и r местами в pixelAt и наслаждаемся картинкой на большом и классном IPS-дисплее:

Производительность отрисовки не очень высокая, однако если оптимизировать код (копировать непрозрачные картинки сразу сканлайнами и убрать проверки в инлайнах), то будет немного шустрее. Google для подобных целей сделали собственный простенький софтрендер —libpixelflinger.

Есть вариант для быстрой и динамичной графики: использовать GLES, который без проблем доступен и из recovery. Однако, насколько мне известно (в исходники драйверов посмотреть не могу), указать фреймбуфер в качестве окна не получится, поэтому в качестве Surface для рендертаргета у нас будет служить Pixmap (так называемый off-screen rendering), которому нужно задать правильный формат пикселя (см. документацию EGL). Рисуем туда картинку с аппаратным ускорением и затем просто копируем в фреймбуфер с помощью memcpy.

❯ Обработка нажатий

Однако, ни о каких GUI-программах не идёт речь, если мы не умеет обрабатывать нажатия на экране с полноценным мультитачем! Благо, даже механизм обработки событий в Linux очень простой и приятный: мы точно также открываем устройство и просто читаем из него события в фиксированную структуру. Эта черта мне очень нравится в архитектуре Linux!

Каждое устройство, которое может передавать данные о нажатиях, находится в папке /dev/input/ и имеет имя вида event. Как узнать нужный нам event? Нам нужен mtk-tpd — реализация драйвера тачскрина от MediaTek (у вашего чипсета может быть по своему), для этого загружаемся в Android и пишем getevent. Он покажет доступные в системе устройства ввода — в моём случае, это event2:

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

// Open input device evDev = open(INPUT_EVENT_TPD, O_RDWR | O_NONBLOCK);

После этого, читаем события с помощью read и обрабатываем их. На устройствах с резистивным тачскрином, передается просто ABS_POSITION_X, на устройствах с поддержкой нескольких касаний — используетсяпротокол MT. Когда пользователь нажал на экран, посылается нажатие BTN_TOUCH с значением 1, а когда отпускает — соответственно BTN_TOUCH с значением 0. Разные драйверы тачскрина используют разные координатные системы (насколько я понял), в случае MediaTek — это абсолютные координаты на дисплее (вплоть до ширины и высоты). На данный момент, я реализовал поддержку только одного касания, но при желании можно добавить трекинг нескольких нажатий:

void m2dUpdateInput()

{

input_event ev;

int ret = 0;

while((ret = read(evDev, &ev, sizeof(input_event)) != -1))

{

if(ev.code == ABS_MT_POSITION_X) tsState.x = ev.value;

if(ev.code == ABS_MT_POSITION_Y) tsState.y = ev.value;

if(ev.code == BTN_TOUCH) tsState.isPressed = ev.value == 1;

}

tsState.cb(tsState.isPressed, tsState.x, tsState.y); }

Теперь мы можем «возить» логотип Хабра по всему экрану:

void onTouchUpdate(bool isTouching, int x, int y) {

if(isTouching)

{

tsX = x;

tsY = y;

}

}

int main(int argc, char** argv) {

printf("Test\n");

m2dInit();

test = m2dLoadImage("test.tga");

test2 = m2dLoadImage("habr.tga");

printf("Volume: %i %i\n", vol, muteState);

m2dAttachTouchCallback(&onTouchUpdate);

while(1) {

m2dUpdateInput();

m2dClear();

m2dDrawImage(test, 0, 0, 1.0f);

m2dDrawImage(test2, tsX - (test2->width / 2), tsY - (test2->height / 2), 0.5f);

m2dFlush();

}

return 0;

}

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

❯ Звук, модем и другие возможности

Для звука нам придётся использовать ALSA — поскольку эта подсистема звука сейчас используется в большинстве устройств на Linux. Судя по всему, тут есть режим эмуляции старого и удобного OSS, поскольку устройства /dev/snd/dsp присутствует. Однако, вывод в него какого либо PCM-потока не даёт ничего, поэтому нам пригодится ALSA-lib.

Другой вопрос касается модема и сети. И если Wi-Fi ещё можно поднять (wpa_supplicant можно взять из раздела /system/), то с модемом будут проблемы — нет единого протокола по общению с ним и кое-где, чтобы его заставить работать, нужно будет немного попотеть. Не стесняйтесь изучать исходники ядра (MediaTek охотно делится реализацией вообще всего — там и RIL, и драйвер общения с модемом) и смотреть интересующие вас фишки!

❯ Заключение

Как мы с вами видим, у старых девайсов все еще есть перспективы стать полезными в какой-либо сфере даже без Android на борту. На тех устройствах, где нет порта Ubuntu или обычного десктопного Linux, всё равно сохраняется возможность писать нативные программы и попытаться приносить пользу.

Не стесняйтесь лезть и изучать вендорские исходники — это даёт понимание, как работают устройства изнутри. Собственно, благодаря такому ежедневному копанию исходников системы и появилась данная статья! :)

В прошлой статье, мы с вами рассмотрели на что способен одноплатный компьютер, который стоит всего 1.000 рублей. Как мы выяснили, перспективы у данного девайса весьма неплохие, однако по факту, Orange Pi продаёт практически голую железку, которую нужно дорабатывать самому. Да, тут есть Ubuntu/Fedora, да, тут выведена гребенка с I2C/SPI — однако из коробки это всё работает криво-косо, либо не работает совсем. Даже обещанные шины SPI/I2C фактически не доступны в системе «из коробки». Материалов о доработке этого одноплатника в сети мало, поэтому я решил довести его до ума сам и поделится с вами — в том числе, готовыми бинарными образами! Интересно, на что способен доработанный одноплатник по цене ящика пива? :)

Над чем будем работать

В прошлой статье, мы с вами определились с потенциальными перспективами такого устройства. По цене 3х ESP32, производитель предлагает нам два полноценных вычислительных ARM-ядра, 256 мегабайт оперативной памяти, 512 мегабайт встроенной NAND-памяти, контроллер питания с возможностью работы от литий-ионных АКБ и 3G модем. Но в бочке меда нашлась ложка дегтя: никто не собирался это всё поддерживать и Orange Pi практически сразу «забили» на поддержку устройства, ограничившись портом Debian/Ubuntun на устройство.

Более того, производитель даже не описал как работать с GPIO и шинами устройства — что фактически превращало его из одноплатника в обычную ТВ-приставку, только без нормального видеовыхода. Меня крайне удивило, почему над такой дешевой платой не хотело работать коммьюнити — большинство людей только видели всю ситуацию и шли оставлять негативный отзыв, не попытавшись даже разобраться. А ведь для опытного линуксоида-эмбеддера здесь работы на день-два!

Ко всему прочему, в Linux не работает GSM-стек. Да, совсем. Производитель даже не стал кооперироваться с MediaTek, чтобы попытаться реализовать работу с модемом на уровне системы. А ведь фактически, вся работа с модемом происходит лишь на уровне AT-команд. Так в чем же проблема была?

Со всем этим мне и предстоит разобраться! Клонируем репозиторий с исходниками ядра и бежим собирать!

Собираем ядро. I2C и SPI.

Вместо типичного Buildroot, Orange Pi использует свою собственную простую систему сборки на shell-скриптах: в качестве тулчейна используется уже готовый linaro. Отчасти, это связано с самими чипами, на которых работают их устройства — MediaTek, например, не использует Mainline ядро и в процессе сборке имеет ещё кучу шагов для подготовки финального образа. Там даже menuconfig не работает и все изменения приходится делать в уже сгенерированной когда-то конфигурации.

Клонируем репозиторий с системой сборки и запускаем скрипт:

git clone https://github.com/orangepi-xunlong/OrangePi_Build cd OrangePi_Build ./Build_OrangePi.sh

Выбираем нашу плату — 3G IoT и ждем, пока система сборки фактически скачает все необходимое для сборки — исходный код ядра, папки external (драйвера, загрузчик и порт linux MediaTek). Обратите внимание, OrangePi даже систему сборки завязали на конкретной версии системы: только Ubuntu 18.04, но на самом деле, ядро соберется без проблем практически где угодно. После того, как все было скачано, переходим в папку с скриптом сборки и запускаем скрипт сборки:

cd ../OrangePi3G_iot/
./build.sh

А нет, не запускаем — скрипт жалуется на то, что не может поставить некоторые пакеты. Не беда — ставим bsdtar и python minimal вручную и идем править код скрипта. Находится в он scripts/general.sh: убираем оттуда устаревшие имена пакетов.

После этого, компиляция ядра должна пройти успешно. Обратите внимание на версию вашей платы — те, что продают сейчас — именно A. Если пытаться подкинуть им ядро для B, то они будут уходить в kernel panic из-за отсутствия eMMC.

Если mkbootimg будет жаловаться на libstdc++6, то ставим его x86 версию из репозиториев.

Готовое ядро будет лежать вoutput/kernel/boot.img, которое можно прошить на устройство. С одним маленьким нюансом — оно рассчитано на загрузку из внутренней памяти, которой критически мало для дистрибутива Linux! У нас нет boot_sd.img, который есть в оригинальном дистрибутиве. Попытка разобрать образ стандартным AndImgTool не увенчалась успехом — рамдиск встроен прямо в образ zImage, а не отдельно, как это обычно бывает у Android-образов.

Покопавшись в скриптах сборки, я так и не понял логику создания boot_sd, ничего связанного с sd я не нашел даже grep'ом по всей папке. Ну что-ж, тогда попробуем обходным путем: скомпилируем нужные драйвера в виде загружаемых модулей (ko). Идём в наш конфиг, расположенный в linux/arch/arm/configs/3giot_defconfig и меняем CONFIG_I2C_CHARDEV и CONFIG_SPI_SPIDEV на m. Пояснение: y заставит систему сборки скомпоновать драйвер статически с ядром, а m выделит его в виде отдельного модуля ko, который затем можно загрузить черезinsmod.

Снова собираем ядро, на этот раз компиляция занимает не больше минуты. Нужные нам файлы появятся в linux/drivers/spi/spidev.ko и linux/drivers/i2c/i2c-d-ev.ko. Переносим их на хост-пк, а затем и на само устройство с помощью SSH:

Загружаем модули ядра:

insmod i2c-dev.ko


И та-дам! Целых две i2c шины появилось в системе (/dev/i2c-0, /dev/i2c-1). Устанавливаем i2c-tools и идем проверять с помощью i2cdetect: первая шина полностью свободна под наши проекты, а на второй по некоторым адресам висит периферия (FM-радио как вариант):

I2C теперь точно работает! Но как насчет SPI?

insmod spidev.ko
Device or resource busy.


Увы! spidev нельзя подгружать динамически, только статически линковать с ядром, чего мы сделать пока не можем. Однако техническая возможность заставить работать SPI есть: например, написать свой драйвер, который транслирует команды из юзерспейса в SPI API, которое работает на уровне ядра.

GPIO

В прошлой статье, я вкратце рассказал, как работать с gpio из user-space на уровне терминала. Однако, большинство разработчиков потенциально будет пользоваться нативным API для GPIO — ну не всерьез же им парсить вывод состояния в консоль? Поэтому я решил написать крошечную библиотеку для работы с GPIO, такую же простую, как и DigitalWrite/DigitalRead!

Давайте сначала разберемся, как именно работать с драйвером GPIO. Для этого открываем исходники ядра и смотрим внимательно, что нам предлагает драйвер: в нашем случае, это вызовы IOCTL, да еще и простые и понятные. Это просто отлично! Я написал single-header библиотеку минут за 10: без проверки ошибок, но работоспособная.

void gpioInit();

void gpioSetDir(int num, byte dir);

byte gpioGetDir(int num);

void gpioWrite(int num, byte value);

byte gpioGetState(int num); byte gpioRead(int num);

void gpioSetPullState(int num, byte enabled, byte up);

Пример использования (141 — крайний пин на гребенке):

#define GPIO_IMPL

#include "gpio.h"

#include <stdio.h>

void testPin(int pin)

{

printf("Pin state %i is %i\n", pin, gpioGetState(pin));

gpioSetDir(pin, 1);

gpioWrite(pin, 0);

printf("Pin state %i is %i\n", pin, gpioGetState(pin));

gpioWrite(pin, 1);

printf("Pin state %i is %i\n", pin, gpioGetState(pin));

}

int main(int argc, char** argv) {

gpioInit();

testPin(141);

}

Модем

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

В устройствах MediaTek, драйвер для общения с GPS, A-GPS и модемом один — ccci, судя по всему cross chip communication interface. Именно ccci создает устройства, с в которые поступает вход с микрофона и выход на динамики, а также он создает управляющие интерфейсы для общения с различными модулями этого SoC.

При старте ядра, ccci создаёт много устройств — ccci_ioctl, ccci_ipc, ccci_fs и самое нужное нам —ttyC0/ttyC1/ttyC2— в зависимости от количества СИМ-карт в системе. Кроме ccci, в системе есть некий 6620_launcher — бинарник, который загружает прошивку Wi-Fi и gsm0710muxd — специальный сервис, который позволяет в GPRS-сетях одновременно разговаривать и сидеть в интернете.

На смартфонах MTK есть factory mode — так называемый тестовый режим, который гоняют на заводах. Вы, вероятно, когда-то видели китайские меню похожее на рекавери — это и есть factory mode. Из этого режима можно дозвонится в 911 и активировать модем без запуска Android и RIL. Как это работает? Идём читать исходники ядра!

В factory-режиме, для каждого теста, программа активирует модем заново. Для этого есть функции тестового режима для работы с AT-командами и для инициализации модема. Сначала, она открывает терминал /dev/ttyC0 — именно там происходит общение с модемом с помощью AT-команд:

После этого, программа выводит модем из режима сна с помощью команды «AT+ESLP=0», инициализирует СИМ-карту с помощью команды «AT+ESIMS» и задает режим работы с помощью «AT+EFUN=1» и «AT+CREG=1». После этого, модем начинает искать сеть и доступен для обычного общения с помощью AT-команд. Однако, написав тестовую софтину для общения с модемом из под Debian, я получал ошибки вида Device not found. Почему? Пока не знаю. Однако я продолжаю изучать данный вопрос!

Заключение

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

К счастью, довести гаджет до ума мы смогли своими силами. Весьма странно, что такой крупный и уважаемый производитель как Orange Pi, банально решил «забить» на поддержку собственного устройства. И я лично считаю, что не стоит закидывать в долгий ящик их тем читателям, которые купили когда-то себе подобный девайс и забили, смирившись с отсутствием гайдов.

Немного энтузиазма, опыта и видения будущего проекта — и все получится :)

Каждый год выпускается с десяток новых моделей одноплатных компьютеров. Свежие девайсы представляют как старые и уважаемые фирмы по типу Raspberry Pi, Orange Pi или Banana Pi, так и относительные новички на рынке — Repka Pi, или, например, Lctech Pi. Одноплатники работают на достаточно большом парке железа: кто-то использует чипы AllWinner, кто-то Amlogic, кто-то Beoadcom, а кто-то… мобильные! Пару лет назад Orange Pi отличились выпуском нескольких одноплатников на базе чипсетов очень бюджетных мобильников 2013-2015 годов — 2G IoT и 3G IoT. На данный момент, выпуск 3G IoT завершен, а компания предлагает купить абсолютно новый одноплатник с 3G, Bluetooth, Wi-Fi, GPS, поддержкой Linux и Android всего за 1.000 рублей (500 само устройство и 500 доставка). На что оно способно и стоит ли его брать — узнаем в статье!

Что за устройство?

IoT устройство уже прочно закрепились в нашей жизни. Сейчас уже есть возможность приобрести полноценный внешний GSM-модуль за пару сотен рублей, который способен будет выйти в сеть или обрабатывать SM. Однако, в мире одноплатников всё не так просто: большинство из этих устройств использует планшетные чипсеты, которые обычно не обладают встроенными модемами для работы в GSM-сетях. На помощь приходят внешние модули, но чем выше необходимое поколение связи, тем выше цена. И есть 200 рублей за 2G модуль — это совсем немного, то 3G, а тем более LTE модули могут влететь в копеечку. Конечно в мейнлайн дистрибутивах уже есть драйвера на некоторые модемы Huawei, благодаря чему можно просто воткнуть копеечный USB-свисток но это не совсем спортивно.

С весьма интересным решением пришла компания Orange Pi. Несколько лет назад они представили весьма занимательное устройство: 2G IoT, которое работало на базе давным-давно забытого мобильного чипсета RDA8810, который является родственником Spreadtrum SC6820 — чипа, который использовался в очень многих китайских ультрабюджетниках 2012-2014 годов. Устройство отличалось весьма неплохими характеристиками за низкий прайс:

• Процессор: RDA8810, Cortex-A5, 1Ghz.

• ОЗУ: 256 мегабайт DDR2.

• ПЗУ: 512 мегабайт NAND памяти + возможность загрузки с MicroSD флэшек.

• Дисплей: 40-пиновый коннектор, мимикрирующий под стандартизированный. Однако производитель предлагает свой дисплей от мобильниках втридорого, а распиновка несколько отличается от общепринятой — нужно делать переходник.

• Питание: 5в от USB, до 2А нагрузки при работе с сетью, 3.7в от АКБ с встроенным контроллером питания.

• Звук: Микрофон + встроенный в чипсет ЦАП для вывода звука из системы.

• Интерфейсы: SPI, I2C, GPIO, UART, Wi-Fi, Bluetooth.

Причина низкой цены и хорошего функционала очень проста: Orange Pi просто взяли референсную плату ультрабюджетного смартфона за 1.500-2.000 рублей и развели из нее одноплатник, который затем начали производить. На момент выхода одноплатника, смартфоны на 8810 не производились, так что отпускная цена на чипы была копеечная, в то время как на AllWinner'ы спрос весьма хорош. Год назад они продавались по 700 рублей с учетом доставки, но сейчас их окончательно распродали и найти их можно только на вторичке.

3G IoT — следующая ветвь развития IoT линейки OPi, которая на этот раз работает на базе чипсета MediaTek и имеет полноценную поддержку 3G. По сути, возможности остались те же, однако возможности вывода на HDMI до сих пор нет — теперь производитель предлагает LVDS матрицу, опять же, втридорого. Однако схема есть, чисто теоретически есть возможно купить какой-нибудь бюджетник от ZTE/Huawei, найти схему платы и сделать переходник с шлейфа нашей матрицы на коннектор одноплатника. Драйвер матрицы можно взять в исходниках ядра и без изменений перенести. Работает девайс на базе чипа для бюджетных смартфонов, однако теперь в нашем распоряжении целых два ядра!

Характеристики девайса такие:

• Процессор: 2х-ядерный MT6572, Cortex-A7, 1.2Ghz.

• ОЗУ: 256мб.

• ПЗУ: 512мб eMMC флэшка от Leahkinn + возможность загрузки с MicroSD.

• Дисплей: MIPI DSI, LVDS.

• Питание: 5в, до 2А в пике, 3.7в с контроллером питания.

• Звук: всё так же, микрофон + ЦАП.

• Интерфейсы: SPI, I2C, GPIO, UART, Wi-Fi, Bluetooth.

Весьма недурно, согласны? На момент выхода статьи, этот одноплатник можно заказать на всем известном сайте за 1.000 рублей — это с учетом доставки. Идет недели 3, поставляется в фирменной коробочке. Гребенка уже распаяна с завода.

Ну что-ж, предлагаю посмотреть, что может предложить нам такой одноплатник и стоит ли его вообще брать?

Накатываем систему

На выбор у нас есть Android и Linux. Учтите, что GSM стек работает только в Android! Теоретически есть возможность связаться с модемом из под Linux, но это требует дальнейшего изучения местного factory-режима. Впрочем, GSM под Android не так уж и плохо — нужное вам поведение, вероятно, можно реализовать в виде службы. Но управлять Android придется только, и только через ADB, если у вас нет дисплея.

Для установки ОС можно использовать как внутреннюю память (только Android, rootfs линукса туда не влезет), так и на MicroSD. Оба способа требуют прошивки eMMC с помощью фирменого флэшера — SP Flash Tool. Суть в том, что выбор варианта загрузки с SD/NAND реализован здесь в виде настройки точки монтирования: ядро так или иначе будет находится на eMMC, но в зависимости от выбранного образа boot, будет загружать систему с соответствующего носителя. Примерно как это реализовано здесь.
Мы будем ставить Linux: качаем SP Flash Tool, выбираем scatter-файл и ставим Format All + Download. Осторожно, форматирование сотрет NVRAM и IMEI, так что лучше сделать бэкапы (хотя их все равно можно легко перебить из системы вручную):

На первом проходе, флэшер переразметит внутреннюю память, но ругнется на отсутствующий раздел System. После этого, нужно вернуть режим Download only, снять галку с System и прошить устройство еще раз — после этого, плата будет загружаться с MicroSD:

Теперь нужно записать саму систему на флэшку. Образы записываются как обычно — берем флэшку на 4-8гб, вставляем в кард-ридер и записываем образ через Win32DiskImager. Флэшку желательно брать 10-класса, но у меня и «пятерка» работала с адекватной производительностью:

После записи, вставляем флэшку в устройство и запитываем его. Возможны варианты питания как напрямую от БП, так и от аккумулятора — в таком случае, при подключении БП, контроллер питания будет заряжать аккумулятор, а за статусом зарядки можно следить через устройство battery в /sys/class/power_supply/ (и в Linux, и в Android).

Для общения с системой через консоль, нам понадобится UART-преобразователь. Я для этого использую плату ESP32-WROOM с выпаянным чипом ESP32. Подтыкиваемся (или подпаиваемся) к UART'у, запускаем putty, ставим бодрейт 115200 и вперед наблюдать за консолью!

Настраиваем Linux

Тут ничего особо сложного нет, лишь некоторая подготовка к полноценному использованию системы. Если для вас написанное малопонятно — можете просто скопипастить, все должно работать без проблем.

Итак, система запустилась и требует логин, а кроме этого — сыпет логами в UART. Стандартный логин — root, пароль orangepi, лучше смените пароль сразу. Надоели логи? Пишем:

dmesg -n 1

Можно сразу записать эту команду в rc.local, если не хотите после каждого ребута писать команду по новой.

После этого, нам нужно настроить Wi-Fi. В системе предустановлен wpa_supplicant, поэтому для подключения мы идем в /etc/network/ и редактируем с помощью nano файл interfaces:

nano interfaces

... Дописываем

auto wlan0

iface wlan0 inet dhcp

wpa-ssid "Имя вашей сети"

wpa-psk "Пароль вашей сети"

Жмем Ctrl + X, сохраняем и перезапускаем сервис networking service networking restart Возникли проблемы? wpa_supplicant жалуется на существующий контекст? Удаляем wpa_supplicant из /run/, если все равно не работает - отправляем систему в ребут, должно заработать.

Имейте ввиду: плата без проблем питается от стандартных 5В/0.5А USB-порта ПК, но если подключить к ней USB-устройство во время работы — то плата начнет уходить в ребут при попытке поднять Wi-Fi, даже если вытащить флэшку. Лечится легко: обесточиваем плату, затем включаем снова.

Подключиться можно хоть к точке Wi-Fi от вашего смартфона, дабы объединить их в локальную сеть. Тогда с помощью VNC можно будет вывести изображение с одноплатника на экран разбитого сяоми — чем не применение старому гаджету? Пингуем гугл, сеть есть — отлично!

Теперь ставим icewm из репозиториев, tightvnc и пошло поехало… ан нет! Debian Stretch уже выкинули из официальных репозиториев, перенеся его в архив. Пользовались старыми версиями убунты/дебиана? Тогда следующая операция для вас будет знакома:

nano /etc/apt/sources.list

...

Меняем ftp2.cn.debian.org на archive.debian.org во всех строках. Ctrl + X, сохраняем.

Пишеv apt-get update. Ждём обновления списка пакетов.

Теперь мы можем ставить официальные бинарные пакеты из репозиториев. Нам доступна куча софта, в том числе с более старших Raspberry Pi и Orange Pi — ABI то одно! Можно поставить TightVNCServer, запустить его и без проблем подключиться к нашей машинке (5900 — базовый порт, 5901 — будет для первого дисплея и.т.п).

Но сейчас у нас просто маленький и слабенький десктоп. Надо же использовать возможности одноплатника по полной, верно?

GPIO

У устройства есть гребенка с 40 пинами, часть из которых мы без проблем можем использовать для наших целей. Друзья, если вы уже имели опыт с другими одноплатниками, то знаете что для Broadcom/AllWiiner и других иных чипсетов уже есть готовые библиотеки для работы с GPIO. Под MediaTek их нет, но ничего сложного в работе с ними из user-space нет. Рассмотрим схему подробнее и два способа работы с ними:

Первый из официального мануала, подразумевает чтение и запись в специальное виртуальное устройство — mt_gpio, а вернее — в его дебаг-режим. В него можно писать хоть из shell-скрипта при желании. Виртуальное устройство расположено по пути/sys/devices/virtual/misc/mtgpio/pin. Если просто начать читать из него, то мы получим список всех пинов и их состояние:

PIN: [MODE] [PULL_SEL] [DIN] [DOUT] [PULL EN] [DIR] [INV] [IES]
0:1000000-1
1:1000000-1
...

Чтобы записать состояние, нам нужно послать специальную строку:

echo -wdout<номер пина> > 1/0

Чтобы выбрать направление пина, нам нужно послать:

echo -wdir<номер пина> > 1/0, где 0 - вход

Чтобы получить состояние пина, нужно прочитать все строки устройство pin и потом распарсить, например, с sscanf (хотя поскольку одно поле — один char, можно взять абсолютное смещение от начала строки). Если читаем — то 3 столбец после двоеточия будет состоянием нашего пина. Я уже все проверил, все точно работает без каких либо проблем, главное не забывайте за режим GPIO :)

Пожалуйста, согласовывайте уровни! GPIO у MT6572 имеют лог. уровень 1.6в. Часть периферии чипсета работает на стандартных 3.3в.
Как это работает? См.в исходниках ядра.

Такой способ подойдет для приложений, где не требуется сильно высокая скорость работы. Для шелл-скриптов или даже полноценных нативных приложений таким методом можно управлять пинами без проблем — если вы конечно не реализовываете SPI софтварно :)

Есть и второй способ — использовать mt-gpio напрямую через вызов ioctl. Я этот режим пока еще не пробовал, но он гораздо быстрее — для юзерспейса самое то, а работать с ним довольно легко. См. исходники драйвера здесь.

UART

Это второй способ коммуникации с внешним миром, доступный из коробки. На устройстве целых два канала UART, которые могут работать как минимум со скоростью 921600б/с (или 115200 килобайт в секунду). лучше всего использовать эту шину для общения с другими микроконтроллерами или ПК.

Получить доступ к UART можно благодаря соответствующему character-устройству /dev/ttyMTxx. При стандартных настройках (921600б/с), можно без проблем работать с UART из shell-скриптов, как с самым обычным терминалом: echo для записи, cat — для чтения. Из нативных программ, есть такая же возможность открыть ttyMT и читать/писать при стандартных настройках, а если конфигурацию необходимо изменить, то на помощь приходит termios.

SPI/I2C

А вот тут уже все гораздо интереснее. Как известно, в Linux драйвера шин делятся на два типа: kernel-mode, для работы с драйвером SPI/I2C из других драйверов (например, драйвер камеры хочет получить информацию о модуле через i2c) и user-space i2c-dev/spi-dev. Последние два есть из коробки в большинстве дистрибутивов для «взрослых» одноплатников, но их забыли включить в текущий релиз ядра 3G IoT. Почему? Не ясно — драйвера для i2c и spi у MediaTek точно есть.

На гребенке есть один I2C и один SPI. Исходники ядра для платы можно найти на гитхабе OrangePi. Чуть позже надо будет попробоваать скомпилировать i2cdev и spidev в виде отдельных модулей ядра, которые можно будет загрузить через modprobe.

Я хочу бэйр-метал, а не эти ваши линуксы!!!

И такая возможность есть, но лишь частично. Orange Pi открыли исходники вторичного загрузчика MediaTek — lk (альтернатива u-boot) или Little Kernel. При некоторой модификации логики lk, можно реализовать свою прошивку используя почти всю мощь чипсета. За этим — сюда.

Для чего он еще может пригодится?

Давайте смотреть сами. У нас есть полноценный десктопный Linux, есть Android, есть 2 неплохих ARMv7 ядра, работающих на частоте 1.2ггц, есть 256 мегабайт ОЗУ. Чем он может еще пригодится:

• Сервер: Нет, речь конечно же не о NAS. Однако поднять простенькую домашнюю страницу, или попытаться реализовать на нем умный дом можно вполне.

• Сбор информации с датчиков: В паре с микроконтроллером, на таком устройстве можно собирать, обрабатывать и хранить довольно большое количество данных с высокой скоростью опроса.

• Ретро-машинка для эмуляторов: При условии, что Вы купили фирменный дисплей, поскольку через VNC поиграть не получится. К сожалению, ни одного вывода на ТВ, данный чипсет не имеет, поэтому либо пытаться прикрутить дисплей от китайчика, либо покупать фирменный.

• Хитрая и дешевая сигнализация с GPS: В целом, для сигнализации такую плату можно рассматривать как System On Module: сразу и линух есть, и GPS из коробки, и 3G. Выйдет дешевле, чем купить отдельно GPS, ESP32 и 3G модуль.

В целом, можно найти еще кучу всяких разных применений данной плате в embedded.

Схема платы доступна здесь:drive.google.com/drive/folders/19R66eFtCDVDVGs7P_WTTBaHTfshnIIqK

Заключение

Я считаю, что подобных ультрадешевых плат должно быть гораздо больше на рынке, ведь не все готовы платить несколько тысяч рублей за одноплатники. Однако, такие решения не подойдут для тех людей, которые хотят «купить и чтобы работало, с кучей гайдов» — у таких плат банально околонулевая поддержка. Да, Orange Pi уважаемая компания, они предоставляют полный исходный код не только ядра, но и загрузчиков — чего они делать не обязаны были, но по сути они просто произвели на свет эту плату, а разбираться в ней придется конечному пользователю. Без мануалов, без гайдов.

Стоит ли такую себе брать? Я лично не пожалел :) Плата очень перспективная, а ковыряться в исходниках ядра я люблю. Попробую сделать из неё что-то полезное!