Unix + Гаджеты

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

Недавно я задался вопросом: а возможно ли написать для ARM нативную программу, которая будет бесшовно работать сразу на 4-х операционных системах без необходимости перекомпиляции для разных платформ и ABI. Мне очень хотелось реализовать возможность писать кроссплатформенные эльфы для мобильных телефонов из нулевых и попытаться портировать на них эмуляторы ретро-консолей. Погрузившись в документацию на исполняемые форматы, я пришёл к выводу, что да - это возможно и смог реализовать такую программу на практике без читерства по типу VM! Всех гиков приглашаю под кат!

❯ Зачем и почему?

Давным-давно, в далёком 2001 году, мир увидел легендарный японский телефон - Sony CMD-J70. Ещё до создания совместного подразделения с Ericsson, Sony выпускала достаточно занимательные девайсы, которые привлекали внимание не только рядовых пользователей, но и моддеров всех мастей. Уже через пару лет после выхода, в программном плане телефон копали все кому не лень: кто-то менял графику, кто-то писал патчи, а со временем написали даже бинлоадер (PRGLoader) - загрузчик внешних "экзешников", позволявший запускать на телефоне произвольный софт, написанный на ассемблере!

Сейчас сложно себе представить, но в те годы это был нереальный отвал башки: на большинстве телефонов были доступны разве что Java/Mophun-приложения, которые обладали ограниченным функционалом и уж тем более не позволяли лезть в дебри прошивки телефона, а здесь были программы которые буквально позволяли делать с телефоном всё что захочешь: светомузыку из подсветки, кастомные игры, обои на главный экран... всё это было доступно только на куда более дорогих смартфонах с Symbian и Windows Mobile на борту!

Недавно мы с вами вспоминали о легендарном Siemens M55 и узнали, что у него находится под капотом. Несмотря на диковинную архитектуру Infineon C166, даже под этот телефон делались патчи и была написана как минимум одна кастомная игра. Но рассвет моддинг-сцены Siemens произошёл с выходом платформы S-Gold на базе стандартного ядра ARM926EJ-S, когда в ~2004 году энтузиасты полностью взломали алгоритм генерации BootKEY для загрузчика, а затем в 2006 году реализовали полноценный эльфлоадер, который позволял загружать программы написанные на C и скомпилированные самым обычным компилятором ADS. В отличии от бинлоадера для CMD-J70, "эльфятник" позволял угонять функции RTOS для создания потоков и привносил в бюджетные телефоны полноценную вытесняющую многозадачность с настоящим диспетчером задач и возможностью запуска несколько программ одновременно:

Энтузиасты раскапывали прошивку в дизассемблере, изучали её и пытались понять как работают разные её подсистемы. Результатом стало появление нативного клиента почты с предком пуш-уведомлений, аськи (NatICQ), порты самых разных эмуляторов ретро-консолей и даже полная программная поддержка MP3 в тех телефонах, где её отродясь не было! И представьте себе, почти все эти программы можно было свернуть и продолжить работу в браузере или, например, Card Explorer'е! Одним из эльфописателей был Хабровчанин @ilya_ZX

Но если вы думаете что одними телефонами Siemens энтузиасты были едины, то вы ошибаетесь - ведь круче были только "моторолки"! В 2004-году, недорогая Motorola E398 с двумя громкими динамиками, светомузыкой и поддержкой MicroSD-флэшек, стала настоящим бестселлером и привлекла к себе не меньше энтузиастов, чем Siemens. Ребята сплотились на форуме MotoFan, нашли уязвимость в загрузчике и хакнули верификацию RSA-подписи у прошивок, позволив не только модифицировать Seem'ы (что-то типа NVRAM), но и создавать для телефона кастомные прошивки - монстрпаки, которые прибавляли громкость и без того не самым тихим динамикам и в различных аспектах изменяли главное меню устройства. Со временем, @Andy51 и ещё несколько энтузиастов реализовали эльфлоадер (EP1) для E398, раскопали прошивку и написали много полезного софта, время от времени переключаясь на Linux-телефоны от Motorola...

Вероятно многие читатели подумают мол "было и было, мой айфон/сяоми может запускать любой произвольный софт и эти ухищрения давным-давно неактуальны...". Но как бы не так: про моторолки и сименсы не просто всё чаще вспоминают, у них есть до сих пор активное моддерское коммьюнити, которое продолжает пилить для них кастомный софт и далее колупать прошивку. Всё тот же @EXL портировал крутой софтрендер для E398 и в 2025 году наконец-то взломал C350, @Azq2 пилит аппаратный эмулятор Infineon S-Gold и многие другие делают свой вклад в моддинг сцену уже не таких мейнстримных, но отнюдь не устаревших устройств!

Однако порог вхождения для написания эльфов достаточно высокий: нет никакой отладки кроме printf, любая ошибка в приложении приводит к зависанию или ребуту телефона (на сименсах с характерным "пик"), а API напрямую импортируется из прошивки телефона и может быть достаточно комплексным - ни о каких кроссплатформенных эльфах и речи не идет. Поэтому в какой-то момент мне стало интересно: а возможно ли написать такой эльфлоадер, который за своим рантаймом будет прятать детали реализации работы с аппаратной начинкой телефона и при этом загружать один и тот же бинарник на всех поддерживаемых платформах без особых патчей и изменений? Принявшись за изучение ABI ARM и спецификации Elf, я начал дизассемблировать и изучать самые маленькие тестовые программы...

❯ Формат ELF, ABI ARM и тулчейн

Начнём с самого простого: что же такое эти самые эльфы? Elf - формат исполняемых файлов, широко применяемый как в мире Unix-систем, так и в embedded-устройствах. Самые распространенные тулчейны - GCC и clang/llvm, по умолчанию собирают программы именно в этом формате и по своей сути, это прямой аналог .exe (PE) файлов из Windows. Помимо кода, Elf также содержит в себе множество секций и различных данных, при этом разработчики формата старались сделать его настолько гибким, чтобы его можно было использовать на любых архитектурах: от x86, до risc-v.

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

.text - хранит в себе код программы и обычно записывается в память с флагами MMU R X (чтение и выполнение)

.data - преинициализированные данные, имеет флаги R W (чтение и запись). Например, заполненная структура в C:

int a[] = { 1, 2, 3 };

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

.rodata - различные константы: строковые, const-преинициализированные массивы, а также структуры и т.п, имеет только флаг R и на системах с MMU попытка запись в эту секцию повлечет SIGSEGV.

За загрузку всех этих секций отвечает загрузчик Elf в ядре ОС. Однако это справедливо только для простых программ, которые загружаются в фиксированный адрес виртуальной памяти и которые не используют внешние библиотеки (.so, аналог в Windows - .dll). Поскольку адрес загрузки для всех библиотек предсказать невозможно, разработчики ABI придумали позиционно-независимый код (PIC и его производное - PIE), который может загружаться в любую область памяти и оттуда выполняться.

Реализация PIC может достигаться тремя разными способами:

• Первый способ заключается в использовании глобальной таблицы смещений (GOT) и релокаций. Релокации - специальные данные в Elf, которые позволяют переместить программу в другой адрес путём патчинга адресов в секции .got "на лету": иными словами, сам код (.text) остаётся позиционно-независимым (дабы библиотеку можно было загрузить один раз и использовать во множестве процессов) и обращается к GOT относительно PC, но в самом GOT (который представляет из себя массив void* addresses[]) указатели на остальные сегменты находятся так, будто программа загружается по смещению 0x0. Задача динамического линкера - посчитать абсолютный адрес для всех указателей в GOT: в простейшем случае, это got[address] += baseAddress.
  Релокации могут затрагивать сразу literal pools в обход GOT, если архитектура предусматривает их наличие.

• Релокацией занимается динамический линкер или интерпретатор в мире Unix (тот самый ld.so, что часто "not found" :) ), а самих релокаций есть много разных видов в зависимости от архитектуры процессора. В ARM чаще всего встречается R_ARM_REL32

• Второй способ заключается в том, что мы компилируем программу так, будто она должна загружаться по фиксированному адресу 0x0 - то есть без PIC, однако просим линкер (--emit-relocs) создать информацию о всех обращениях к памяти в виде всё тех же релокаций. Вместо R_ARM_REL32, линкер создаёт релокации R_ARM_ABS32, которые можно разрешить обычным сложением.
  С таким подходом количество релокаций кратно увеличивается, однако из-за отсутствия GOT немного повышается быстродействие программы (вместо трёх LDR для загрузки слова из памяти нужно всего два: из Literal pool в регистр и затем из фактической памяти).

Третий способ поддерживается не везде, но в ARM он является одним из самых распространенных в embedded-среде: код собирается с флагами /rwpi и /ropi полностью не зависит ни от GOT, ни имеет каких либо релокаций. Вместо этого, для адресации базового адреса программы он использует выделенный регистр R9, который загрузчик должен заполнить адресом, куда он загрузил программу (mov r9, textSectionBase). Такой подход теоретически чуточку быстрее, чем GOT, но медленнее второго подхода из-за необходимости добавлять сложение регистра с PC перед каждым фетчем из памяти.

Поскольку в телефонах MMU обычно не используется, эльфлоадеры загружают программы по тому адресу, что им выделяет системный аллокатор памяти и вынуждены использовать PIC. Чаще всего используются релокации (как минимум на Siemens и Motorola), на некоторых платформах используется второй подход с использованием регистра R9.

Для большей гибкости, я решил выбрать второй подход и построить свой эльфлоадер поверх уже существующих загрузчиков, обернув API прошивок в ряд собственных стандартизированных функций: работа с дисплеем, вводом, файлами, а также звуком. При этом эльфы должны собираться современным компилятором clang с поддержкой C99, чтобы была возможность легко портировать современные single-header программы по типу эмуляторов, да и в целом не писать код на манер Ansi C, когда переменную нигде нельзя объявить кроме начала блока.

Далее я сутками игрался с компиляторами и пытался заставить выдать их подходящий для моих целей код и по итогу написал скрипт для линкера, который для простоты загрузки файла объединяет все секции в один .text (таким образом остаётся всего один Program Header):

