Linux + Смартфон

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

Недавно я задался вопросом: а возможно ли написать для 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!). Всем большое спасибо за донаты!

Есть у меня страсть к коллекционированию и ремонту интересных смартфонов прошлых лет. Недавно подписчик подарил мне весьма диковинный и необычный гаджет 2011 года: бюджетный QWERTY-смартфон Samsung Galaxy Y Pro с чипсетом от Broadcom. Помимо самого факта того, что смартфон обладал QWERTY-клавиатурой, меня также заинтересовало его кровное братство с Raspberry Pi первого поколения. Но вот незадача, смартфон не включался и просто висел на логотипе. Если вам интересен необычный кейс "отвала" eMMC и переноса Android на MicroSD-флэшку - жду вас под катом!

❯ Теория

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

Происходит это из-за того, что для загрузки системе необходим доступ как минимум к трём разделам: system для чтения, а также data и cache для чтения и записи. У eMMC и современной UFS-памяти есть свой собственный контроллер в чипе, который по своим собственным параметрам определяет S.M.A.R.T накопителя и, если по его мнению, флэшка уже близка к "кончине", просто переводит её в режим Read only, из-за чего данные пользователя остаются на месте, но смартфон уже больше никогда не загрузится без вмешательства специалиста.

В теории всё замечательно: данные на месте, в сервисе просто вычитают дамп старой флэшки, подберут такой же или совместимый по корпусу новый чип, а затем запишут на него дамп и восстановят все данные без потери. Но на практике бывают определенные казусы: например, у некоторых чипов Samsung 2012-2014 года был баг в прошивке, из-за чего они полностью умирали с потерей всех данных, после чего смартфон вообще не подавал никаких признаков жизни (примеры: Galaxy S4 Mini в 9008, S4 Zoom, Note N8000), иногда eMMC просто уходила в полный ReadOnly (HTC Desire SV и некоторые другие HTC'шки 2011-2012 годов), а иногда чип уходил в ReadOnly лишь частично - операции записи просто заканчивались неудачей (предположительно из-за того, что бэды ремаппить уже просто некуда) и смартфон даже мог загрузится... правда все приложения постоянно крашились, а настройки телефон не сохранял.

Примерно так вышло и в моём случае. В январе, подписчик Андрей предложил подарить мне весьма необычный смартфон - Samsung Galaxy Y Pro. Читатель попытался его перепрошить, однако смартфон всё так же продолжал висеть на заставке. Конечно я согласился, причём мне из принципа хотелось разобраться в платформе и при возможности перенести всю систему на MicroSD-флэшку.

❯ Переносим на MicroSD

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

Чтобы понять, что всё это значит - давайте вкратце рассмотрим процесс загрузки Android:

1. Старт BootROM, SPL и загрузчика: После включения смартфона или подключения ЗУ, контроллер питания даёт разрешение на запитывание всех модулей устройства. После этого, процессор начинает выполнять код загрузчика, однако поскольку ни NAND, ни eMMC не поддерживают XIP (eXecute In Place - возможность подключить флэшку прямо в шину процессора, на манер ROM в спектруме), первым делом процессор выполняет код из BootROM - небольшого, физически прожженного в небольшую ROM-память на заводе загрузчика, в задачи которого входит экстренный режим восстановления при окирпичивании устройства (MTK USB Port на MediaTek, 9008 на Qualcomm, FEL на AllWinner) и загрузка вторичного загрузчика из eMMC/NAND - SPL (на MediaTek называется Preloader). В его задачи входит инициализация ОЗУ и передача управления вторичному загрузчику - тот самый, который вы, возможно, захотите разблокировать и который загружает ядро Linux.
   
   Но вот нюанс, на чипсетах Broadcom BootROM'а нет: там запуском ARM-ядер занимается GPU VideoCore, который по своей натуре - векторный DSP! Так что Y Pro интересен ещё и этой малозначимой, но забавной деталью :)

2. Linux: Обычно ядро хранится не в сыром виде, а в специальном разделе boot/recovery и представляет из себя образ zImage + рамдиск. На этом рамдиске хранятся минимально-необходимые для старта устройства программы: init, busybox (не всегда) и... всё!
   
   Формат таких образов условно стандартизирован и их можно разобрать и собрать с помощью специальных программ. Например, AndImgTool!

3. init: Далее самая главная программа с PID 0 - init, запускает набор скриптов в корне рамдиска с расширением .rc. В скриптах содержатся обработчики событий (early-boot, boot, late-boot и т.п), а также список служб для запуска. В скриптах идёт монтирование разделов, запуск служб если это нужно, создание ссылок, загрузка динамических модулей и конфигурация драйверов/ядра, а также режима USB и adb. Помимо этого, init отвечает за properties - свойства в build.prop, а также default.prop, которые позволяют включить adb даже если устройство не загружается. Это нам позже пригодится.

4. app_process: После того, как раздел system примонтирован, RIL запущен и другие важные операции выполнены - rc-скрипт запускает наконец-то app_process с параметром zygote. Это самый важный процесс в Android, его краш ведет к "мягкой перезагрузке" - т.е появлению анимации загрузки и появлению рабочего стола. app_process - это как-бы Java-машина Dalvik (или ART в Android 5.1+), аналог java.exe, только размножается она методом почкования - с помощью системного вызова fork.

5. Ну и когда все службы работают - устройство показывает рабочий стол и вызывается событие ON_BOOT_COMPLETE.

Да, всё вот так просто. Итак, основываясь на сказанном выше, как мы можем перенести Android на MicroSD? Правильно, пропатчив скрипты загрузки так, чтобы они монтировали систему и раздел data с cache не с внутреннего накопителя, а с флэшки. Но для патча необходимо чтобы eMMC была хоть сколь-либо перезаписываема.

Сначала я попытался установить кастомную прошивку с помощью CWM (он здесь не перепрошивается навсегда, а запускается с помощью бага в update.zip) и заметил, что поведение смартфона поменялось: он просто висел на первичном логотипе и не загружал даже бутанимацию. А значит какие-то операции перезаписи завершились ошибкой и init либо не может примонтировать system, либо там у нас там творится бардак. Но что-то ведь всё таки перезаписалось, а после перепрошивки родной системы смартфон снова начинал показывать бутанимацию... значит, флэшка не полностью в readonly?

Я решил пропатчить boot.img, активировав в нём режим отладки через USB, дабы посмотреть что творится у нас в dmesg. Для этого я распаковал образ с помощью AndImgTool, открыл файл default.prop и заменил свойства ro.secure = 0, ro.debuggable = 1, а также persist.service.adb.enable = 1

Samsung в те годы ещё не блокировал загрузчики и прошить произвольный раздел можно было фирменным флэшером. Для этого необходимо было создать tar-архив, куда положить образ (например boot.img), выбрать его в программе и нажать "Start".

После прошивки, смартфон всё также висел на заставке... но определился в диспетчере устройств и команда adb devices показала, что смартфон подключен. Значит, раздел перезаписался и только часть eMMC ушла в readonly! Те разделы, которые никогда не перезаписываются (куда входит system, boot, recovery и SPL) - в норме?

Пишем dmesg и... видим как драйвер eMMC флудит в printk об ошибках перезаписи в раздел /data/. А ведь я говорил о том, что Android для загрузки этот раздел обязательно нужен!

Но что же за stl11, если в Linux принято называть eMMC-устройства mmcblk? Давайте посмотрим в init.rc:

Разделы используют какую-то самопальную файловую систему RFS (что-то проприетарное от Samsung), а также J4FS, вместо общепринятых YAFFS или EXT4. Давайте сделаем логический вывод: если раздел system и efs (с настройками модема) у нас в норме и никогда не перезаписывается, а после загрузки ядра, Android нужны для перезаписи data и cache... значит можно просто перенести эти разделы на MicroSD, а init.rc заставить монтировать разделы именно оттуда!

Для этого мы берём MicroSD-флэшку и с помощью fdisk бьём её на три раздела: один будет для /data/ (30% от ёмкости MicroSD - или хотя-бы 256Мб), второй для /cache/ около 64Мб и третий для обычных файлов. Затем форматируем первый и второй разделы в ext2 с помощью программы mke2fs, а третий - в обычный FAT32 (или тоже ext2, по желанию).

Далее прописываем новые точки монтирования в init.rc, собираем boot.img и прошиваем в смартфон:

И, спустя пару минут загрузки... нас встречает рабочий стол! Радости нет предела :) Но некоторые читатели могут усомнится в юзабельности всей этой затеи, ведь MicroSD как минимум в десять раз медленнее eMMC... Но всё ли так плохо? Давайте посмотрим на практике!

