Android + Linux

Для многих разработчиков приложений далеко не секрет, что экосистема 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, всё равно сохраняется возможность писать нативные программы и попытаться приносить пользу.

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

Linux

OpenSnitch

gufw

Uncomplicated Firewall

Windows

SimpleWall

TinyWall

MacOS

LuLu

Little Snitch

Android

NetGuard

NoRoot Firewall

AFWall+

RethinkDNS + Firewall

iOS

Lockdown

Hardware

IPFire

Shorewall

OpenSense


Мы в телеграме!

В прошлой статье, мы с вами рассмотрели на что способен одноплатный компьютер, который стоит всего 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, банально решил «забить» на поддержку собственного устройства. И я лично считаю, что не стоит закидывать в долгий ящик их тем читателям, которые купили когда-то себе подобный девайс и забили, смирившись с отсутствием гайдов.

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

GUI утилита от работящих китайцев, подключается к вашим устройствам Android через USB (или через TCP/IP) для отображения и управления ими.
Поддерживает три основные платформы: GNU/Linux, Windows и macOS.

Вы также можете управлять всеми своими телефонами одновременно.😎
https://github.com/barry-ran/QtScrcpy

Если интересно: https://t.me/errorium/228

Каждый год выпускается с десяток новых моделей одноплатных компьютеров. Свежие девайсы представляют как старые и уважаемые фирмы по типу 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 уважаемая компания, они предоставляют полный исходный код не только ядра, но и загрузчиков — чего они делать не обязаны были, но по сути они просто произвели на свет эту плату, а разбираться в ней придется конечному пользователю. Без мануалов, без гайдов.

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