OUTPUT_FORMAT("elf32-littlearm")
SECTIONS
{
. = 0x0;
.text : {
*(.r9ptr)
*(.text*)
*(.data*)
*(.bss*)
*(.rodata*)
*(.functions)
}

.rel : {
*(.rel*)
}

/DISCARD/ : {
*(.ARM.*)
}

}

И следующий набор опций для компилятора, который устанавливает архитектуру и целевой процессор, ABI для FPU, включает генерацию релокаций и отключает выравнивание в линкере для выходного файла (иначе файлы забиты нулями и весят целых 64Кб:

Когда компилятор наконец-то начал выдавать корректный код, я принялся писать сам эльфлоадер. За качество кода и отсутствие нормальной структуры не ругайте - это эмбеддед, тут можно ;))

На входе лоадеру поступает адрес загруженного в память эльфа и его длина. Задача эльфятника - верифицировать заголовок и убедится что он собран с подходящими параметрами:

// Read and verify ELF header
Elf32_Ehdr* hdr = (Elf32_Ehdr*)data;

PRINT("Loading ELF...");
if(hdr->e_machine != EM_ARM)
{
PRINT("Not an EM_ARM executable");

return 0;
}

if(hdr->e_ident[EI_DATA] != PLATFORM_ELF_ENDIANESS)
{
PRINT("Endianess mismatch");

return 0; // Wrong endianess
}

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

ret = (ExecInfo*)ExecAlloc(sizeof(ExecInfo));

sections = (Elf32_Phdr*)(&data[hdr->e_phoff]);
sh = (Elf32_Shdr*)&data[hdr->e_shoff];
symSectionIndex = hdr->e_shstrndx;
codeSize = 0x0;

PRINT("Processing program headers");
// Process program headers and determine total size
for(i = 0; i < hdr->e_phnum; i++) {
Elf32_Phdr hdr = sections[i];

if(hdr.p_type == PT_LOAD) {
if(hdr.p_offset == 0x0)
continue;

codeSize += hdr.p_memsz;
}
}

PRINT("Allocating memory for .text");

textSection = (char*)ExecAlloc(codeSize);
textOffset = textSection;

ret->CodeSection = textSection;

if(!textSection)
{
free(ret);
PRINT("Failed to allocate .text section");

return 0;
}

Далее найти секцию с таблицей символов и с строками, где содержатся имена символов:

PRINT("Analyzing section table");
for(i = 0; i < hdr->e_shnum; i++)
{
Elf32_Shdr sec = sh[i];

if(sec.sh_type == SHT_STRTAB && i != hdr->e_shstrndx && strTable == 0)
{
strTable = &data[sec.sh_offset];
PRINT("Found string table");
}

if(sec.sh_type == SHT_SYMTAB)
{
PRINT("Found symbol table");
symbols = (Elf32_Sym*)&data[sec.sh_offset];
symNum = sec.sh_size / sizeof(Elf32_Sym);
}

if(sec.sh_type == SHT_REL && relocs == 0)
{
UtilPrint("Found relocations");
relocs = (Elf32_Rel*)&data[sec.sh_offset];
relNum = sec.sh_size / sizeof(Elf32_Rel);
}

if(sec.sh_type == SHT_RELA)
{
PRINT("Found unsupported relocation types");
return 0;
}
}

if(!strTable || !symbols)
{
free(ret);
PRINT(".strtab or .symtab not found");

return 0;
}

А затем найти функцию ElfMain, которая служит точкой входа и пропатчить таблицу импортированных функций! На этом, загрузка эльфа завершена - можно устанавливать регистр R9 и вызывать Main!

PRINT("Relocation fix-up");
for(i = 0; i < relNum; i++)
{
Elf32_Rel rel = relocs[i];
int sym = ELF32_R_SYM(rel.r_info);

switch(ELF32_R_TYPE(rel.r_info))
{
case R_ARM_ABS32:
*((unsigned int*)&textSection[rel.r_offset]) += (unsigned int)textSection;
break;
case R_ARM_JUMP24:
break;
case R_ARM_CALL:
break;
default:
PRINT("Unsupported relocation type");
}
}

PRINT("Patching import table");

// Analyze symbol table and patch all imported function pointers to real counterparts
for(i = 0; i < symNum; i++)
{
Elf32_Sym sym = symbols[i];
uint8_t* symName = &strTable[sym.st_name];

int symType = ELF32_ST_TYPE(sym.st_info);

if(symType == STT_OBJECT && strstr((const char*)symName, "SYS_"))
{
int funcNumber = ExecFindFunction(symName);

if(funcNumber == -1)
{
PRINT("Failed to import function: ");
UtilPrint((char*)symName);
PRINT("");

continue;
}

//drawDebug(FuncExportTable[funcNumber].Pointer == 0 ? "Not OK" : "OK");

*((unsigned int*)&textSection[sym.st_value]) = (unsigned int)FuncExportTable[funcNumber].Pointer;
}

if(symType == STT_FUNC && strstr((const char*)symName, "ElfMain"))
{
PRINT("ElfMain function is found");

ret->Main = (ExecMainFunction)&textSection[sym.st_value];
}

В Elf уже есть механизм импорта функций из сторонних библиотек, называется Platform Linkage Table. Для импорта функций прошивки, эльфлоадер Siemens использует SWI (сисколлы, что-то типа программных прерываний в x86 - int 10h и т.п.), Motorola же патчит thunk-функции на лету, которые сами вызывают настоящую функцию:

А я решил поступить несколько изящнее. В моем эльфятнике, функции импортируются с помощью специального макроса, который создаёт переменную-указатель на функцию, который изначально располагается в секции .functions. При этом с помощью ключевого слова asm, символу присваивается иное имя - с префиксом SYS_, которое означает то, что загрузчик эльфа должен пропатчить адреса функций на реальные (которые предварительно зарегистрированы в рантайме) в процессе загрузки программ и таким образом, избежать thunk-функций и позволить оптимизатору легко выкидывать указатели на неиспользуемые функции:

#ifndef LOADER
#define IMPORT(name, ret, ...) __attribute__ ((section(".functions"))) ret (* name )( __VA_ARGS__ ) asm( "SYS_" #name )
#define IMPORTNOARGS(name, ret) __attribute__ ((section(".functions"))) ret (* name )() asm( "SYS_" #name )
#else
#define IMPORT(name, ret, ...) ret name( __VA_ARGS__ )
#define IMPORTNOARGS(name, ret) ret name()
#endif

Что самое забавное, лучший способ отладить эльфлоадер - в QEMU с GDB под Linux. Однако я решил время не терять и отлаживал его сразу на смартфоне с Windows Mobile. А раз WM стал первой поддерживаемой платформой - на нем мы с вами и реализуем рантайм.

❯ Портируем на Windows Mobile (CE)

Поскольку всю жизнь я сижу в основном на Windows, а WinAPI в CE практически полностью копирует десктопную версию, никаких проблем с портированием рантайма не возникло. Единственный выбор который передо мной встал: стоит ли прокидывать stdlib из хост-системы в "эльфятник", или же воспользоваться реализацией newlib в clang/gcc. В процессе портирования на другие платформы выяснилось, что нормально libc реализован, по сути, только на Windows, во все остальных реализациях были лишь самые основные функции по типу malloc, free, memcpy, strcmp и т.п. Поэтому я решил не городить велосипеды и прокинул из хост-системы лишь аллокатор - т.е malloc и free:

// stdlib
IMPORT(elf_malloc, void*, int size);
IMPORT(elf_free, void, void* ptr);
/*IMPORT(elf_strcmp, int, char* str1, char* str2);
IMPORT(elf_strcpy, char*, char* dst, char* src);
IMPORT(elf_strlen, int, char* str);
IMPORT(elf_strstr, char*, char* string, char* substring);
IMPORTNOARGS(elf_rand, int);
IMPORT(elf_memcpy, void*, void* dst, const void* src, uint32_t length);
IMPORT(elf_memset, void*, void* dst, int what, uint32_t length);
IMPORT(elf_memmove, void*, void* dst, void* src, uint32_t length);*/

Далее я сразу решил, что платформозависимые функции для работы с дисплеем использовать не буду и из хост-системы мне нужен будет лишь указатель на фреймбуфер, а блиттинг, рисование текста и прочие операции я реализую сам. На первый взгляд может показаться что это единственное верное решение, однако на практике в некоторых телефонах (Motorola E398, Razr V3) активно использовались 2D GPU от ATI и Nvidia, которые рисуют (BitBLT) изображение значительно быстрее любой программной реализации.

Ниже представлена черновая реализация без преобразования пиксельформатов (поскольку на подавляющем числе телефонов использовался 565) и поддержки прозрачности через колоркей. Её можно оптимизировать до быстрого копирования по сканлайнам через memcpy:

for(i = 0; i < bitmap->Height; i++)
{
for(j = 0; j < bitmap->Width; j++)
{
LCD_PLOT_565(clamp(x + j, 0, lcd->Width), clamp(y + i, 0, lcd->Height), bmp[i * bitmap->Width + j]);
}
}

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

__inline int LcdDrawChar(LcdInfo* lcd, char chr, uint32_t x, uint32_t y, uint16_t color)
{
if(x >= 0 && y >= 0 && x + FONT_WIDTH < lcd->Width && y + FONT_HEIGHT < lcd->Height)
{
int i, j;
unsigned char* glyph = &embedded_font[chr * 8];

for(i = 0; i < FONT_HEIGHT; i++)
{
short* fb = &((short*)lcd->Pixels)[(y + i) * lcd->Width + x];

for(j = 0; j < FONT_WIDTH; j++)
{
if((*glyph >> (FONT_WIDTH - j)) & 0x1)
*fb = color;

fb++;
}

glyph++;
}

return true;
}

return false;
}

void LcdDrawString(LcdInfo* lcd, char* str, uint32_t x, uint32_t y, uint16_t color)
{
SWITCH_CONTEXT;
if(lcd && x >= 0 && y >= 0)
{
unsigned int i;

for(i = 0; i < strlen(str); i++)
{
if(!LcdDrawChar(lcd, str[i], x, y, color))
return; // Out of screen

x += FONT_WIDTH;
}
}
END_CONTEXT;
}

Отладив эльфлоадер, я написал небольшую тестовую программу для вывода картинки и текста:

#include <system.h>

int ElfMain(void* ptr)
{
LcdInfo* lcd = lcdInit();

lcdDrawBitmap(lcd, bitmap, 0, 0);
lcdDrawString(lcd, "Test", 0, 0, COLOR_BLUE)

return 100;
}

И получил следующий результат:

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

❯ Портируем на MRP/MRE

И имя этой платформе, вернее даже двумя платформам - MRP и WRE. Эти платформы использовались на бюджетных китайских телефонах с 2007 по 2016 год. Встретить их можно было везде: легендарная Nokla TV E71/E72, клоны 6700, бюджетные телефоны Fly/Explay/DEXP и даже в оригинальных телефонах Nokia на платформе S30+ (например 230)!

И хотя люди часто считали такие устройства бесполезными в плане установки сторонних приложений, многие ранние "нонейм"-телефоны поддерживали запуск нативных программ через небольшой костыль - установку специального "загрузчика" dsm_gm.mrp и ввод комбинации *#220807# в номеронабиратель. Конечно, знали об этом костыле единицы и в 2010 году MediaTek решила сделать свою платформу под названием MRE (MAUI Runtime Environment), приложения для которой можно было запускать прямо из проводника без установки! SDK для обеих платформ сейчас свободно лежит в сети.

Обе платформы, по сути, занимаются тем же самым, что и мой эльфятник - прокидывают нативные функции MMI (оболочка телефона) в приложения и для загрузки позиционно-независимых программ используют третий подход с регистром R9, который обязательно необходимо где-то хранить и восстанавливать. Изначально мой эльфятник использовал такой же подход, из-за чего я написал отдельный костыль для "свичнга" контекстов, причем восстановление R9 я делал в отдельной функции из-за бага ассемблера в ADS:

#define SWITCH_CONTEXT unsigned int staticBase; __asm { MOV staticBase, sb;
LDR r0, [sb];
MOV sb, r0 }