❯ Тестируем

Поскольку смартфон у нас с QWERTY-клавиатурой и горизонтальным дисплеем, здесь лаунчер подогнан под частичное управление с кнопок, при этом стоить иметь ввиду, что далеко не каждое приложение адаптировано для такого DPI. Тачскрин тоже есть, причём емкостной, что не может не радовать. Дисплей выполнен по технологии TN, разрешение - всего 240x320, что в целом совсем немного для смартфона, но вполне нормально для QWERTY-бюджетника тех лет.

Под капотом скрывается чипсет от Broadcom - BCM21553 с одним ядром ARM1136, работающем на частоте 832МГц. И да, это ARMv6 ядро, что значительно сужает круг поддерживаемых игр и приложений. Когда-то на 4pda даже был отдельный клуб владельцев смартфонов на этом чипсете, где люди жаловались на отсутствие поддержки ARMv7! Также в смартфоне установлено 384Мб DDR2 ОЗУ и 512Мб постоянной памяти.

В качестве GPU используется ядро собственной разработки Broadcom - VideoCore IV. И оно тоже было предметом критики на профильных форумах. Все дело в том, что как и у GPU от Samsung - FIMG, у VC IV были плохие драйвера для GLES - что было критично для игр тех лет. Поскольку большинство релизов оптимизировалось на Qualcomm Adreno и Mali, во многих играх на Y Pro были белые текстуры, или же графические артефакты.

Для сравнения: Raspberry Pi Model A и B - братья данного смартфона, которые в аппаратной части похожи почти во всем. Теперь мы с вами выяснили, что смартфон представляет определенный коллекционный интерес для любителей гаджетов на необычных процессорах!

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

Но можно ли назвать смартфон бесполезным в наше время? Я думаю, что нет, определенный набор задач он все еще способен выполнять. Например, серфинг в сети - самый базовый просмотр страниц всё ещё можно осуществить с помощью Opera Mini 7, которая до сих пор продолжает работать спустя 10+ лет после релиза. Многие страницы отображаются некорректно, ни о каких сайтах с интерактивом и речи не идет... но почитать Википедию или Хабр всё равно можно!

При условии отключения проверки сертификатов (Защита -> "SSL (Принимать все)") и использования одноразовых паролей, можно использовать почтовый клиент. Работает шустро, однако пуши не поддерживает, поэтому сообщения будут проверяться с интервалом в ~5мин.

Также можно посидеть в мессенджерах. Я писал клиенты ВК и ТГ (работает через прокси) для смартфонов с Android 1.5+ и запускал их даже на первом серийном Android-смартфоне в мире и они здесь работают вполне неплохо. Об официальных клиентах и речи не идет - Android 2.3 слишком сильно устарел по мнению большинства разработчиков.

И конечно можно поиграть. Начиная от Java-игр, в которые играть вполне удобно благодаря наличию аппаратных кнопок, заканчивая эмуляторами консолей, которые в большинстве своём здесь летают и нативными играми. Таким образом, старенький смартфон превращается в миниатюрную портативную консоль. Единственный нюанс - VC IV совсем уж слабенький GPU, когда заходит вопрос запуска 3D-игр. Даже Raging Thunder 2 со своим замечательно оптимизированным рендером здесь иногда чуточку подтормаживает, при том что она же идеально работает на Adreno 200 (ATI Z430), Mali-300 и даже Vivante GC-600!

Пусть круг задач и не слишком широкий, но смартфон всё равно очень интересный и крутой :)

❯ Заключение

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

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

Мои давние читатели наверняка знают о том, насколько сильно я люблю необычные нетбуки с диковинными процессорами и необычными операционными системами на борту. Один из таких девайсов сегодня попал ко мне на стол: Toshiba AC-100, который вышел как нетбук для серфинга интернета за 200$ в далеком 2011 году и отличался тем, что работал на крайне диковинной платформе - ARM-чипсет NVidia Tegra 2 вкупе с десктопным мультиконтроллером и Android в качестве ОС. Но вот беда: в устройстве не работала подсветка дисплея. В сегодняшней статьей мы с вами: узнаем предысторию нетбуков и как появился AC-100, отремонтируем шлейф подручными средствами и посмотрим на такого замечательного красавца на практике. Интересно? Тогда жду вас под катом!

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