#define ELF_CONTEXT(ptr) unsigned int staticBase; void* elfStaticBase = ptr; __asm { MOV staticBase, sb; \
MOV r9, elfStaticBase }

#define END_CONTEXT RestoreSB(staticBase);

Но я не учел то, что MMI хоть и построены по event-based принципу, в них нельзя так просто взять и сделать while(true) {}, а необходимо использовать таймеры, что влечет за собой постоянные костыли с свичингом контекстов что по итогу только снижает производительность. По итогу я перешел на релокации и реализовал проброс таймеров.

Во всем остальном, MRP и MRE простые как табуретка, никаких проблем с пробросом ввода и графики не возникло:

LcdInfo* LcdInit()
{
LcdInfo* ret;
ret = (LcdInfo*)malloc(sizeof(LcdInfo));
ret->Width = screenInfo.width;
ret->Height = screenInfo.height;
ret->Pixels = (void*)w_getScreenBuffer();

return ret;
}

void LcdFree()
{

}

void LcdLock(LcdInfo* info)
{

}

void LcdFlush(LcdInfo* info)
{
mrc_refreshScreen(0, 0, 240, 320);
}

И вот, наша программа уже запускается на двух совершенно разных ОС без каких либо проблем!

❯ А если что-то посложнее Hello, world?

Наверняка у читателя возникнет вопрос мол "окей, твой эльфятник может и способен запускать простые программы, но как насчет чего-то посложнее?". И конечно-же, для тестов я решил портировать не абы что, а целый эмулятор NES! В конце-концов, одна из целей разработки такого эльфятника - возможность запускать Java-игр и эмуляторов на многих кнопочных телефонах из нулевых.

Какое то время назад, я обнаружил весьма шустрый эмулятор NES от неизвестного разработчика из Китая. Код был неважного качества, никаких копирайтов в нём не было. Но поскольку сам эмулятор был быстрый (быстрее, наверное, только vNesC, который является прямым source-портом Java-эмулятора vNes на C), я отвязал его от целевой платформы и превратил в небольшую библиотеку для легкого портирования на любые платформы путем вызова всего нескольких функций:

typedef struct {
uint16_t* FrameBuffer;
uint8_t* JoyState;
} emuContext;

emuContext* emuInitialize();
uint8_t emuLoadROM(void* rom, int length);
void emuReset();
void emuDoFrame();
void emuShutdown();

И, соответственно, базовый порт на наш эльфятник выглядит примерно так:

#include <string.h>

#define FUNC_PROTOTYPES
#include <system.h>

#include <nes.h>
#include "nes_rom.h"

emu_context* ctx;
LcdInfo* lcdInfo;

void EmuTick()
{
emuDoFrame();

LcdLock(lcdInfo);
short* pixels = (short*)lcdInfo->Pixels;

for(int i = 0; i < EMU_FRAMEBUFFER_HEIGHT; i++)
{
memcpy(&pixels[i * lcdInfo->Width], &ctx->FrameBuffer[i * EMU_FRAMEBUFFER_WIDTH], lcdInfo->Width * 2);
}

LcdFlush(lcdInfo);

}

void EmuSetupTimer()
{
TimerAttach(1, EmuTick); // As fast as possible
}

void EmuSetupRegularLoop()
{
while(true)
EmuTick(); // TODO: If elfloader port will be usable on Android, add FPS limit :)
}

int ElfMain(unsigned int* basePtr, void* test)
{
lcdInfo = LcdInit();

ctx = emuInitialize();
if(!emuLoadROM(nes_rom, sizeof(nes_rom)))
{
UtilPrint("Failed to load ROM");
return 100;
}

emuReset();

switch(GetMainLoopType())
{
case PLATFORM_LOOP_MMI_TIMER:
EmuSetupTimer();
break;
case PLATFORM_LOOP_REGULAR:
EmuSetupRegularLoop();
break;
}

return 100;
}

А вот и результат:

❯ Заключение

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

А если вам интересна тематика ремонта, моддинга и программирования для гаджетов прошлых лет — подписывайтесь на мой Telegram-канал «Клуб фанатов балдежа», куда я выкладываю бэкстейджи статей, ссылки на новые статьи и видео, а также иногда выкладываю полезные посты и щитпостю. А ролики (не всегда дублирующие статью) можно найти на моём YouTube канале.

Очень важно! Разыскиваются девайсы для будущих статей!

Друзья! Если вам понравилась сегодняшняя статья про разработку эльфов, то спешу объявить: для подготовки будущих материалов с разработкой самопальных игрушек под необычные устройства, объявляется розыск телефонов и консолей! В 2000-х годах, китайцы часто делали дешевые телефоны с игровым уклоном — обычно у них было подобие геймпада (джойстика) или хотя бы две кнопки с верхней части устройства, выполняющие функцию A/B, а также предустановлены эмуляторы NES/Sega. Фишка в том, что на таких телефонах можно выполнять нативный код и портировать на них новые эмуляторы, чем я сейчас занимаюсь, а затем написать об этом подробную статью и записать видео! Если у вас есть телефон подобного формата и вы готовы его задонатить или продать, пожалуйста напишите мне в Telegram (@monobogdan) или в комментарии. Также интересуют смартфоны-консоли на Android (на рынке РФ точно была Func Much-01), там будет контент чуточку другого формата :)

А также я ищу старые (2010-2014) подделки на брендовые смартфоны Samsung, Apple и т. п. Они зачастую работают на весьма интересных чипсетах и поддаются хорошему моддингу, парочку статей уже вышло, но у меня ещё есть идеи по их моддингу! Также может у кого-то остались самые первые смартфоны Xiaomi (серии Mi), Meizu (ещё на Exynos) или телефоны на Linux (например Motorola EM30, RAZR V8, ROKR Z6, ROKR E2, ROKR E5, ZINE ZN5 и т. п., о них я хотел бы подготовить специальную статью и видео т. к. на самом деле они работали на очень мощных для своих лет процессорах, поддавались серьезному моддингу и были способны запустить даже Quake!). Всем большое спасибо за донаты!

Осторожно: в статье я постарался подробно и простым языком написать об аппаратном моддинге и ковыряние в железе, хакинге Linux и обходе проприетарной оболочки, а также программировании и портировании софта с других платформ. Но есть нюанс...

Я очень большой фанат портативных гаджетов с полноценными QWERTY-клавиатурами: ноутбуков, коммуникаторов и различных хэндхелдов. Когда в мои руки попадает девайс с Linux или Windows CE в том или ином виде, я стараюсь максимально расширить функционал устройства и порой даже портирую программы с других платформ! Недавно мне удалось купить китайский детский обучающий ноутбук с MIPS-процессором и поворотным дисплеем всего за 1 000 рублей. Интересно узнать о том, как я хакнул девайс и причём здесь Dingoo A320? Тогда жду вас под катом!

❯ Предыстория

В конце 2000-х годов, цена на бюджетные ноутбуки снизилась настолько, что купить полноценный лэптоп мог почти каждый студент. Если в начале нулевых годов миниатюрность была роскошью и стоила довольно дорого по отношению к обычным 15-дюймовым бюджетникам, то с выходом Asus EEEPC в 2007 году, маленькие нетбуки с 7-дюймовыми дисплеями наоборот образовали новый сегмент рынка недорогих портативных устройств.

Сейчас мы с вами привыкли, что большинство ноутбуков работает на базе процессоров с двумя архитектурами — x86_64 и ARM. Однако в те времена, инженеры и производители активно экспериментировали и с альтернативными архитектурами — например, MIPS. В 2009 году, некая китайская компания Noah Educational Holdings, которая занималась разработкой портативных устройств для обучения дошколят и школьников младших классов, выпустила на рынок свой собственный миниатюрный обучающий ноутбук — Noah NP5000.

Обычно, когда читатель слышит «детский ноутбук», он представляет себе небольшое устройство с почти полноценной QWERTY-клавиатурой, небольшим монохромным ЖК-дисплеем и набором некоторых обучающих программ. При этом замоддить такие устройства не представляется возможным — в них используются микроконтроллеры с масочной ROM (прожигаемой на заводе), которые скорее всего являются близкими родственниками процессоров тех самых Тетрисов!