Пожалуй, начать можно с того, для кого и зачем позиционировался такой интересный девайс, как ARM-нетбук, да ещё и на Android. Сейчас ноутбуком на чипсете Qualcomm никого не удивишь, многие известные вендоры активно выпускают собственные девайсы на чипсетах X-Elite и полноценной Win10 For ARM на борту, а Apple вот уже несколько лет успешно использует чипы серии M даже в топовых макбуках.

История бюджетных нетбуков (компактные ноутбуки выходили и в 90-х, но стоили очень дорого, поэтому я подчеркнул бюджетные) начинается в 2007 году, с выходом Asus EEEPC, который стал первым действительно массовым и доступным компактным портативным ПК. Первые модели EEEPC разбирали как горячие пирожки на вокзале и многие производители, наблюдая успех новинки, рванулись делать свои собственные нетбуки. Однако первый EEEPC использовал весьма интересный процессор — Celeron M ULV 353 (также использовавшийся в UMPC), который был не слишком производительным (примерно на уровне Pentium III, и при этом наследует его же архитектуру, как и все современные процессоры Intel), но всё же альтернатив по сути и не было, кроме AMD Geode, который берёт корни от Cyrix MediaGX 1997 года выпуска. Очевидно, что нужен был новый процессор, разработанный специально для ноутбуков и планшетов...

В 2008 году Intel представила новую линейку процессоров Atom — не слишком мощных, но зато экономичных и относительно холодных, построенных как x86-совместимые, но при этом не наследующие микроархитектуру своих «больших» десктопных собратьев (вышеупомянутый Celeron M использовал архитектуру Dothan, являющуюся прямым потомком Pentium III). В серии Atom, Intel экспериментировала не только с тепловыделением и энергопотреблением, но и с использованием необычных GPU в качестве встроенных — например основой GMA 3600 стала мобильная графика PowerVR SGX 545, являющаяся близким братом видеоускорителя первого iPad и показывающая себя вполне неплохо в играх начала 2000-х годов.

После выхода Atom, многие производители ринулись делать свои собственные нетбуки, их производительность росла, число форм-факторов увеличивалось (у меня, например, есть EEEPC-трансформер с резистивным тачскрином!) и до массового появления недорогих Android-планшетов, нетбуки оставались крайне популярными устройствами для потребления контента в сети. Однако один из главных конкурентов Intel на мобильном поприще, а именно ARM, не спали и в 2007 году представили ядро Cortex-A9, реализующее набор инструкций ARMv7 и способное работать на частоте выше 1ГГц. В начале 2010 года, компания NVidia представила второе поколение чипсетов Tegra, построенное на базе ядра Cortex-A9.

Компания Toshiba, будучи ветераном на рынке ноутбуков, тоже производила свои собственные нетбуки, однако в 2011 году решилась на весьма интересный шаг, а именно выпуск нетбука не на привычной x86-платформе, а на свеженьком ARM-чипсете Tegra 2. Причём в качестве ОС была выбрана не Windows (которая в те годы хоть и умела работать на ARM устройствах, но ARM-версия в свет пока ещё не вышла), не Linux-дистрибутивы как на гиковских Sharp Zaurus, а... Android! Причём версии 2.1, совершенно не адаптированной не только для нетбуков, но даже для планшетов!

Я очень большой фанат нетбуков на необычных архитектурах и с необычными процессорами. Обожаю устройства и на MIPS, и на ARM, и на SH3/SH4, хотя их очень сложно находить на барахолках (хотя иногда мне помогают подписчики, а время от времени даже дарят для будущего контента!). Год назад читатель с Хабра под ником @inkvizitor68slподарил мне AC-100, которому я посвятил одну из своих статей и даже чуть-чуть видео, за что ему огромное спасибо. Недавно подписчик Андрей написал, что ищет интересные и необычные Android-устройства к себе в коллекцию, на что я ему посоветовал купить себе AC-100.