Однако в случае с NP5000 всё было совершенно по другому — дисплей здесь уже цветной, а не монохромный, вместо батареек используется полноценный аккумулятор, да и в целом девайс выглядит действительно как взрослый миниатюрный нетбук с поворотным экраном! При включении пользователя встречает заставка с логотипом компании и характерным пингвинчиком, рабочий стол, напоминающий Windows XP и определенный набор обучающих программ на китайском языке.

В один день я листал Goofish (китайский аналог Авито) в поисках интересных гаджетов, именно пингвинчик и привлёк моё внимание. Информации о том, на каком процессоре работает ноутбук, можно ли на него устанавливать сторонние приложения и что он вообще умеет в сети не было. Однако приятная цена в 1 000 рублей и желание заполучить интересный девайс в коллекцию взяли верх — и я решил рискнуть!

Когда девайс приехал ко мне, я немного поковырял его родную оболочку, попытался выйти в терминал, поставить пакеты OpenWRT — но всё тщетно, оболочка тщательно была закрыта от ушлых детских ручек! Поэтому я решил разобрать девайс и узнать, на каком процессоре он работает и есть ли у нас UART, на котором можно поискать рут-консоль или хотя-бы консоль U-Boot.

Девайс помог привезти в Россию мой подписчик Роман и сервис YouCanBuy, за что им огромное спасибо! Также этой статьи не было бы без подписчика Андрея, который занял мне определенную сумму для заказа ништячков из Китая, за что ему отдельная благодарность!

❯ Что внутри?

Разбирается маленький нетбук почти также, как и его взрослые собратья — через клавиатуру! Со стороны поддона виднеется съёмная крышка, которая на x86-устройстве должна содержать в себе место под HDD и слоты для оперативной памяти. Однако в нашем случае, здесь скрывается кое-что поинтереснее: видите характерное место под миниджек с подписанными пинами RX и TX? Это и есть UART, о котором я говорил в прошлом абзаце.

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

В качестве процессора используется легендарный Ingenic JZ4757! Это готовая система на кристалле, включающая в себя MIPS-ядро собственной разработки с микроархитектурой XBurst, работающее на частоте до 380МГц, видеоконтроллер с возможностью вывода картинки на дисплей или телевизор, аудиокодек, USB-хост и т. п. Слева от процессора расположились два чипа ОЗУ типа SDRAM, в сумме образующие 64Мб, а чуть ниже распаяна NAND-флэшка от компании Samsung на 2Гб. Справа снизу «спрятался» чип часов реального времени — с которого при желании можно было бы взять шину I2C!

Я не зря назвал процессоры от Ingenic легендарными. Дело в том что именно JZ'шки использовались во многих легендарных портативных гаджетах нулевых годов. Например, JZ4732 использовался в популярной эмуляторной игровой консоли Dingoo A320, а JZ4725 использовался в журнале Vogue с экранчиком и OpenHardware-ноутбуке Ben NanoNote. Ingenic славились своей открытостью к сообществу моддеров и свободно предоставляла исходный код ядра Linux, BSP для Windows CE и даже код своей проприетарной прошивки для MP4-плееров!

Далее я решил подпаяться к UART'у, дабы почитать что у нас туда пишет система. Вне зависимости от чипсета или устройства, довольно часто на UART летят логи загрузчика и ядра, а иногда на нём можно найти и рутовую консоль. Благодаря такому «бэкдору» можно попытаться хакнуть самые разные устройства: например, тонкие клиенты на процессорах Marvell или незамысловатый ТВ-бокс. В качестве USB-UART преобразователя я использую плату с ESP32 с постоянным RESET'ом на микроконтроллере (дабы не вмешивался в работу шины):

❯ Хакаем

Далее я включил ноутбук, настроил Putty на свой COM-порт с бодрейтом 115200 и увидел логи. Выяснилось что в качестве загрузчика используется всеми любимый U-Boot (в котором нельзя прервать процесс загрузки), а в качестве ядра — Linux версии аж 2.6! И конечно же на этом терминале висела полноценная рут-консоль!

Далее я сразу решил проверить с какой системой мне придется иметь дело: заглянул в top, обнаружив что используется оболочка Qtopia (формальная альтернатива Xorg и DirectFB для КПК на Linux), пошерстил по папкам с бинарниками и посмотрел inittab. Наша задача — заставить ноутбук запускаться с текстовым терминалом на дисплее, а Qtopia запускать уже по желанию.

Сначала я закомментировал запуск Qtopia в скрипте автозагрузки - inittab'е. Однако если просто «прибить» оболочку — после включения ноутбука нас будет встречать пустой экран без какого либо взаимодействия. Поскольку у меня не было возможности изменить cmdline ядра и перенаправить консоль на терминал fbcon, я решил это сделать уже в юзерспейсе с помощью системного вызова TIOCCONS, однако он по каким-то причинам выдавал ошибку. Тогда пришлось немного костылить и дублировать терминал с помощью getty:

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

❯ Портируем эмуляторы

Далее я решил попробовать портировать эмуляторы с родственной данному ноутбуку Dingoo A320. В родной системе почти никакие эмуляторы не работали даже после подкидывания всех необходимых библиотек (в том числе и uclibc с SDL), однако после chroot'а в систему от Dingoo A320 у меня запустились часть эмуляторов. Однако в этом ноутбуке используется оригинальный непропатченный кривой драйвер фреймбуфера, который постоянно сыпет ошибками и не умеет работать в виртуальном разрешении. Из-за этого, часть эмуляторов выглядело... примерно вот так:

А часть вот так:

И я понял что без патчей в исходном коде не обойтись. Для сборки программ под старые Linux-машины, кросс-компилятор из репозиториев свежих дистрибутивов не подойдет — слишком новая версия glibc. Более того, некоторые устройства могут использовать uclibc вместо glibc, как, например, та же самая динга. Поэтому может потребоваться установка уже готового тулчейна — благо для динги он сохранился в сети. Распаковываем архив в /opt/, добавляем в переменную PATH путь к папке bin/ и пробуем собирать тестовую программу. Всё работает!

Далее предстояло найти исходный код эмуляторов для динги. Часть из них можно найти на гите (в качестве портов на GCW-Zero), часть — на сайте OpenHandhelds. Первым дело я решил портировать эмулятор GameBoy Color. Поскольку эмулятор работает поверх библиотеки SDL, в первую очередь я изменил видеорежим с 240x320 на 800x480...

И ожидаемо ничего не получил, никто растягивать картинку за меня не будет! Поэтому я сначала написал простейшую функцию скейлинга картинки на флоатах с заранее посчитанным шагом интерполяции, затем оптимизировал её до fixed-point арифметики, а после и вовсе решил «запечь» координаты для сэмплинга в один большой массив.

Крайний вариант был самым быстрым, однако в нативном разрешении ноутбука я получил примерно 50%-скорости от реальной консоли — т. е., по сути, не играбельно. При этом в видеорежиме 240x320 всё работало нормально и упор был явно не в скорость растягивания картинки... по каким-то причинам либо блиттер SDL работал слишком медленно, либо драйвер фреймбуфера спотыкался об преобразование форматов пикселя из-за чего всё и тормозило.

Далее я решил попробовать запустить другие эмуляторы. NES, Sega Master System и другие консоли работали отлично... пока я не устанавливал разрешение выше 240x320. Ради интереса, я запустил оболочку для Linux-консолей gmenu2x с Ben NanoNote, которая вместо SDL использует DirectFB и получил вот такую картину. Epic fail...

После этого я решил попробовать накатить всем известный Debian. В отличии от эмуляторов, здесь пересобирать ничего не нужно: достаточно лишь собрать rootfs с необходимыми пакетами, отформатировать SD-карточку и chroot'унутся в систему. Для сборки можно использовать две утилиты — debootstrap и multistrap:

Сначала я хотел накатить что-то относительно современное по типу Debian Buster или Jessie, однако вскоре выяснилось, что ядро 2.6 эти версии системы не поддерживают...

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

Далее мне удалось подкинуть некоторые пакеты и даже попытаться запустить иксы (на 64Мб ОЗУ!)... но затем я погряз в зависимостях и всё таки решил попытаться подкинуть сеть. Выяснилось что в ядре есть поддержка встроенного в чипсет Ethernet-контроллера, однако PHY на плате то не распаян!

❯ Заключение

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

А вам надеюсь было интересно почитать мой опыт моддинга такого замечательного девайса. Пишите своё мнение в комментариях! Если вам интересна тематика ремонта, моддинга и программирования для гаджетов прошлых лет, подписывайтесь на мой Telegram-канал «Клуб фанатов балдежа», куда я публикую бэкстейджи статей, иногда полезные посты ну и немножечко щитпоста! Если вам интересны мои видео той же тематики — предлагаю подписаться на мой YouTube-канал.

Очень важно! Разыскиваются девайсы для будущих статей!

Друзья! Для подготовки статей с разработкой самопальных игрушек под необычные устройства, объявляется розыск телефонов и консолей! В 2000-х годах, китайцы часто делали дешевые телефоны с игровым уклоном — обычно у них было подобие геймпада (джойстика) или хотя бы две кнопки с верхней части устройства, выполняющие функцию A/B, а также предустановлены эмуляторы NES/Sega. Фишка в том, что на таких телефонах можно выполнять нативный код и портировать на них новые эмуляторы, чем я и хочу заняться и написать об этом подробную статью и записать видео! Если у вас есть телефон подобного формата и вы готовы его задонатить или продать, пожалуйста напишите мне в Telegram (@monobogdan) или в комментарии. Также интересуют смартфоны-консоли на Android (на рынке РФ точно была Func Much-01), там будет контент чуточку другого формата :)

А также я ищу старые (2010-2014) подделки на брендовые смартфоны Samsung, Apple и т. п. Они зачастую работают на весьма интересных чипсетах и поддаются хорошему моддингу, парочку статей уже вышло, но у меня ещё есть идеи по их моддингу! Также может у кого-то остались самые первые смартфоны Xiaomi (серии Mi), Meizu (ещё на Exynos) или телефоны Motorola на Linux (например, EM30, RAZR V8, ROKR Z6, ROKR E2, ROKR E5, ZINE ZN5 и т.п, о них я хотел бы подготовить специальную статью и видео т. к. на самом деле они работали на очень мощных для своих лет процессорах, поддавались серьезному моддингу и были способны запустить даже Quake!). Всем большое спасибо за донаты!