Читатель купил его на вторичке за 1800 рублей. Но вот незадача, по приезду оказалось что подсветка девайса не работает от слова совсем! Я решил помочь подписчику и разобраться в чем дело, а вот как происходил процесс ремонта — давайте с вами и узнаем!

❯ Ремонтируем

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

Разборка нижней части начинается с выкручивания винтов с обратной стороны устройства (не забываем потайные винты по бокам отсека АКБ) и снятия клавиатуры путем аккуратного нажатия на «язычки» плоской отверткой. После откручивания винтов можно снять топкейс и увидеть материнскую плату устройства.

Как мы с вами видим, основная плата здесь очень компактная, а в качестве маркировки красуется LA-xx, означающая что ноутбук разработан и произведен компанией Compal (один из крупных OEM-производителей ноутбуков). В первую очередь, в глаза бросается чип ENE, представляющий из себя мультиконтроллер: он отвечает за обработку кнопки включения и внешних GPIO, светодиоды, общение с аккумулятором через шину SMBus, а также являющийся контроллером клавиатуры. И вот здесь опытные читатели могли озадачится: ведь мультиконтроллеры свойственны для классических x86-ноутбуков (где изначально в процессоре особо нет ни GPIO, ни контроллера клавиатуры), ARM-устройства их никогда не использовали, поскольку всё необходимое обычно уже включено в сам чипсет устройства!

Именно «полудесктопная» платформа и отличает AC-100 от других ARM-нетбуков и делает его уникальным. Например здесь разведен Mini PCI-e слот и используется некий чип Texas Instruments, являющийся эдаким контроллером питания, но который скорее всего выполняет также и роль чарджера.

Посмотрим же на сердце устройства, а именно чипсет NVidia Tegra 2. В нём расположились два ядра ARM Cortex-A9, работающие на частоте 1ГГц, графический ускоритель GeForce ULP, видео-декодеры и DSP и контроллер дисплея. Расположен он под термопрокладкой и охлаждается пассивно за счет металлической части топкейса, а именно подложки клавиатуры и в процессе работы почти не греется! Вспоминаем среднебюджетные ноутбуки с горяченными Turion 64 X2, которые при наличии серьезного охлаждения и не очень продуманного теплоотвода вполне могли обжечь руку...

Далее мы видим две банки DDR2 ОЗУ, по 256Мб каждая, образующие в сумме 512Мб. Объём памяти считался однгим из главных недостатков AC-100, поскольку по мнению некоторых пользователей её было мало, однако не стоит забывать что в те годы, в топовые планшеты и смартфоны ставили максимум 1Гб. Так что такой объём не так уж и плох для бюджетного нетбука, да и Android 2.1 кушал далеко не так много ресурсов, как Android 4.x например. Снизу расположился чип флэш-памяти Toshiba на целых 32Гб. Информации о том, eMMC ли это или обычный NAND у меня нет, но подключался он напрямую к контроллеру флэш-памяти в чипсете и его вполне можно назвать SSD-накопителем. Здесь AC-100, однако, был далеко не первым — ещё в 2007 году вышел первый Asus EEEPC, где в качестве флэш-памяти использовалась NAND-флэшка на 4Гб.

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

Затем откручиваем винты от самого дисплея, вынимаем его, отключаем шлейф и отклеиваем черный изолирующий скотч. Важно понимать, что в отличии от смартфонов и планшетов, на ноутбучных матрицах питание подсветки формируется с помощью бустера на плате дешифратора (т. е. на самой матрице), а не на материнской плате устройства, поэтому при отсутсттвии подсветки в первую очередь стоит смотреть присутствие сигнала BLEN (может также называться BKOFF и т.п, отвечает за включение бустера подсветки) и наличие ШИМа на PWM - это регулировка яркости дисплея. Если оба сигнала присутствуют — значит можно переходить к диагностике платы дисплея, а в нашем случае — к осмотру шлейфа подсветки.

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

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

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

Теперь можно подключить шлейф обратно и проверить работоспособность устройства. И о чудо, подсветка появилась!

Собираем девайс обратно и видим что все работает нормально, а значит процедура ремонта прошла успешно!

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

В прошлой статье с участием AC-100 я рассказывал о накатывании Ubuntu и опыте её использования на этом устройстве. Однако Андрей хотел, чтобы на устройстве оставалась официальная Android 2.1, поэтому смотреть в сегодняшней статье мы будем именно на неё. Изначально в устройстве была установлена CyanogenMod на базе Android 4.2 — но кастом работал очень криво, не было нормального режима сна, нетбук быстро разряжался и сильно грелся, поэтому было принято решение прошиваться на сток, благо торрент с образами разделов всё ещё доступен.

На стоковой прошивке девайс выглядит как минимум необычно. Видно что лаунчер Toshiba допиливала своими руками, но всё равно остается ощущение что интерфейс планшетный.

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

Благодаря довольно шустрому Tegra 2, девайс отлично справляется с эмуляторами, причём благодаря наличию полноценного USB-разъема, можно без проблем подключить геймпады и гонять в классику. Дисплей хорошего качества, также есть и HDMI, так что девайс вполне можно использовать для ретро-гейминга в дороге. Родной аккумулятор как в моей AC-100, так и в герое нашей статьи вполне держит даже спустя 13 лет после выхода — так что с этим проблем не будет.

Также девайс тянет нативные игры. Quake 2 в OpenGL-рендерере и в HD? Вообще легко! Правда наверняка читатели спросят мол «отлично, а в софтрендере HD потянет?» :)

Но с некоторыми играми есть и проблемы. GeForce ULP был довольно свежим GPU и игры под него адаптировались, поэтому в Angry Birds, например, есть проблемы.

Но в целом вот такой крутой и вполне полезный в наше время девайсик получился. Конкретно этот АС-100 отправится в коллекцию Андрея, который будет его время от времени включать и наслаждаться выглядящим диковинно в наше время Android 2.1, восхищаясь инженерами Toshiba (или Compal?). А я продолжу искать нетбуки на необычных процессорах, чтобы писать про них новые статьи, даже нерабочие — ведь восстановление крутых ретро-девайсов это всегда интересно!

❯ Заключение

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

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

Кстати, если у кого-то из читателей есть ненужные устройства (в том числе с косяками) или дешевые китайские подделки на айфоны/айпады/макбуки и другие брендовые девайсы будучи нерабочими, тормозящими, или окирпиченными и вам не хотелось бы выкидывать их на свалку, а наоборот, отдать их в хорошие руки и увидеть про них статью — пишите мне в Telegram или в комментах! Готов в том числе и купить их. Особенно ищу донора дисплея на китайскую реплику iPhone 11 Pro Max: мой ударник, контроллер дисплея калится и изображения нет :( Было бы интересно поколупать и КПК самого начала нулевых годов (PPC2002, а то и WinCE или PalmOS) — пишите, если таковые есть.

А ещё я держу все свои мобилы в одной корзине при себе (в смысле, все проекты у одного облачного провайдера) — 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 чтобы не пропускать новые статьи каждую неделю!

Сверхусовершенствованная камера iPhone 16 Pro Max: Все, что нужно знать

Согласно информации от Digital Chat Station, ожидается, что iPhone 16 Pro Max станет флагманом изображения с выдающимся качеством фото- и видеосъёмки. Основные улучшения включают:

Камера и датчик изображения

- Улучшенные функции: Возможно наличие 14-битного аналого-цифрового преобразователя (ADC) и DCG для повышения динамического диапазона и снижения уровня шумов.

- Увеличенный размер сенсора: На 12% больше, чем у предыдущих моделей iPhone 14 Pro и iPhone 15 Pro. Это должно привести к повышению качества изображения, особенно в условиях плохого освещения.

Улучшенные возможности

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

- Эффективность при слабом освещении: Благодаря новому датчику и улучшениям, iPhone 16 Pro Max будет способен делать качественные снимки даже при низкой освещенности.

Дизайн и дисплей

- Легкие изгибы: По слухам, iPhone 16 Pro и Pro Max могут получить слегка изогнутые экраны, соответствуя тренду модели iPhone 15 Pro и Pro Max.

С учетом всех этих обновлений, iPhone 16 Pro Max обещает впечатляющую камеру и улучшенный опыт фотографирования для пользователей. Будем ждать официального анонса компании Apple для подтверждения этих спекуляций.