А ещё я держу все свои мобилы в одной корзине при себе (в смысле, все проекты у одного облачного провайдера) — Timeweb. Потому нагло рекомендую то, чем пользуюсь сам — вэлкам:

Приветствую! В сегодняшнем материале мы опробуем с вами новый формат статей, а именно — «ретрошортсы». В этой рубрике будем вкратце вспоминать крутые гиковские штуки прошлых лет, и конкретно сегодня — тот самый журнал Vogue от декабря 2010 года с внешним дисплейчиком, на который можно было накатить Linux и получить мини-компьютер буквально за 200 рублей. Если вам интересно, что за девайс придумали в далеком 2009 году, причём здесь игровые консоли и как бородатые 30-летние хабровчане бегали по всей Москве в поисках ставшего дефицитным женского журнала, то добро пожаловать под кат!

❯ Предыстория

Недавно я писал ретроспективную статью о такой замечательной гиковской консоли, как Ritmix RZX-50. Устройство, построенное на MIPS чипсете Ingenic JZ4750 отличалось относительно низкой ценой, наличием официального SDK для разработки хоумбрю и использованием Linux-дистрибутива OpenDingux в качестве операционной системы. Консоль презентовалась как разработанная моддерами для моддеров — и за исключением аппаратной платформы разработки KohoTech (также известной Android-консолями JXD, которые продавались в РФ под брендами Smaggi, EXEQ и т. д.), в целом, оно так и было.

Но причем здесь игровые консоли, спросит читатель? Дело в том, что примерно в середине 2000-х годов начал появляться такой класс устройств, как дешевые mp4-плееры. Когда техпроцесс позволил уместить в один кристалл мощное вычислительное ядро, DSP/ISP для декодирования (и кодирования) видео и аудио на лету, а также контроллер дисплея с аппаратным ускорением отрисовки 2D-графики, чипмейкеры представили по сути уже готовые решения для реализации собственных портативных плееров. Под готовыми подразумевается не только аппаратная часть устройств, но и программная — инженеры писали собственные прошивки на базе RTOS-ядер, которые включали в себя уже готовый видео-плеер, аудио-плеер, а также приложения по типу просмотра изображений и чтения книг. По сути, производителю самого плеера оставалось лишь развести плату на основе референсной и чуть приукрасить интерфейс, что и обуславливало низкую цену таких устройств.

Примерно к 2006-2007 году, на базе таких чипсетов начали делать эмуляторные игровые консоли, а в 2009 году вышла легендарная в моддерских кругах Dingoo A320 на базе MIPS-чипсета Ingenic JZ4732. Изначально консоль работала на базе собственной проприетарной ОС внутренней разработки Ingenic (кому интересно, можете поколупать исходный код здесь), однако затем один испанский инженер заметил, что A320 основана на базе референсной платы Ingenic с кодовым именем Caetus, которая из коробки работает на Linux и о чудо, нормально работает с ядром для референсной платы! После этого, к ядру подсунули дистрибутив OpenWRT (и скорее всего адаптировали драйвер дисплея — в динге использовался дисплей с 8080-шиной на базе контроллера ILI9341/9325) и он замечательно заработал на A320'ой. Так и появился кастомный Linux-дистрибутив для консолей и плееров на базе чипсетов Ingenic под названием OpenDingux. Кроме того, Ingenic не стеснялись делится PDK для своих чипсетов: на FTP-сервере компании лежали BSP для Windows CE и Linux.

В 2009 году компания AmeriChip разработала технологию Video in Print, позволявшую в обычном бумажном журнале разместить специальную картонную страницу с миниатюрным экранчиком, который воспроизводит видео при открытии этой самой страницы. Очевидно что целевая аудитория технологии — реклама «мажорных» брендов, которые могут оплатить установку такого плеера в определенный тираж журнала, цена которого в несколько раз превышает себестоимость самого печатного издания. В Россию эта технология пришла аж в в конце 2010 года, когда бренд напитков Martini решил сделать крутую рекламу для женской ЦА в рамках декабрьского выпуска журнала Vogue. В обычном бумажном журнале за ~200 рублей разместился дисплейчик, который воспроизводит видео со звуком! Когда об этом узнали на Хабре, начался лютый ажиотаж вокруг журнала и бородатые 30-летние дядьки, одним из которых был @dlinyj, ранним утром побежали сметать журналы с полок магазинов.

Нетрудно представить, какими удивленными были лица продавцов, когда к ним целыми днями бегали мужики в погоне за женским журналом! Поскольку журнал хотели все, но далеко не весь тираж был с теми самыми дисплейчиками, некоторые ушлые ребята начали продавать их втридорога (это касалось и розничных магазинов), а иногда и отправлять их в другие страны. При препарировании страницы оказалось, что каждый плеер собирается вручную «на соплях» и работает на базе чипсета Ingenic JZ4725B, для старших версий которого, как мы помним, есть порт Linux! По сути, этот плеер являлся кровным братом тех самых игровых консолей Dingoo A320 и Ritmix RZX-50!

Изначально страница использовала прошивку «minios» с нужным видеороликом в памяти устройства, но коммьюнити хотелось запустить, конечно же, Linux. Ядро с Dingoo A320 удалось запустить не сразу. Дело в том, что у чипсета отсутствует часть периферии с более старших моделей (например, нет USB-хоста), из-за чего пришлось патчить драйверы, а также использовались другие пины (и в целом шина) для подключения дисплея к чипу. Благо даташит сразу же «слили» в сеть, а сам процессор был выполнен в QFP-корпусе, так что необходимые пины почти сразу вызвонили и смогли запустить на журнале... полноценный Linux!

Свои два Vogue я получил в подарок от хабровчан, за что вам огромное спасибо :) Давайте же посмотрим, что скрывается у них «под капотом».

❯ Под капотом

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

Начинаем с самой материнской платы устройства. Как уже было упомянуто выше, девайс использует MIPS-чипсет Ingenic JZ4725B, работающий на частоте 360МГц. Насколько я понимваю, это один из самых бюджетных чипов этой серии и не умеет в вышеупомянутый USB-хост, что значительно сужает круг применения такого девайса на практике. Рядом с чипсетом установлена банка SDRAM-памяти на 32Мб, а также NAND-флэшка объемом в 1Гб. Хотя казалось бы, плеер предполагается «одноразовым» (посмотрел рекламу и забыл), но на плате разведен в том числе и чарджер литий-ионных АКБ, а также выведены пины для USB-клиента.

На нижней части платы можно заметить место для нераспаянных аппаратных кнопок. Всего их здесь 6, так что с минимальной пайкой из плеера можно сделать, например, эмулятор GameBoy или NES. Из внешних шин на плате доступен только UART, который благодаря пинмуксингу «висит» на одной из аппаратных кнопок — так что если захочется подключить устройство к МК, то придётся выпаивать SMD-конденсатор над кнопкой K2. В целом, это не значит что к девайсу нельзя подключить клавиатуру или мышь, просто для них придется делать отдельный переходник на МК, который будет слать кейкоды через UART в input-драйвер устройства. Таким образом можно подключить HID-клавиатуру или геймпад, но без прослойки — никуда :(

Сам USB удивляет не меньше: он распаян отдельно, используется MiniUSB на небольшой breakout-плате, которая посажена на клей-соплю. На стоковой прошивке при попытке подключить девайс к ПК, устройство требует ввод «кода», дабы хитрые ручонки не подменяли видеоролики на свои и не пользовались плеером для личных целей.

Снизу мы видим довольно большой динамик, а также литий-ионный аккумулятор на 800мАч. Учитывая что журнальчики после прочтения нередко отправляются на чердак, где маринуются под палящим летним солнцем, решение странное — АКБ может и воспламениться.

А сверху мы видим тот самый дисплейчик. Это TN-матрица с разрешением 480x232 и интерфейсом TTL, 40 pin. Такие же использовались в GPS-навигаторах, вышеупомянутой RZX-50 и других самых разных консолях! Если у вас есть девайс с разбитым 40-pin дисплеем, то его вполне можно взять с Vogue и поставить — он должен заработать «из коробки».

И конечно же, с левой стороны нас ждёт что-то типа концевого выключателя, который и выводит плеер из режима сна и заставляет воспроизвести видеоролик и динамик.

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

❯ Запускаем

Подключаем USB-кабель, девайс промаргивается и... мы видим вывод kmsg! На моём экземпляре уже была установлена прошивка Vogeeky, основная на OpenWRT и девайс загрузился, показав готовность к работе.

Взаимодействовать с ним предлагается с помощью всё того же USB: плеер «прикидывается» сетевой картой и позволяет подключиться к SSH с помощью нескольких команд:

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

Однако никто не мешает накатить на девайс программы и эмуляторы для того же самого Dingux. Они будут здесь работать, но скорее всего придется ремаппить GPIO аппаратных кнопок в драйвере ввода. Драйвер кейпада, разработанный сообществом вполне работает — в kmsg даже летят дебаг-сообщения от единственной выведенной кнопки устройства (не забываем про места под кнопки с нижней части платы).

В целом, развитие моддинг-сцены девайса остановилось на Proof of Concept: участники проекта Vogeeky смогли запустить на устройстве Linux, однако найти интересное применение, кроме плеера, к сожалению не смогли. Но это не значит, что девайс бесполезен. С минимальными навыками пайки и программирования, из девайса можно сделать:

• Стационарные часы с ЖК-дисплеем, будильником и подтягиванием погоды по сети.

• Игровую консоль. Но опять же, число аппаратных кнопок ограничено — без доработок у нас максимум будет GameBoy/NES и другие консоли с геймпадами на 6 кнопок.

• Мини-ноутбук. Если я созрею для этого проекта, то расскажу о превращении журнала в миниатюрный лэптоп с апгрейдом дисплея и подключением клавиатуры через UART с запилом кастомного драйвера :)

• Собственно, плеер, только умеющий играть и произвольные видеоролики и аудиофайлы.

❯ Заключение

Вот такой интересный материал у нас с вами получился про легендарный бумжаный журнал на Linux. Надеюсь, молодым читателям было интересно узнать что-то новое, а олдам Хабра было интересно вспомнить тот ажиотаж и те хабратортные статьи, что породил журнал!

Подписывайтесь на мой Telegram-канал, если вам интересна тематика программирования, моддинга и подручного ремонта различных девайсов, а если вам интересны мои видео о ретро-девайсах, то подписывайтесь на мой YouTube или паблик ВК.

А ещё я держу все свои мобилы в одной корзине при себе (в смысле, все проекты у одного облачного провайдера) — Timeweb. Потому нагло рекомендую то, чем пользуюсь сам — вэлкам:

Я большой фанат Linux на мобильных системах и давно слежу за такими проектами, как Meego, Maemo и конечно же, Sailfish-подобными ОС. Недавно я самолично написал в компанию F+ и попросил какой-нибудь смартфон на «Авроре» для статьи и на моё удивление, представители компании согласились! Что из себя представляет R570E, какова «Аврора» с точки зрения обычного пользователя, какие проблемы могут возникнуть у разработчика и есть ли у этой системы перспективы? Читайте в сегодняшней статье!

❯ Предисловие

Пожалуй сейчас Linux'ом на смартфонах и мобильных системах никого не удивить. Ядро Linux используется в ОС Android, благодаря чему хотя бы одно устройство с пингвином на борту можно найти почти в каждом доме. Однако Android использует именно само ядро Linux, выстраивая вокруг него собственное пользовательское окружение (или более корректно — userspace): подсистема абстракции от железа (HAL), оконная система и фреймворк для приложений. На десктопных же системах используется стек, известный как GNU/Linux, предоставляющий этакое знакомое нам unix-окружение со стандартным набором программ, glibc и компилятором GCC. При этом Android абсолютно не совместим с программами, собранными для обычных GNU/Linux систем как раз таки из-за преусловутой glibc (вместо неё в Android используется bionic и свой собственный динамический линкер), и поэтому многие гики хотят запустить полноценный дистрибутив на мобильном устройстве.

Но благодаря тому, что ядро Linux распространяется по лицензии GPL3, производители смартфонов обязаны открывать исходный код своих модификаций ядра под собственные устройства. И пока развивалась моддинг-сцена Android с такими кастомами, как CyanogenMod или, например, MIUI, на некоторые устройства выходили такие диковинные системы, как Ubuntu Touch, pmOS и, конечно же, Sailfish OS.

Linux на мобильных устройствах берёт своё начало ещё с середины 2000-х годов. Именно в это время компания Motorola решила использовать в своих продвинутых устройствах ядро Linux, а если более конкретно — построить собственную оболочку Motorola EZX на базе MontaVista Linux. Немудрено, что систему быстро хакнули и наделали для неё кастомного софта, патчей и других примочек. Примерно в тоже самое время компания Nokia начала развивать линейку собственных интернет-планшетов на базе дистрибутива Linux под названием Maemo.

В 2007 году на свет появился первый полностью открытый смартфон (в том числе и с аппаратной точки зрения — то есть принципиальная схема, разведенная плата и иные необходимые для постановки устройства на конвейер документы) Neo 1973, построенный на базе хакнутого проектом OsmocomBB модема TI Calypso и ОС OpenMoko, который получил умеренный успех среди Linux-гиков. А в 2009 году вышел легендарный Linux-смартфон Nokia N900, который до сих пор считается одним из самых удачных и успешных гиковских смартфонов из когда-либо выпущенных.

И вот в 2011 году Nokia, почти полностью перешедшая на Windows Phone и остановившая развитие Symbian, выпускает свой последний гиковский смартфон — Nokia N9, который в некоторых аспектах стал «батей» многих фишек в современных смартфонах. Несмотря на популярное заблуждение, N9 работает не на Meego, а на Maemo со значительно доработанным пользовательским интерфейсом. И как раз UI устройства был крайне необычным и на своё время прорывным: управление системой жестами, наличие двух всегда доступных страниц, своё видение шторки уведомлений и очень плавная работа. Когда стало ясно, что Nokia больше не будет выпускать Linux-смартфоны, несколько инженеров компании основали свою собственную фирму Jolla и продолжили развивать Meego для полноценного запуска на Nokia N9. Результатом их работы стала новая система — Sailfish OS.

Основной фишкой системы было наличие инкрементальных обновлений, возможность разработки приложений с использованием Qt (т. е в отличии от Android, все приложения и подсистемы полностью нативные, а не написаны на Java), и довольно неплохая совместимость с обычным ARM-софтом для других дистрибутивов Linux. Со временем Ростелеком увидел перспективы в Sailfish OS и выкупил долю в компании, начав работу над своим собственным форком этой системы — ОС «Аврора». С годами «Аврора» полностью отделилась от материнского проекта и начала развитие в другом направлении: если Sailfish OS была системой для гиков и просто пользователей, то «Аврора» больше нацелена на Enterprise-сегмент (т. е. «госка»), на гиков и только потом на конечных пользователей.

И мне, как фанату Linux на мобильных устройствах, очень хотелось пощупать и заполучить свой собственный девайс на этой ОС. Набравшись смелости, я написал в PR-отдел F+ и через пару недель получил положительный ответ. Радости моей не было предела! Но когда девайс пришёл ко мне, начались определенные трудности...

❯ Распаковка

Начать стоит с распаковки девайса. Ко мне смартфон пришёл «не новым», его уже распаковали и накатили на него некоторые тестовые приложения для внутренних нужд PR-отдела. Кроме того, у меня стоит «особенная» версия Авроры 5.1, доступная пока ещё не всем пользователям.

В коробке нас встречает сам девайс, защитное стекло (девайс всё таки защищенный) на дисплей, краткий мануал по использованию «Авроры» (в кои-то веки он нужен!), а также скрепка, Type-C кабель и 5В/2А блок питания. В рознице к девайсу прилагаются ещё и TWS-наушники.

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

После включения нас встречает логотип «Авроры», а затем и предложение ввода пин-кода (есть также сканер отпечатков пальца). Enterprise-направленность девайса видна сразу: MDM-политики, возможность удаленного бана украденного устройства по ключу активации системы и возможность добавления своих репозиториев с софтом помимо возможности установки RPM и использования стандартных репозиториев ОМП.

Характеристики девайса следующие:

• Процессор: MediaTek Helio A25. 2020 год, 8 ядер Cortex-A53 на частоте от 1.5 до 1.8ГГц (пламенный привет MT6753 в любимых мной китайских айфонах). В целом, это довольно бодрый по меркам бюджетника чипсет, именно A25 сейчас частый гость на смартфонах до 5-6 тысяч рублей.

• GPU: PowerVR GE8320 на частоте 600МГц. В целом, GPU можно назвать гордостью девайса: и если с 3D-играми на Авроре и Sailfish вяло, то для эмуляторов даже относительно тяжелых консолей он подойдет замечательно.

• Память: eMCP «бутерброд» с 4Гб предположительно LPDDR4 оперативной памяти и 64Гб eMMC 5.1 постоянной памяти. UFS-флэшки чипсет не поддерживает в силу своей бюджетности.

• Дисплей: 5.7" IPS HD+ матрица. Вполне годная, очень похожа на матрицу моего китайского айфона, есть ощущение что на современных бюджетниках используется +- похожие дисплеи.

• Звук: есть 3.5мм джек! Это настолько редкость сейчас, что я выделил эту фичу в отдельный пункт.

• Сеть: Wi-Fi a/b/g/n ac, Bluetooth 5.0, 2G, 3G, LTE. Стандартный минимальный набор.

• Камера: 13Мп + 2Мп

• Аккумулятор: 5080мАч, литий-полимерный. Для броневика ёмкость средненькая.

В целом, аппаратно R570E - больше классический китайский OEM-смартфон на привычной MediaTek'овской платформе. Мне говорили, что есть какие-то изменения в плате "под капотом", однако девайс я пока не разбирал. Если F+ выложит в общий доступ схему устройства, то смартфон сможет похвастаться ещё и повышенной ремонтопригодностью, что очень актуально как для шаловливых энтузиастких ручек, так и для компаний, закупивших девайс для бизнеса. В целом, как по мне, — характеристики вполне неплохие, но стоит иметь в виду, что я почти всю жизнь пользовался бюджетными девайсами и выжимал из них все соки, так что мне привычно доводить девайс до идеала и после покупки.

Но в случае R570E, самое важное в девайсе — это «Аврора». И на её пользовательские качества мы сейчас с вами и посмотрим.

❯ Знакомимся поближе

Сначала предлагаю взглянуть на «пользовательскую» часть системы. Недавно пользователям начали прилетать апдейты с «РуСтором» на борту (в бета-ветке), однако мой смартфончик пока что обделен этим обновлением. Об этом чуть позже.

Как и «батя» в лице Sailfish OS, «Аврора» управляется полностью жестами. Некоторые обзорщики сравнивают UI Авроры как «украденный у Android и iOS», однако это не так: корни интерфейса уходят в Nokia N9, из которого как раз все всё и позаимствовали спустя почти 10 лет. Несмотря на бюджетный 4-х летний чипсет, девайс работает очень плавно и у него есть адекватная многозадачность.

По умолчанию в системе предустановлен классический набор приложений, плюс ярлыки PWA можно выносить на рабочий стол. К слову о браузере — здесь используется Firefox 78 (2020 год) с самопальным интерфейсом, который всё ещё открывает большинство сайтов, но стремительно теряет актуальность. С апдейтами обещали обновить и WebView, едва-ли 78'ой останется актуальным в 2025 году.

R570E неплохо подходит и по основному предназначению (т. е. как телефон): номеронабиратель удобный, есть импорт контактов из Exchange, vcf-файлов и других телефонов. Что ещё, собственно, нужно? Приложение для обмена SMS самое обычное, ничего примечательного.

Само собой есть встроенный плеер для прослушивания музыки. Из-за броненаправленности смартфона, мне не удалось нормально подключить мои основные полноразмерные наушники, но в целом качество ЦАПа... на уровне остальных смартфонов с MTK на борту: нормально, но после флагманских BlackBerry с ЦАП'ом Wolfson, смартфонов Sony или ZTE Axon с аж двумя отдельными аудиотрактами (!) хочется вернуться всё же к флагманам: А вот что в плеере не понравилось, так это отсутствие эквалайзера: плеер совсем простенький.

В целом, понравился клиент почты. Есть интеграция с российскими сервисами, плюс поддержка POP3/IMAP-ящиков. Сам клиент шустрый и удобный. Единственный момент - не работает поиск по всему ящику, только по синхронизированным сообщениям и не сразу заработал SMTP gmail'а.

Поговорим о камере. Модуль здесь бюджетный, на уровне флагманских смартфонов эдак года 2013-2014. По качеству выдает картинку близкую к Galaxy S2-S3, но немного не хватает цветокоррекции. Макро тоже у смартфона получается "с трудом", по крайней мере в авторежиме. Правда всё это можно объяснить тем, что для камеры у MTK есть куча блобов с различными алгоритмами для улучшения изображения, и эти блобы разработаны для использования с Android и возможно Аврора использует лишь самый простой вариант захвата изображения с камеры:

Также я накатил клиент Telegram «Tavro» на базе библиотеки TDlib, который вполне неплох... однако его полная версия платная. Впрочем, подразумевается что полная версия «Тавро» предназначена для бизнеса. Если будет наблюдатся тенденция с платным жизненноважным софтом на «Авроре» — то система точно не станет популяряной у обычных пользователей. А ещё Тавро лагучий и если пару дней не открывать Telegram, то синхронизация большого числа изменений может занять пару минут, а интерфейс будет висеть.

Также я хотел написать вторую статью о разработке небольшой 3D-аркады с нуля под «Аврору», однако возникли определенные трудности о которых я и говорил в начале статьи. Дело в том, что на мой смартфон установлена немножко «особенная» версия ОС, где режим разработчика (отладчик и ещё некоторые фичи) просто сломан. Пакет (сломанный) уже установлен, однако не удаляется, не обновляется и не устанавливается. В моём случае можно только сделать бэкап и прошить дамп чистой системы с 4pda, благо такая возможность есть.

Тем не менее, даже несмотря на «поломанность», есть возможность установки сторонних приложений. Просто включаем соответствующую галку в настройках — и вот, мы можем ставить сторонние rpm-пакеты прям как apk в Android.

В целом, «Аврору» можно назвать достаточно открытой для моддинга и разработки собственных программ системой. За деплой приложений не нужно ничего платить, есть неплохая документация и можно делать с системой всё что угодно из терминала: благо root-доступ есть из коробки для всех. Я немного общался с @chuvilin(техдир в ОМП), а он когда-то сам хоумбрю приложения для Maemo (Nokia N900) писал, так что вполне очевидно что даже сами разработчики держат вектор на открытость системы для гиков.

❯ Есть ли перспективы?

Пожалуй, наличие перспектив у «Авроры» зависит от того, зачем вам нужен девайс с ней на борту. Если говорить о Enterprise-секторе и гос-организациях, то система со временем может занять довольно большой процент рынка и так или иначе, у вас будет шанс пощупать её на промышленном устройстве. В целом, её интеграцией в бизнес уже сейчас активно занимается компания «Марвел» (владелец бренда F+).

Также у «Авроры» есть хорошие перспективы среди гиков: существуют тематические каналы в Telegram, а также люди активно обсуждают систему на 4pda. Аврора очень интересная «под капотом» и достаточно дружелюбная по отношению к разработчикам, так что гики — определенно одна из ЦА этой системы.

Есть ли перспективы среди обычных пользователей? Тут сказать сложно. Дело в том, что основная проблема «Авроры», Sailfish OS, Meego и Maemo — относительно малое количество софта, которым можно пользоваться «из коробки». И если гикам часть приложений можно запилить самому (например, клиент банка на СМСках), то что делать простым пользователям? Правильно, ждать появления нужного софта в магазинах, а до этого использовать веб-версии в FireFox. Будем честны, такой вариант устраивает далеко не всех.

❯ Заключение

Вот такой материал об «Авроре» и F+ R570E у нас с вами сегодня получился. А как вам данный смартфон? Есть ли у него перспективы? Пишите своё мнение в комментариях!

P.S: Я не получил от F+ ни копейки за статью, кроме самого девайса. Все впечатления — мои личные, а меня довольно легко впечатлить (достаточно чтобы на девайсе был Linux :) ) Поэтому, надеюсь, даже те читатели, которые не питают симпатию к Авроре», останутся довольны после прочтения статьи.

Также у меня есть Telegram-канал "Клуб фанатов балдежа", куда я публикую ссылки на новые статьи, видео, а также мысли по программированию, ремонту и моддингу различных гаджетов, а также немного щитпоста. Подписывайтесь, если интересно. Недавно я начал вести ещё и паблик в ВК, там в основном репосты видосов с ютуба для тех, кто не хочет юзать VPN, но кому интересны мои видосы. Также туда публируется часть постов из телеги.

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

Друзья! Много ли платформ вы знаете, где для написания пользовательских приложений используется стек… веб-технологий, причём это единственный нативный способ писать программы? Услышав о HTML5 + CSS + JS, на ум приходит разве что webOS — которая используется в современных телевизорах от LG (а ранее использовалась ещё и в Palm Pre — уникальный смартфон, единственный в своём роде), а олды вспомнят ещё и про FireFox OS, в которой вся оболочка (включая многозадачность, шторку уведомлений и все приложения) также была реализована на JS. Но ни webOS, ни FFOS в своё время не суждено было стать массовыми ОС на смартфонах: сказывались аппаратные ограничения устройств, да и проблемы с портированием уже существующих приложений с других платформ (например, игр). Однако несколько лет назад, проект FireFox OS был форкнут и на свет появилась новая система, предназначенная для… умных кнопочных телефонов с LTE! И имя ей — KaiOS. Вероятно, многие мои читатели слышали о ней и о новых умных кнопочниках от Nokia. Но что из себя представляет система под капотом и чем она может быть интересна гику? Читайте в новом материале!

❯ Предыстория

В наше время, стек веб-технологий стал чуть ли не вторым по важности для разработки клиентских приложений. С появлением PWA и модных MVC-фреймворков, а также таких проектов, как Electron, визуальная составляющая многих приложений радикально поменялась: стало возможным реализовывать кастомный, гибкий и адаптивный интерфейс с поддержкой тем и анимаций буквально в несколько строчек кода. Такой подход значительно упрощает и удешевляет разработку клиентских приложений для популярных сервисов: например, «набросать» своё приложение для MP3-плеера может даже зелёный джун, который только начал писать код.

Первой попыткой сделать PWA-приложения «нативными» был, как ни странно, первый iPhone. iOS 1.0, которая в те годы ещё называлась iPhone OS, не имела AppStore и поддержки нативных ipa-приложений и предлагала просто выносить значки нужных сайтов на рабочий стол. При этом возможность отображения полноценных десктопных сайтов была одна из самых сильных сторон iPhone в те годы! Как показала практика, Стив Джобс немного поспешил с интеграцией PWA на смартфонах и в iOS 2.0 уже был добавлен AppStore, куда разработчики могли публиковать нативные и быстрые приложения!

Но всё это итак знакомо многим моим читателям: подписчики часто жалуются на то, что современные приложения жиреют и лагают, а ещё тащат за собой целый CEF и миллион npm-пакетов из-за чего даже какие-то простые приложения начинают требовать слишком большие ресурсы. Но кто бы мог подумать, что веб-стек найдет своё место на… кнопочных мобильниках! Казалось бы, дешевые кнопочники не имеют ресурсов для запуска полноценного браузера, их главная задача — именно звонить. Но ведь на складах всё ещё лежат, полагаю, целые стеллажи бюджетных смартфонных процессоров 10-летней давности, которые вполне способы запустить Android… смекаете, к чему я? :)

KaiOS появилась как форк и концептуальное продолжение провалившейся FireFox OS: система от Mozilla предлагала множество интересных концепций и шустро работала даже на очень-очень бюджетных смартфонах, несмотря на веб-направленность. Минимальные требования системы были скромными: ОС шустро работала на бюджетном ZTE Open с 256Мб ОЗУ и чипсетом MSM7225A из 2012 года. FireFox OS работала на ядре Linux, основой был браузерный движок Gecko, а поскольку Mozilla, полагаю, не смогла заручиться поддержкой вендоров чипсетов и хотела, чтобы систему мог портировать на своё устройство любой желающий, для взаимодействия с железом устройства система использовала драйвера для… Android! Поскольку Gecko собирался с использованием стандартного libc, а драйверы использовали bionic, FireFox OS активно использовала библиотеку libHybris, что позволяло портировать систему на уже существующие смартфоны с любыми чипсетами.

Идея системы простая: формально, это один большой браузер (оболочка Gaia), который при запуске приложений создаёт ещё маленькие «браузеры» (элемент webview, это не iframe). Плюсы такого подхода очевидны: отказоустойчивость (потенциально, весь рестарт Gaia — это WebView.Refresh. В случае Android — это закрытие всех приложений и перезапуск app_process), безопасность (нельзя вызвать Private API), лёгкость отладки и малый вес конечных приложений (причём вес — основной критерий для публикации приложения в официальном магазине KaiOS, пакет до 20Мб). Стоит ли говорить о том, что приложение на такое устройство сможет написать даже ребенок, а игру в стиле «Змейки» можно реализовать за пару часов? Порог вхождения значительно ниже даже чем на Android!

В основном, KaiOS разрабатывалась как система, которая должна вывести кнопочные телефоны из разряда «просто-звонилок» и позволить использовать на привычных устройствах современные мессенджеры и различные сервисы (например, тот-же YouTube). Пожалуй, это отнюдь не «прокачанные бабушкофоны», как некоторые могут подумать, а перспективные девайсы с современным железом (поддержка дисплеев высокого разрешения, 3D GPU, LTE) и заделом на будущее, пусть пока и без крутых девайсов в стиле Nokia N-серии. Концепция умных кнопочников не ограничена KaiOS: выходят различные девайсы и на Android, об одном из таких смартфонов я даже писал две отдельные статьи с обзором и моддингом.

Сейчас на барахолках можно найти дешевые девайсы на KaiOS до 2х тысяч рублей, правда свежие Nokia ценятся обычно выше. Мне же достался в подарок Nobby 240 LTE от моего читателя jameskod007, за что ему большое спасибо! Чем такие девайсы могут быть интересны гику? Давайте посмотрим!

❯ Что «под капотом»?

Под капотом у устройств на KaiOS трудятся старые и такие знакомые многим читателям бюджетные чипсеты, как MediaTek MT6572 (использовался в смартфонах до 3-4х тысяч рублей в 2014-2015), SpreadTrum SC7731E (наследник SC7731 2014 года с другим GPU) и Qualcomm 205 (судя по всему, наследник Snapdragon 200 — популярного чипсета 2014-2015 года, который использовался, например, в Lumia 520). Само собой, это позитивно сказывается на цене устройства: зачем в девайс с дисплеем 240x320 ставить 800'ый Snapdragon? :)

Значительным плюсом подобных устройств является простота обслуживания. По правде сказать, здесь и ломаться то особо нечему: дисплей относительно надежно защищен от внешнего влияния с помощью воздушной прослойки и защитного стекла, а элементная база смартфона весьма маленькая и «не ломучая». Разбирается смартфон просто: достаточно лишь открутить несколько винтов с обратной стороны корпуса и расщелкнуть телефон пластиковой картой. Что забавно — такие формы корпусов будто «унифицированы» среди производителей дешевых телефонов, никто, почему-то, не экспериментирует с корпусами в стиле а-ля Nokia N-серий.

Перед нашим взором открывается плата. К сожалению, я пока не видел на кнопочных смартфонах UART в открытом виде, иначе давно бы реализовал что-то типа такого. На плате мы можем заметить, что LTE-версия Nobby 240 работает на достаточно свежем Spreadtrum SC9820E с двумя 64-битными ARMv8 ядрами Cortex-A53 на частоте 1.3ГГц и GPU Mali T820 MP1, а также с LTE модемом. Чип выполнен по техпроцессу 28Нм, максимальное разрешение дисплея — 480x854 (т. е. DSI матрицы всё таки поддерживаются, параллельно с DBI). Весьма шустрый чипсет для девайса такого класса, его едва ли можно назвать «бабушкофонским», подобные характеристики были флагманскими для смартфонов ~2012 года. Для сравнения — простые кнопочники все еще работают на ARMv5 ядрах на частоте около 200-300МГц.

Дисплей припаян и приклеен к плате, подключен к процессору при помощи 16-битного протокола 8080, а не MIPI DSI, как в современных смартфонах. Его разрешение — классические 240x320. Поиск его замены скорее всего не составит труда, хотя точная модель контроллера мне пока неизвестна (предполагаю, либо ILI9341/ILI9325, либо ST7731, либо так любимый китайцами GC9306).

А вот клавиатура — болячка таких девайсов. По каким-то причинам, пластиковые толкатели кнопок очень быстро изнашиваются и кнопки начинают дребезжать (нажиматься несколько раз одновременно), либо не прожиматься. Это очень обидно и неприятно, но быстрофикс есть — напечатать крохотные проставки на 3D-принтере.

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

❯ Веб-разработка

Для разработки нам потребуется совсем немного: любой текстовый редактор (хоть блокнот), FireFox 59 и platform-tools с adb для Android.
В первую очередь, на смартфоне необходимо включить режим отладки, который активируется набором кода *#*#33284#*#* (DEBUG) в номеронабирателе. После этого, в шторке уведомлений появится значок «жука». На некоторых устройствах, режим отладки активируется прямо в настройках. После этого, смартфон будет виден через adb и мы сможем дебажить на нем свои приложения!

Теперь нам необходимо накатить «древний» FireFox 59, это последняя версия с поддержкой WebIDE и возможностью деплоя под FireFox OS от 2018 года. WebIDE — это дебаггер и менеджер приложений для экосистемы Mozilla, активируется с помощью хоткея Shift + F8. Не забудьте отключить авто-обновление в настройках браузера!

После этого, нам необходимо связать WebIDE с нашим смартфоном с помощью «Remote Runtime». Однако перед этим, нам необходимо форварднуть adb-сокет с помощью команды:

После этого, мы жмем «Remote Runtime» и «Runtime Info», дабы получить информацию о нашем девайсе и убедится что всё нормально:

Создаём новое приложение и вперед творить! По правде сказать, я практически не знаю, каких приложений особо не хватает на KaiOS. ВК частично есть, YouTube почти полноценный, WhatsApp тоже реализован… не хватает разве что Telegram? Но я лично не смог бы полноценно чатится с телефона такого типа (и дело не в форм-факторе), поэтому я решил запилить ради прикола приложение-виджет для просмотра погоды в моём городе :)

У каждого приложения есть манифест, который объявляет используемые разрешения, значки и различные данные, необходимые для публикации приложения в магазине приложений. Существует три типа приложений: «web» (Hosted web apps — или, фактически, PWA), «privileged», и «certified» (приложения с доступом к критичным функциям смартфона типа СМС. В привилегерованном режиме, приложения могут обращаться к службам KaiOS, таким, как например Bluetooth и настройках сети.

Сначала я сверстал простенький интерфейс для приложения. Логика простая: поскольку это приложение-виджет, при его запуске отображается прелоадер (анимация загрузки), а как только данные загружены — программа показывает блок content и скрывает анимацию загрузки. Никаких фреймворков типа React я тащить не стал, но для более сложных приложений придётся продумывать более сложную логику для реализации диалогов.

Не ругайте за <center>! Я не веб-разработчик, адаптивные верстки делать не умею :))

Фетчить данные мы будем с OpenWeatherMap, хотя можно попросить доступ к API и у Gismeteo. Формат запросов у API очень простой — фетчим данные о погоде в локации относительно координат широты/долготы, при этом встроенный API для геокодинга поможет найти координаты того или иного района в городе. Делаем вот такой GET-запрос:

И получаем вот такой ответ:

Конечно, разобрать его очень и очень легко. Обновляем представление нашего приложения (я не юзал селекторы):

И получаем следующий результат:

Вся логика программы уложилась в 85 строк кода. Преимущества веб-подхода и «жабоскрипта» при грамотном использовании очевидны, согласитесь? Опять-же повторюсь, я не веб-разработчик, мои познания в JS ограничиваются «олдовым» стилем уровня начала-середины 2010х годов, я, вон, даже jquery тащить не стал.

❯ Рут

Изначально материал должен был состоять из двух частей: обзор «клиентской» части девайса с приложениями на веб-стеке и выкидывание B2G, дабы реализовать нечто подобное одной из моих более ранних статей. Но вендор смартфона подложил «свинью»: у устройства залочен загрузчик и разблокировать его штатными средствами невозможно. Вообще, инфраструктура FireFox OS имеет много общего с Android изнутри, так что я попробовал с помощью патчера magisk'а пропатчить бут и залить в него su… но увы, девайс валился на верификации signed-образа и отказывался прошивать раздел! За это жирнющий минус вендору.

Если хотите взять подобный девайс для моддинга и экспериментов, присмотритесь к девайсам на Android, или KaiOS на базе MT6572/SC7731 — те обычно разблокированы с завода. Например, год назад я сделал первую кастомную прошивку для Android-кнопочника и написал для него кастомный лаунчер.

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

❯ Заключение

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

Какие применения могут быть у такого девайса? Да самые разные! Например:

• Маленький фронтэнд для данных с микроконтроллера: тут уже и дисплейчик небольшой есть, и кнопки, а также GPU, если нужно показывать какие-то данные в 3D. Почему-бы и нет?

• BT-плеер в машину: пилим фронтэнд к ВК Музыке/Спотику или еще какому-либо сервису, коннектим по BT и получаем миниатюрный автомобильный самодостаточный плеер, который еще и аккумулятор относительно долго держит :)

• Часы с погодой: частичную реализацию этого проекта я уже представил в статье. Собственно, а почему-бы и нет? Многие смартфоны от Motorola и Sony с док-станциями сейчас так и используют. Почему бы не заюзать для этого и девайс на KaiOS?

Надеюсь вам было интересно! Пишите своё мнение, есть ли перспективы у смартфонов на KaiOS? Также у меня есть свой Telegram-канал, куда я выкладываю бэкстейдж со статей, различные заметки о ремонте, моддинге и программировании под девайсы прошлых лет и вовремя публикую линки на новые статьи. Подписывайтесь!

Насчёт машины

Друзья! Те читатели, которые подписаны на меня наверняка знают о том, что я коплю на покупку ТАЗика, дабы реализовать интересный проект с разработкой самопального ГУ "из того что было" по самому дешману. Сейчас у меня есть чуть более 100.000 рублей, из которых 8.000 рублей - донаты читателей! В Ейске, на юге, за такие деньги купить относительно живой по мотору и, что немаловажно, с +- целым дном тазик сложновато. Я даже Волгу и Москвич рассматривал как вариант, но Волга ушла, а у Москвича мотор не родной. Если вам нравятся мои статьи и вы хотите помочь материально будущему проекту - с помощью формы ниже можно помочь проспонсировать проект!

Если вы вдруг живете в Ейске или в 50км от Ейска и вы или ваши знакомые продают относительно живой ТАЗик (кроме классики, критерии - на ходу, чистые документы и не совсем панорамное дно. Машинка может быть помята, с плохим ЛКП и конечно другими косяками, машина ведь не новая!) - пишите в ТГ @monobogdan!

Статья подготовлена при активной финансовой поддержке TimeWeb Cloud. Не стесняйтесь пользоваться их услугами, если вам нужен VDS, выделенный сервер или иные облачные услуги. Подписывайтесь на меня и @Timeweb.Cloud, дабы не пропускать интересные технические статьи каждую неделю!