Я все таки запилил первый видос, экранизацию одной из прошлых своих статей
Да, где-то запорол звук и видеоряд, но я старался! Пожалуйста, зацените ;)
Да, где-то запорол звук и видеоряд, но я старался! Пожалуйста, зацените ;)
И снова ежемесячный пост! Как многие пикабушники уже вероятно знают, я пишу статьи об оживлении, моддинге и программировании под различные старые девайсы! Но некоторые девайсы, как, например, дешевые китайские подделки порой найти проблематично: большинство оказалось на свалке, а на онлайн-барахолках их не найти из-за запрета на контрафакт. Для будущего материала, я ищу китайские подделки из начала 2010х: в основном китайские копеечные игровые консоли, Android-реплики айфонов, айпадов, макбуков, Samsung Galaxy, Nokia Lumia/HTC/Sony Xperia и другие подделки на популярные бренды. Можно невключайки/нерабочие/зависающие, почти любое состояние - все постараюсь оживить и поднять. Что с ними происходит потом? Смотрите сами: Альтернативное Apple'водство: Как и зачем я променял оригинальный айфон на китайский нерабочий 14 Pro Max, На помойку? Никак нет! Пишем нативные приложения для китайских кнопочников, Сам себе Linux-смартфон: Выкидываем Android из старого Fly и пилим свою оболочку, Сам себе экосистема, портируем свежий Android на NoName-смартфон, на грани отвала eMMC: переносим Android на MicroSD, накатываем чистый Android на китайский iPhone 5s, бомж-гейминг за копейки с отвальной консолью. Так что не сомневайтесь, девайсы попадают в хорошие руки :) Все стараюсь поднять, оживить и написать про них материал! Есть что-то подобное? Пишите в комменты или в тг @monobogdan. Спасибо!
Отвал флэш-памяти типа eMMC - весьма частая болячка смартфонов и планшетов, которая массово преследует современные девайсы на протяжении вот уже более 10 лет. Симптомы проблемы знакомы многим читателям: смартфон виснет на заставке, системные приложения регулярно вылетают, или настройки системы внезапно перестают сохраняться. Сам процесс замены флэш-памяти требует навыков перекатки и пайки BGA-чипов, оборудования (трафареты для реболла, программатор с колодками, опционально подогрев) и понимания того, как работает загрузчик той или иной аппаратной платформы, поэтому в СЦ за эту процедуру могут взять достаточно большую сумму. На некоторых девайсах менять память уже совсем невыгодно, особенно когда другой такой-же аппарат стоит полторы тысячи рублей на барахолке, но воспоминания о любимом девайсе порой гораздо дороже, чем сумма за ремонт смартфона. Год назад я уже писал материал о загрузке Android с MicroSD при условии того, что eMMC ещё подает хоть какие-то признаки жизни, а сегодня я вам расскажу о способе загрузить систему с флэшки уже после того, как чип флэш-памяти отказал и ушёл в read-only. Сегодня мы с вами: узнаем о том, какие типы флэш-памяти существуют и причины их отказа, разметим MicroSD-флэшку и запишем на неё образ системы, пропатчим пути монтирования в boot.img, а также узнаем, как теперь запускать наш смартфон и посмотрим, сможет ли он работать достаточно шустро с MicroSD флэшки! Интересно узнать, как вернуть жизнь таким легендам, как Google Nexus? Тогда добро пожаловать под кат!
Как я уже говорил в вводном абзаце, проблема внезапно отваливающейся флэш-памяти существует вот уже более 10 лет. Ещё с выходом iPhone 3Gs/4, мастера познакомились с такой болячкой, как внезапное падение устройства в режим DFU и отказ прошиваться через iTunes. Ближе к выходу Galaxy S III, HTC Desire и Wildfire, LG Nexus возникла потребность в программаторах, поскольку чипы eMMC в этих смартфонах очень часто помирали «сами по себе» из-за косяков производителя флэш-памяти. Более опытная часть моих пользователей может вспомнить такие проблемы, как отказ входа в HSPL (загрузчик HTC), бесконечная загрузка с отказом прошиваться в режиме Odin на самсунгах, падение смартфонов на базе чипсетов Qualcomm в режим 9008 (QHSUSB_BULK), а также внезапное прекращение работоспособности девайса даже при наличии адекватного потребления и реакции на кнопку включения.
В относительно современных смартфонах используется два типа чипов флэш-памяти с разными протоколами: NAND и eMMC (в современных чаще используется UFS — наследник eMMC с дифференциальным протоколом, вместо MMC). Устройства конца 2000х годов чаще использовали флэш-память типа NAND с Legacy-протоколом, который требовал ручного управления SPARE-страницами и расчета кода коррекции ошибок (ECC), чем занималось отдельное периферийное ядро в процессоре, называемое NAND-контроллером. Момент, когда нужно «приговорить» флэш-память и перевести её в режим read-only решал не сам контроллер, а драйвер NAND в прошивке устройства — и обычно он был весьма лоялен даже к «сыпящейся» памяти. Кроме того, NAND-контроллер позволял практически напрямую взаимодействовать с чипом флэш-памяти, благодаря чему в загрузчиках типа U-boot есть команда для очистки таблицы Bad-блоков и низкоуровневого форматирования флэш-памяти, дабы в дальнейшем контроллер попробовал пересчитать бэды и, потенциально, вернул некоторое число блоков обратно в строй. Такой тип «флэшек» помирал значительно реже, в основном из-за того, что софт (на моём опыте) практически никогда не уводил флэшку в read-only, «добивая» её до последнего. Из минусов такого подхода — если флэш помирала совсем, то данные из нее можно было достать только с помощью программатора, да и то не факт.
В моей довольно большой коллекции нет ни одного смартфона с Legacy NAND, где флэш бы действительно «приехала», хотя на форумах мастеров иногда встречаются старые сообщения о замене флэши на телефонах Nokia.
Второй тип памяти появился примерно в начале 2010х годов и имя ему — eMMC. Фактически, eMMC — это адаптация интерфейса MMC для использования в виде обычных чипов памяти, а не карточек, совместимая с спецификацией ~SDHC. Если выпаять чип с телефона и припаять сигнальные линии к обычному SD-кардридеру на ПК — он будет работать и определяться как полноценный диск! Таким образом, на некоторых смартфонах можно заменить eMMC на MicroSD напрямую припаяв флэшку на место чипа к соответствующим сигнальным линиям. Однако работать такое будет только если у вашего смартфона «бутербродная» компоновка, где ОЗУ припаяна поверх процессора (MTK и Spreadtrum в пролете). В eMMC используется память типа NAND, которой управляет не чипсет, а встроенный в сам чип памяти контроллер, работающий с протоколом MMC и имеющий собственную прошивку и карту бэд-блоков. Такая флэш-память может самостоятельно уходить в режим read-only когда это посчитает нужным контроллер, зачастую не давая смартфону загрузится, но при этом потенциально сохраняет данные пользователя и позволяет их прочитать дома (сделав дамп памяти устройства и смонтировав раздел userdata в Linux). Однако всё равно иногда данные теряются безвозвратно. Нюанс в том, что состояние eMMC определяет сам контроллер в чипе — поэтому «оживить» его дома и вывести из read-only невозможно. Однако я слышал, что на некоторых «бракованных» чипах памяти (в основном Samsung 2012-2013 годов), которые ушли в read-only слишком рано, можно подпаяться к тест-поинтам программатором и прошить чуть более свежую прошивку с другой ревизии этого же чипа памяти. Флэшка, бывало, оживала.
В некоторых случаях, eMMC были бракованными с завода и помирали сами по себе (!) через короткое время (около года) после покупки устройства. Я знаю как минимум два примера массового брака флэш-памяти: смартфоны HTC 2011-2012 годов, которые время от времени страдали от валящихся чипов Hynix (это касается не всех устройств, многие дожили), хотя я лично видел не так много HTC'шек с дохлой памятью, так что здесь читатели-сервисники с опытом работы в те годы могут только подтвердить или опровергнуть мои слова. А вот подтвержденный пример — смартфоны и планшеты Samsung 2012-2014 годов. Galaxy S3 с артефактами на дисплее при включении, S4 Mini в 9008 или повисшие на заставке, S4 с теми же симптомами, S4 Zoom, которые практически все померли «сами по себе» после обновления до 4.4 KitKat, N8000… Добавьте к этому слабые NC-пятаки, которые срывает при попытке снять чип феном, близко расположенный «бутербродный» процессор, который легко «убить», если орудовать феном, компаунд… и по итогу многие мастера просто спиливали чип дремелем. А что ещё делать!?
По итогу, нам остаётся искать софтварные способы загрузить систему с внешней MicroSD флэшки. И я нашел два таких способа! Первый — предварительно подготовить образ boot.img и прошить его в смартфон вместо recovery, дабы если память ушла в read-only, мы могли просто «дуалбутнутся» во второй образ с пропатченными точками монтирования системных разделов на MicroSD. А о втором, к сожалению, знают лишь единицы, хотя это просто замечательный способ, который позволяет загрузить систему уже «пост-фактум» после ухода флэшки в read-only и требует некоторых манипуляций с fastboot! Давайте же рассмотрим его подробнее.
Нашим подопытным будет рабочий смартфон Alcatel OT-5020D 2013 года выпуска, который пока не подает признаков помирающей eMMC: к сожалению, смартфонов с полудохлой памятью и разлоченным бутом у меня не оказалось, дохлые флэшки я иногда меняю и сам :) Но тем не менее, грузиться мы в любом случае будем с флэшки и вы сможете повторить все шаги в статье, дабы загрузить систему с MicroSD самому!
Друзья! Для следующих действий, вам понадобится разблокированный загрузчик или устройство, на котором с завода загрузчик не заблокирован. Главный критерий — наличие режима fastboot.
Какие устройства не подойдут: многие смартфоны на базе чипов Spreadtrum, а также часть смартфонов Samsung на Exynos. Ни те, ни другие частенько не имеют режима fastboot от слова совсем. У Samsung есть режим загрузки с MicroSD (т. н. T-Flash Mode), но ядро он не грузит.
Какие устройства подойдут, но требуется подготовка: все смартфоны от Sony (исключение — Xperia Tipo, забагованный fastboot), Google Nexus (некоторые модели страдали из-за отвалов флэши), современные китайские новодельные noname-смартфоны (с вот таким патчем), Xiaomi, Meizu. Чипсеты: MediaTek 67xx/Qualcomm Snapdragon, возможно Kirin. Таким устройствам требуется предварительная разблокировка загрузчика.
Какие устройства подойдут даже при условии уже мертвой флэш-памяти: большинство девайсов на базе чипсетов MediaTek прошлого десятилетия, особенно бюджетных: MT6572, MT6582, MT6592, MT6580, MT6570, MT6575, MT83xx, некоторые Spreadtrum. Это касается Fly, Explay, ZTE и многих других ультрабюджетных смартфонов тех лет. Загрузчик там разблокирован с завода, никакого секьюрбута и верификации загружаемых образов нет. Но не везде можно загрузится в fastboot напрямую (попробуйте громкость вверх и громкость вниз при включении — если сразу грузится в рекавери, то нужно до отказа eMMC включить ADB, если показывает менюшку fastboot, recovery, normal boot — значит все ок).
Не подойдут: MT6573, MT6571 — там U-Boot (но его тоже можно попробовать заставить грузиться с SD).
Список устройств для потенциальной возможности загрузки с SD весьма большой! Как понять, что eMMC «всё»?
Смартфон не реагирует на зарядку и кнопку включения при заряженной АКБ: это не 100% показатель, но если поднимаются питальники с КП и потребление от кнопки есть ~0.1-0.3А — значит процессор вероятно пытается стартовать. Но не откуда. В таком случае, девайс поднять не получится — доступа к fastboot нет, флэшка полностью посыпалась. Исключение — некоторые Qualcomm'ы при наличии прожженного фьюза с завода, разрешающего загрузку с MicroSD могут стартовать ядро, но всё зависит от конфигурации aboot.
Смартфон загружается и сразу вылетают приложения, настройки не сохраняются: явный показатель того, что флэша ушла в read-only потенциально не повредив данные. Если смартфон грузится в fastboot — его ещё можно оживить, но не факт что получится вытащить данные (из-за шифрования). Если после сброса до заводских настроек эффект остается тот-же — eMMC приехала 100%.
Смартфон висит на заставке, сброс и прошивка не помогает: тоже явная причина: eMMC в read-only. В таком случае, не рекомендуется еще раз шить смартфон в надежде что все заработает, есть шанс что флэша посыпеться окончательно и вы потеряете доступ к fastboot.
Весьма всё просто, согласитесь? Как я уже сказал выше, на некоторых устройствах нужно сначала разблокировать загрузчик. Кое-где это, вероятно, получится сделать и при том что флэша ушла в read-only. Например, на устройствах Sony можно без проблем зайти в fastboot и разлочить устройство с помощью кода, полученного на сайте Sony (используйте VPN, если вы в РФ):
Как зайти в fastboot — вам придётся погуглить для конкретно своего устройства. Не нашли? Поищите как это делается на других смартфонах, которые работают на том же чипсете. Почти всегда можно зайти, если у вас включена отладка по USB с помощью команды:
adb reboot bootloader
Краткая справка: на устройствах Sony, в Fastboot можно зайти подключив устройство к ПК с зажатой громкостью вниз, на MTK громкость вверх или вниз, на HTC в HSPL, на Nexus'ах в фирменном загрузчике сразу режим Fastboot, на устройствах Tegra — включение с зажатой громкостью вверх, на смартфонах с чипсетом Intel есть fastboot, насколько помню зайти в него можно с помощью громкости вниз.
Команда для разблокировки загрузчика почти везде одна:
fastboot oem unlock
Вас могут запросить код разлочки или просто предупредить о последствиях такого действия. Как узнать, что бут разлочен?
fastboot getvar all
secure, locking и т. п. — отвечают за статус разлочки. Но даже если таких переменных нет, это не всегда значит, что загрузчик заблокирован. Возможно он разблокирован с завода :)
Теперь нам нужен образ раздела boot — boot.img. Его можно найти в файлах родной прошивки устройства, или, иногда, в zip-файлах кастомов. boot.img содержит в себе ядро Linux и небольшой раздел с файловой системой initrd (рамдиск), которая загружается в оперативную память и содержит в себе программы init, adbd, recovery, а также скрипты инициализации, которые управляют загрузкой Android и процессом зарядки (показывают анимацию, когда вы подключаете устройство выключенным к ЗУ. Да, в таком случае Linux тоже грузится!).
Если у вас есть доступ к fastboot, то попробуйте запустить его с помощью команды:
fastboot boot boot.img
Работать она будет не везде, на MTK её поддержка отключена в загрузчиках некоторых устройств. Если вы увидели на экране устройства USB Transferring — половину дела сделана! Если устройство показало лого и анимацию загрузки или ушло в ребут — потенциально, вы сможете загрузить Android с MicroSD. Если ошибка secure-boot — нужно сначала разблокировать загрузчик. Если unknown command — команда не поддерживается :(
Теперь у нас есть возможность загрузить ядро и пропатчить скрипты конфигурации, дабы изменить точки монтирования раздела /system/, /data/ и /cache/ на MicroSD-флэшку, вместо встроенной памяти.
Обратите внимание: Android очень интенсивно использует ресурс флэшки и постоянно перезаписывает сектора памяти, поэтому не поскупитесь купить нормальную MicroSD флэшку от, например, Transcend, Kingston или Samsung. Дешевые MicroSD флэшки очень-очень быстро (вероятно, за пару дней — это не шутка) выйдут из строя и придется делать всё заново!
Сначала, нам придется разбить флэшку на три раздела: /system/, /cache/, и /data/. Раздел system будет первым, cache — вторым, data — третьим. При этом раздел /sdcard/ не нужен — он автоматически маппится в /data/media/ на современных версиях Android. Сделать это можно как с ПК с помощью MicroSD-адаптера и fdisk/diskpart/gparted, так и с самого смартфона с помощью того же fdisk в busybox. Я решил это сделать с помощью другого вспомогательного смартфона с TWRP, где изначально был root-доступ через adb! Размеры выбирайте следующие: для системного диска чуть больше или по размерам с system.img (раздел read-only и не «растет» со временем), cache — 100-200Мб, userdata — всё оставшееся место на флэшке.
Разметили MicroSD? Теперь нам нужно записать на неё образ системы. Тут три пути: если у вас есть Linux-машина, то можете подмонтировать образ system.img из оригинальной прошивки и скопировать все файлы с сохранением прав, закинуть system.img в внутреннюю память другого смартфона с root-доступом и проделать все тоже самое, либо записать с помощью dd образ system.img напрямую в нужный нам раздел флэш-памяти. Я выбрал третий способ:
dd if=/sdcard/system.img of=/dev/mmcblk1p1
Разделы cache и userdata можно просто форматировать в ext4:
mke2fs -t ext4 /dev/mmcblk1p2
mke2fs -t ext4 /dev/mmcblk1p3
Готово! Необходимые для базовой работы разделы перенесены на MicroSD. Теперь, когда, у нас есть образ системы, нам нужно распаковать родной boot.img устройства и поменять точки монтирования. Я использую кухню MTKImgTools. Идём в Boot -> Unpack -> boot.img. В Unpack/boot/ появятся файлы нашего раздела boot:
Открываем файл init.rc (в случае MediaTek). Ищем строки с монтированием разделов вида emmc@system, emmc@cache, emmc@userdata и меняем их на /dev/block/mmcblk1p1, /dev/block/mmcblk1p2 и /dev/mmcblk1p3. На некоторых чипсетах, править нужно сразу fstab, или init.<чипсет>.rc:
Готово! Собираем образ обратно с помощью Boot -> Pack -> boot.img и получаем образ, который нам и надо будет загрузить с помощью fastboot. Копируем boot.img в папку с adb и пробуем загрузить систему. Это будет основная команда для старта загрузки смартфона в будущем:
fastboot boot boot.img
Увидели бутанимацию? Значит система пошла загружаться, нужно лишь подождать первой загрузки 5-10 минут! Система висит на лого или уходит в ребут? Значит, возможно, вы неверно прописали точки монтирования, записали образ system или форматировали раздел userdata. Если система 4.4 и ниже, то можно изменить default.prop, заменив ro.secure на 0 и debuggable на 1. Если вы на Android 5+ — то заменить adbd (не требующий ключи авторизации) в /system/bin на вариант из TWRP и посмотреть logcat и dmesg. Монтируется ли /system/? Загружается ли app_process? На каком этапе стопорится? Всё это пригодится при дальнейшей отладке!
Например, такая ошибка при запуске adb shell означает то, что раздел /system/ не монтирован.
Ну а на моем девайсе система уже загрузилась и работает. Но насколько шустро? В комментариях читатели часто говорили, что из-за скорости MicroSD система будет не юзабельной. Насколько это правда? Давайте посмотрим!
Вывод mount:
Как мы и видим, /system/, /data/ и /cache/ на MicroSD. custpack и mobile_info, а также nvram трогать не нужно — если в родной флэше они не повреждены, то у девайса без проблем будет работать и сеть, и Wi-Fi.
Наш девайс работает на базе Android 4.2 — казалось бы, совсем старенький дроид, но тем не менее ещё кое-что, да может. Alcatel OT — это бюджетный девайс из 2013 года, но работает он, на удивление, весьма шустро и приятно!
Начинаем с самых необходимых приложений — звонилка, контакты и галерея. Все эти приложения стартуют практически моментально, лишь иногда с небольшими лагами. Однако если поставить в браузере что-то скачиваться на фоне — конечно-же, система начнет лагать.
Как насчет браузера? Ставить последний хром, поддерживающий 4.2 смысла нет — уже и он открывает далеко не все сайты. Но те сайты, что пока ещё открывает стандартный браузер почитать ещё можно: например, opennet. На смартфонах с более свежим Android, браузер будет работать относительно адекватно. Зато с соц. сетями проблем особых нет. Telegram, конечно, может конкретно подвесить смартфон в процессе подгрузки картинок с каналов, но потом все будет нормально. Решение одно: отключить автоматическое кэширование картинок и видео!
С записью видео ситуация сложная. Даже в профессиональных камерах для 1080p рекомендуются карточки не ниже 10-класса (10Мб/с) и UHS-класса для 2+K видео. На нексусе, это скорее всего превратит девайс в лагодром даже при записе 720p видео: система в фоне так или иначе регулярно читает и записывает данные и рано или поздно мы упираемся в дисковой кэш.
Об играх с динамическим стримингом ресурсов можно забыть, если флэшка достаточно медленная — будут лаги.
А в динамике это всё выглядит так:
Достаточно шустро, для смартфона 2013 года за 4 тыщи рублей?
Сегодня мы с вами узнали, каким же образом можно перенести систему на MicroSD! Да, сработает далеко не на всех девайсах, однако сам способ может помочь поднять сотни устройств обратно в строй и сделать их полезными! Это всяко лучше, чем распаивать потенциально рабочие девайсы на «доноров» или, тем-более, отправлять их на мусорку или в чермет. С современными версиями Android ситуация сложнее: и не только из-за большего числа необходимых для загрузки разделов, но и из-за возросших требований к скорости флэш-памяти (упомянутые выше UFS работают на скорости ~500Мб/с), а также, внезапно, стремительно исчезающего слота для MicroSD :(
Надеюсь, материал вам был полезен! Сегодняшняя статья подготавливалась специально в «классическом», более коротком стиле с максимумом конкретики. Если вам больше нравится такой формат, нежели подробный на 15-20+ минут на чтения — напишите в комментариях!
Кстати, если у кого-то из читателей есть ненужные устройства (в том числе с косяками) или дешевые китайские подделки на айфоны/айпады/макбуки и другие брендовые девайсы будучи нерабочими, тормозящими, или окирпиченными и вам не хотелось бы выкидывать их на свалку, а наоборот, отдать их в хорошие руки и увидеть про них статью — пишите мне в Telegram или в комментах! Готов в том числе и купить их. Особенно ищу донора дисплея на китайскую реплику iPhone 11 Pro Max: мой ударник, контроллер дисплея калится и изображения нет :(
А ещё у меня есть Telegram-канал, куда я публикую различные заметки по ремонту, программированию и моддингу девайсов, свои мысли и вовремя публикую ссылки на новый материал!
Статья подготовлена при поддержке TimeWeb.Cloud. Подписывайтесь на меня и @Timeweb.Cloud, чтобы не пропускать новые статьи каждую неделю!
А еще получит ачивку в профиль. Рискнете?
Моддинг-сцена с разработкой и портированием кастомных прошивок для Android-устройств существует вот уже более 10 лет. В основном, энтузиасты пытаются проапгрейдить свои устройства путем портирования более свежих версий Android, чем предлагает производитель девайса. Чего уж говорить, если Galaxy S III, которому уже 12 лет стукнуло, получил неофициальный апгрейд до Android 14. Порой мне в голову приходят различные, весьма странные моддерские мысли: например, почему бы не портировать на старенький смартфон… ещё более старую версию Android, дабы посмотреть «что будет». Казалось бы «портировал и портировал», но в процессе работы я столкнулся с множеством интересных нюансов и особенностей работы Android, о которых хотел бы рассказать и вам — моим читателям! Сегодняшняя статья будет в классическом «научпоп»-стиле без кода, зато с подробными объяснениями одной из техник портирования Android-прошивок путем патчинга скриптов для конфигурации системы и подмены Board-specific библиотек, дабы система «увидела» всё необходимое железо! Интересно? Тогда жду вас под катом!
У меня, как и у многих моих читателей, одной из первых версией Android в жизни была 2.x. Наверное, я уже никогда не смогу забыть первые впечатления от использования своего новенького, пусть и бюджетного и слабого Android-смартфона после простеньких китайских кнопочников. Эти ощущения были прекрасными: вот я разблокирую смартфон, потянув «замочек» вправо, свайпаю рабочие столы и тапаю на значок приложения браузера, выполненный в стиле скевоморфизма, загружаю полноценную страницу Википедии через GPRS-сеть (мой первый смартфон не имел 3G) и плавно скроллю страницу, не забывая смахнуть шторку вниз и проверить статус уведомлений в пока ещё совсем простенькой панели нотификаций… Это были по настоящему ламповые впечатления, которые не смог превзойти ни один современный девайс: ни AOSP, ни MIUI, ни OneUI.
Моим первым смартфоном была китайская реплика Samsung Galaxy S III Mini, купленная в самом начале 2013 года. Возможно, кто-то из вас помнит, как подобные дешевые смартфоны и планшеты «Sumsanc» можно было купить на рыночных развалах, в метро и прочих местах, где допускается торговать несертифицированными гаджетами. Даже с учётом накрутки, эти смартфоны стоили всего 2 000 рублей, что было просто «подарком» для цены абсолютно нового гаджета. Девайс был крайне простым для начала 2013 года и имел следующие характеристики:
Процессор: Spreadtrum SC6820. Одно ядро Cortex-A5 на частоте до 1ГГц, Mali400 MP в качестве GPU. Чипсет был крайне высоко-интегрированным для своих лет: в одном корпусе располагалось ARM-ядро, GPU, контроллер питания, GPS, множество периферии (например, DAC), а также Baseband-часть GSM-радиотракта. BT/Wi-Fi реализовывались в отдельном комбочипе разработки RDA.
Память: 256Мб DDR1 ОЗУ/256Мб NAND-памяти в одном чипе eMCP от Hynix. Предположительно, эти чипы остались на складах ещё со времен первых Android-смартфонов, но очень быстро потеряли актуальность и их, вероятно, отдавали «за бесценок» что позволило ещё сильнее снизить цену производства таких смартфонов.
Дисплей: безоговорочно, TFT, обычно с разрешением не выше 480x320, что для 3" дисплея было нормальным, но для 5" — уже несколько маловато. Тем не менее, сами дисплеи были нормальными и глаза от них не «вытекали». Тачскрин обычно ёмкостной, на 2 касания.
Android: 2.2, на некоторых похожих моделях встречался 2.3.
Аккумулятор: ~1.500мАч, не больше. По форм-фактору напоминает BP-4L, без проблем подходит от многих S60 смартфонов Nokia тех лет.
Не густо, да? Уже в апреле того же года вышел Galaxy S4 с Snapdragon 600, 2Гб ОЗУ и 32Гб встроенной памяти, а мы тут с одноядерным чипсетом и 256Мб ОЗУ сидим. Но мне, будучи школяром, это было за счастье — чего я на нём только не делал, и на PHP какие-то WAP-сайты динамические пытался писать и на FTP заливать, и даже ADT Bundle скачал, дабы попытаться что-то своё запилить под собственный смартфон! В общем, я был счастлив, несмотря на лаги девайса. Именно того девайса у меня уже давным-давно не осталось… но память я всё ещё храню и стараюсь дать новый дом таким китайчикам, которые в большинстве своем оказались на свалке истории в новом мире современных смартфонов!
Но на самом деле, смартфоны 10+ летней давности могут быть интересны и своим форм-фактором: в современном мире едва ли можно найти хоть какие-то телефоны с полноценной QWERTY-клавиатурой (исключение — смартфоны UniHertz, которые стоят недешево) и уж тем более, боковые слайдеры. Поэтому мой интерес к подобным девайсам очень легко объяснить!
Однако, порой мне самому хочется снова пережить эти эмоции и ещё раз походить с подобным девайсом «на каждый день», даже когда на Android 2.2 особо никакие сервисы уже не работают. Отчасти, я решаю свои проблемы сам и пишу клиенты нужных мне сервисов, если они действительно нужны, дабы рано или поздно всё таки вдохнуть новую жизнь в «старенькие» девайсы. И казалось бы, это можно списать на синдром утёнка и банальную ностальгию, но мои ощущения «ламповости» отнюдь не мимолетны и всё равно меня тянет именно на те смартфоны, с тем самым интерфейсом, которые я когда-то увидел впервые!
Пожалуй, сказать что я решил портировать старый Android на отнюдь не новый смартфон «просто так» было бы ложью. Я всё ещё верю в то, что смогу в одиночку хотя бы частично вдохнуть новую жизнь в эти девайсы и позволить им работать с современными сервисами, дабы они могли приносить пользу не только мне, но и другим людям, которые намеренно занимаются дауншифтингом или вынуждены сидеть на девайсах с старыми версиями Android! Сегодняшним нашим подопытным станет один из представителей подобных noname-смартфонов тех лет, реплика Galaxy S III Mini на том самом железе, на котором работал мой первый смартфон. Однако с завода на нём стоял Android 2.3 — слишком свежая, по моему мнению, версия системы, которую я конечно-же захотел откатить до Android 2.2!
Задача облегчалась тем, что смартфоны на этом чипсете с Android 2.2 уже выходили, что позволило мне портировать прошивку путем несложных патчей скриптов инициализации и копирования Platform-specific файлов, дабы завести все необходимые для смартфона модули. А поскольку о таком простом способе портирования свежих и старых прошивок знают далеко не все мои читатели — я решил написать об этом отдельный подробный материал! Давайте же перейдём к практической части нашей статьи.
Перед тем, как начать портирование системы, нам необходимо разбираться в том, как вообще происходит процесс загрузки Android и какие процессы при этом загружаются. Вкратце, описать весь процесс загрузки можно так:
Загрузчик: при включении смартфона, первичный загрузчик BootROM, аппаратно-прошитый в чипсет ещё на этапе изготовления чипа, инициализирует некоторую периферию, загружает вторичный загрузчик из NAND (коим может быть SPL — Second Program Loader, занимающийся инициализацией контроллера DDR и UART) и передаёт ему управление. Вторичный загрузчик в свою очередь передаёт управление U-Boot — в задачи которого входит также инициализация периферии, обработка устройств постоянной памяти (например, NAND или контроллер SD), загрузка ядра Linux и конфигурация самого процесса загрузки. U-Boot можно считать эдакой альтернативной UEFI/BIOS в мире не-x86 устройств. В смартфонах на базе чипов MediaTek и Qualcomm, роль U-Boot выполняет LK — маленькая ОС, в задачи которой входит инициализация периферии и передача управления ядру Linux с помощью программы aboot.
Ядро Linux: после загрузки образа ядра с initrd (небольшая файловая система, которая загружается сразу в память и содержит в себе скрипты для конфигурации всего остального) и передачи управления ядру, Linux начинает выполнение программы с PID 0 — /init, в задачи которой входит выполнение скриптов инициализации userspace-окружения системы в init.rc. При этом смартфон уже фактически готов к работе — в одной из своих статей я показывал, как можно приостановить загрузку Android и выполнять свой код, используя все ресурсы смартфона для своих целей.
zygote и app_process: помимо запуска необходимых для работы смартфона служб, динамической загрузки драйверов (с помощью insmod) и определения режима загрузки (например, если телефон подключили выключенным к зарядке — необходимо показать анимацию этой самой зарядки), init.rc запускает две программы, одна из которых необходима для функционирования системы. Первая — это bootanimation, которая проигрывает анимацию включения смартфона и app_process, который в одном из режимов работы превращается в zygote — самый важный процесс для работы Android, который предварительно при старте системы загружает системный Java-байткод, отвечающий за отрисовку интерфейса, проигрывание звука и т. п. из framework.jar и другие системные ресурсы (например темы и изображения), а затем при запуске каждого приложения просто клонирует сам себя (с уже загруженными ресурсами) и начинает выполнение байткода любого запущенного Android-приложения или службы.
Каждое запущенное приложение или служба — это отдельный app_process, в том числе и лаунчер, и Google-сервисы и клиент любого мессенджера.
Всё выглядит просто и логично, не так ли? Подытожив, можно сказать что для того, чтобы система минимально стартовала, нам необходима подходящее ядро для нашего устройства, рабочий init.rc и адекватно запускающийся init.rc. Кроме того, Android зависит от некоторых платформо-специфичных библиотек: в основном, они находятся в /lib/hardware и без них система может не запуститься или что-то может не работать. Особенно осторожно надо подходить к libhardware.so.
Как я уже сказал выше, прошивку мы будем портировать от другого смартфона на том-же чипсете и что забавно — такую же реплику, просто более-раннюю! «Из коробки», мой смартфон работает на Android 2.3, значительно более стабильной, чем изначальный порт 2.2 на эту платформу. Отличий 2.3 от 2.2 достаточно: например, на 2.2 совсем иной цвет шторки, по умолчанию стоит Light-тема, нельзя закрывать уведомления смахиванием и в целом система несколько отличается внешне. Для работы нам нужно будет два образа прошивки: ту, которую будем портировать и та, которая стоковая. Прошивки в смартфонах на платформе Spreadtrum распространяются в формате pac, однако нет никаких проблем подменить образ раздела в ResearchDownload — фирменной утилите для прошивки смартфонов на этом чипсете.
Я решил взять прошивку от FeiTeng N9300 Mini, родная для моего смартфона — M-Horse 9500 Mini. В случае моего девайса, разметка и список разделов между устройствами никак не отличалась, поэтому изначально я напрямую прошил раздел system.img, дабы посмотреть что будет с устройство. Не забывайте, что ядро и init.rc хранится в образе boot.img — поэтому прошивка раздела system безопасна!
После прошивки чужого раздела system, смартфон стартовал… однако работал несколько странно: во первых, у нас не было сети, во вторых не работал тачскрин (при родном то ядре), а в третьих, Android ни в какую не видел аккумулятор, вися на 0% и моментально отключаясь, если смартфон не стоит на зарядке, а при попытке воткнуть кабель — смартфон показывал индикацию зарядки, но потребление было на нуле.
Поскольку тачскрина у нас нет, root доступ через adb придется включать «ручками» — для этого нам необходимо перепаковать наш родной раздел boot. Для распаковки и запаковки образов, я пользуюсь MtkImgTool — весьма удобная «кухня» для работы. Вытаскиваем boot.img из pac, закидываем в Unpack/Image/ и распаковываем с помощью Boot -> Unpack -> boot.img
В Unpack/boot/ramdisk/default.prop нам необходимо изменить ro.debuggable на 1, а ro.secure на 0. Это даст возможность отлаживать устройство даже если Android фактически не загрузился.
Теперь у нас есть root-консоль устройства, даже если смартфон висит на заставке. Прошиваем обратно образ, пишем adb shell в консоли и смотрим, что же тут не так… Вообще, драйвер тачскрина обычно статически слинкован с ядром, но в случае устройств Spreadtrum — они вынесены в динамические модули ko, которые можно найти в папке /lib/modules/, либо /sps/. Давайте глянем init.sp6820a.init.3rdparty.rc, который отвечает за специфичную для этой модели смартфона инициализацию.
Ага, видим insmod gt868.ko? Это команда загрузки драйвера тачскрина, в нашем случае — это вышеупомянутый GT868. Иногда встречаются другие модели тачскринов, но главное отличие прошивки 2.2 от 2.3 — разные названия папок с драйверами и некоторые службы. Достаём из родного образа драйвер gt868.ko, используя всё тот-же MtkImgTools, распаковывая его как обычный ext2 раздел:
Пишем в консоли устройства:
adb push / gt868.ko
adb shell
insmod /system/lib/modules/gt868.ko
И наслаждаемся тем, что у нас теперь появился тачскрин! Android сам подхватил новое устройство ввода, поскольку драйвер тачскрина — обычное устройство в /dev/input/. Чтобы драйвер грузился при загрузке, его достаточно добавить в init.sp6820a.3rdparty.rc, предварительно закинув в раздел /system/. Перед этим, раздел нужно перемонтировать для возможности записи:
on boot
insmod /system/gt868.ko
adb shell
busybox mount -o remount,rw /system/
mkdir /lib/modules/
exit
adb push gt868.ko /lib/modules/
После модификации rc-скрипта, нужно обратно запаковать boot.img с помощью MtkImgTools и прошить его с помощью ResearchDownload — тачскрин будет работать даже после перезагрузки!
Переходим к отсутствию связи с аккумулятором и нулевым потреблением АКБ. Здесь мне пришлось несколько покопаться и почитать логи ядра с помощью команды dmesg. Я обратил внимание на то, что некая служба пишет что-то об аккумуляторе, но разобраться было несложно: в папке /system/bin я нашёл программу charge, которая, очевидно, отвечает за настройку КП для старта зарядки. Что она точно делает — мне неизвестно, возможно корректирует какие-то значения в sysfs, возможно с помощью ioctl общается с драйвером КП и даёт разрешение на старт зарядки и обновление информации в sysfs. В любом случае, после замены /system/bin/vcharged на оный из родной прошивки, зарядка заработала.
Для этого мы снова перемонтируем /system/ в режим записи и копируем vcharged, не забыв вернуть обратно необходимые права:
adb push charge /system/bin/
adb shell
chmod 777 /system/bin/charge
Перезагружаем устройство и… зарядка с индикацией появилась!
Вроде всё работает на первый взгляд: и звук, и вибро, и Wi-Fi с Bluetooth… однако сети-то нет! Девайс не определял наличие SIM, а вместо IMEI у нас был null/null:
Чтобы её поднять, нам необходимо разобраться в том, как работает подсистема взаимодействия с радиомодулем в Android, которая называется ril — Radio Interface Library. RIL предоставляет API для системы, дабы оперировать не напрямую AT-командами (которые могут быть проприетарными, а на некоторых чипсетах, как, например, Qualcomm вообще отсутствовать), а удобным набором функций — например о запросе статуса радиомодуля, начале звонка, поиска сети и т. п. RIL состоит из сервиса rild в /system/bin/ и библиотеки libril.so, которую можно найти в папке /system/lib/. При запуске системы, TelephonyManager открывает сокет с rild и опрашивает его состояние. Именно из TelephonyManager система берет информацию о силе сигнала, название оператора, IMEI и другие данные.
Путем ковыряния в dmesg я понял, что система флудит из-за невозможности запустить проприетарный сервис Spreadtrum — sprd_monitor. При попытке позвонить в 112, смартфон бесконечно пытается включить радиомодуль. Я ковырялся в UI-части исходного кода Android, дабы понять логику работы, но проблема крылась как раз в упомянутых выше службах sprd_monitor. Берём их из /system/bin/ оригинальной прошивки, закидываем их в устройство, не забыв установить права и отправляем систему в ребут:
adb push engappclient /system/bin/
adb push engmodemclient /system/bin/
adb shell
chmod 777 /system/bin/engappclient
chmod 777 /system/bin/engmodemclient
Ошибки в dmesg пропали, IMEI появился, но устройство до сих пор не хочет никуда звонить и просто висит на экране звонка. В настройках смартфон говорит о том, что уровень сигнала недоступен, а значит, радиомодуль до сих пор не работает :(
Но и мы так просто не сдаемся! Поковыляв по файловой системе, в директории /system/opl/telephony/bin/ я нашел скрипт, отвечающий за инициализацию радиотракта, который вызывает родной 3rdparty.rc! Запускаем sh-скрипт и обнаруживаем, что сеть появилась и девайс дозвонился в 112, а также увидел SIM-карту!
sh init.tel
Теперь всё полностью работает :) Дабы радиотракт запускался при старте устройства, я перенес часть инита из boot.img от прошивки, которую мы портировали. Для кого-то, казалось бы, это всё достаточно сложно и долго. Но у меня ушел всего один день на полную отладку и запуск такой кастомной прошивки на своем устройстве! Можно сказать, это самый базовый и краткий экскурс в такое нелегкое дело, как моддинг Android-устройств.
Но мы ведь это всё не просто так делали! Давайте глянем, как будет работать такой девайс на Android 2.2 в 2024 году — спустя 14 лет после выхода системы. Всё ли так плохо, как кажется?
Думаю, многие читатели вспомнят этот ламповый интерфейс, обои с одуванчиком и лаунчеры а-ля TouchWiz на тех смартфонах, где интерфейс Samsung был не предусмотрен. А эти «бульк»… их сложно забыть!
Конечно, изначально может показаться, что устройство плохо подходит для выполнения современных задач: браузер не способен загрузить большинство страниц, а из альтернатив есть только Opera Mini, где вообще нет динамического контента, а официальные клиенты ВК, WhatsApp и YouTube уже давно не работают. Опечаленный читатель может подумать, что девайс, как и многие его ровесники уже давно превратились в звонилки…
Но это отнюдь не так! Ведь как я уже говорил, я стараюсь своими силами вдохнуть в подобные девайсы новую жизнь, реализуя на них клиенты нужных мне сервисов сам! Да, пусть примитивно и корявенько, далеко не ынтырпрайз-уровень, но эти приложения выполняют свои функции и что, немаловажно, весят очень мало (до 100Кб) и работают крайне шустро! Клиент ВКшечки просто летает, несмотря на то, что фактически реализован только мессенджер с нотификациями и музыка.
Пожалуй, многие читатели удивятся — но на таких девайсах есть YouTube! Мой самопальный клиент не поддерживает стриминг из сети (да и многие девайсы объективно не потянут), поэтому предварительно загружает видео на MicroSD-флэшку и затем уже их воспроизводит. Как приятный бонус — видео потом можно посмотреть в любой момент в галерее.
Я помню насколько было лампово слушать музыку с таких девайсов. И если претензии к основному динамику не очень актуальны, то к качеству звука в наушниках были придирки — звук был громкий, но ему не хватало низких частот, из-за чего он звучал несколько плоско, хотя мне и этого хватало — ведь я слушал музыку в наушниках по 200-300 рублей с рынка! Я всё ещё помню те времена, как качал mp3-треки по 2-3 мегабайта через 2G-интернет… слушаешь один трек — как раз загрузится другой и так по кругу наполнял свою фонотеку. Эх времена то какие были! Тем не менее, для некоторых базовых мультимедийных возможностей девайс подходит и сейчас, например в машину в качестве BT-хоста с музыкой.
А ещё на таких девайсах порой клёво скачать какой-нибудь Temple Run образца 2011 года и вспомнить самое начало смартфонного гейминга тех лет… ведь далеко не все игры того времени запускаются на свежих версиях Android!
В остальном же, подобные девайсы отнюдь не бесперспективны! Несмотря на совсем не новое железо, они всё ещё могут выполнять многие задачи, стоит лишь снова запилить необходимые приложения для них! Мессенджеры, соц. сети, музыкальные сервисы и даже просмотр видео — всё это доступно даже для таких, казалось бы, «устаревших» девайсов, когда есть запал энтузиазма и жгучее желание походить именно с этим конкретным устройством как с основным!
Для кого-то это просто проявление синдрома утенка или картинки «вот кому-то делать не.»… ну а для меня — это крайне интересное, захватывающее и кайфовое времяпровождение: начиная от аппаратного ковыряния с такими девайсами и копания исходников ядер/драйверов, заканчивая написанием оптимизированных клиентских приложений, которые весят не 100-200Мб, а 100-200Кб :)
Друзья, если у вас есть подобные китайчики и вы не разделяете желания пытаться вдохнуть в них жизнь, но выбрасывать их жалко — можете задонатить их мне :) Как сами видите — девайсы попадают в хорошие руки. Из недавнего — я взял нерабочую, утопленную китайскую копию 14 Pro Max из под СЦ в качестве основного смартфона. Также у меня есть канал в Telegram, куда я выкладываю бэкстейджи статей, различные заметки о ремонте, моддинге, программировании и реверс-инжиниринге и свои мысли. Кому интересно — залетайте!
Понравилась ли вам статья? Какими были ваши первые Android-смартфоны? Пишите в комментариях, будет интересно почитать!
Пожалуй, рубрика, связанная с обзором и ремонтом различных ноутбуков уже успела стать одной из самых любимых среди моих читателей. Мы с вами успели рассмотреть множество весьма необычных и диковинных устройств прошлых лет: ноутбуки на базе процессоров Transmeta Crusoe, миниатюрные японские девайсы с графикой PowerVR и даже бюджетные ARM-смартбуки на базе различных Linux-дистрибутивов! Поскольку желание копаться в девайсах, писать код и созидать что-то своё у меня возникает даже в дороге, моё творческое начало постоянно требует дописывать и переписывать черновики будущих статей в редакторе Хабра. Для этих целей, мне нужна была надёжная, портативная рабочая машинка, на которой я мог бы с комфортом заниматься подготовкой будущих статей. И этой машинкой оказался получивший апгрейд Ninkear N14 Pro! Что за девайс мы получаем за 40.000 рублей? Читаем в статье!
Что за девайс и на кого он рассчитан?
Сейчас на рынке представлен довольно широкий выбор различных портативных лэптопов: начиная от лёгких и достаточно шустрых Windows-планшетов с клавиатурой-крэдлом, заканчивая мощными и тяжелыми игровыми девайсами-«печками». Крайне большой популярностью пользуются различные бюджетные ультрабуки на базе «околопланшетной» платформы Intel Celeron J-серии, которые в основном берут для базового серфинга в интернете, работы с документами и даже, в некоторой степени, для старых игр.
Однако производительности девайсов на базе бюджетных Celeron и Pentium может не хватать для достаточно ресурсоёмких задач: например, разработка современных UWP и Android-приложений, развёртывание множества Docker-контейнеров, монтаж видео и обработка звука и тогда приходится искать что-то пошустрее, пусть даже на базе достаточно шустрых процессоров позапрошлого поколения.
Недавно компания Ninkear выпустила апгрейд своей шустрой и компактной рабочей лошадки — модель N14 Pro, предназначенную для тех пользователей, кому нужен достаточно маленький и холодный девайс с достойным железом, адекватным временем жизни от аккумулятора и нормальной IPS-матрицей. Ребята из Ninkear лично предложили мне затестить их новенький девайс и рассказать свои впечатления о нём… ну а я не смог не согласится!
Характеристики тестируемого девайса следующие:
Процессор: Intel Core i7-11390h Tiger Lake, работающий на частоте 3.4ГГц (с автоматическим разгоном до 5ГГц в режиме TurboBoost), выполненный по 10нм техпроцессу в конфигурации 4 ядра/8 потоков. Процессор достаточно «горяч» по меркам лэптопа — теплопакет аж в 35Вт, однако производитель обещает довольно продуманное и тихое охлаждение для большинства режимов работы!
ОЗУ: 16Гб DDR4 в одноканальном режиме.
GPU: Интегрированный GPU Iris XE, работающий на частоте до 1.4ГГц и в качестве видеопамяти использующий некоторый процент основной ОЗУ устройства. Iris, как и UHD Graphics, поддерживает OGL 4.6, Vulkan и DX12. Для большинства современного софта этого более чем достаточно, а вот игры… узнаем чуть позже!
Постоянная память: 1Tb NVME SSD, что само по себе уже неплохо, учитывая цену девайса и его мы тоже позже потестируем!
Дисплей: 14.1" 1080p шустрая IPS-матрица достойного качества с яркостью 280Нит.
Аккумулятор: Li-Ion ёмкостью 4.700мАч. Производитель обещает до 48ч в режиме простоя, 6ч размеренной работы и 8ч проигрывания видео в FHD
Толщина и вес: Всего 1.5Кг и тонкий 17мм корпус — весьма компактненько и портативно для такой машинки!
Камера: «Вебка» с разрешением 720p для любителей поболтать в видеочатах.
Wi-Fi: Современный модуль с поддержкой частот 2.4ГГц и 5ГГц.
ОС: Windows 11.
На первый взгляд всё весьма неплохо…
Распаковываем
Девайс пришёл ко мне в двух симпатичных коробочках, одна из которых была с надписью «Notebook». Вероятно, мне прислали ещё предсерийный образец, а дизайн финальной коробки пока ещё не готов.
В первой коробке лежал сам девайс в пленках, а также коврик для мыши, а во второй, которая поменьше — блок питания с кабелем для европейской вилки, а также фирменная беспроводная мышка весьма причудливой формы. Мелочь, а приятно :)
Что мне лично понравилось в первую очередь — так это конструкция и материалы корпуса девайса. Несмотря на то, что поддон ноутбука выполнен из классического пластика, вся верхняя часть устройства и топкейс выполнены из приятного на ощупь алюминия, что, в целом, даёт даже некоторое ощущение премиальности устройства. Девайс мне напоминает макбук, хотя из оригинальных маков у меня только PowerBook G4.
Открывается девайс относительно легко, в таком состоянии мы можем увидеть довольно большой по размерам тачпад с поддержкой мультитача, весьма удобную для девайса таких размеров клавиатуру с подсветкой клавиш, а также хвалёный мной ранее IPS-дисплей. Единственный момент, который мне немного не понравился — яркие статусные светодиоды, которые могут мозолить глаза в полной темноте. Для кого-то может статьи минусом единая с клавиатурой кнопкой включения — но сейчас это тренд.
В целом, по первому впечатлению всё очень даже неплохо, учитывая относительно невысокую цену данного красавца. Предлагаю включить девайс и познакомиться с ним поближе!
Включаем, смотрим и тестируем
Для многих будет приятным тот факт, что несмотря на относительно невысокую цену девайса, на N14 Pro предустановлена лицензионная Win11, а не, например, Debian (впрочем, для многих моих читателей это наоборот минус :)). Девайс достаточно шустро загружается с SSD, холодный старт занимает секунд 5, что весьма приятно.
В меню UEFI настроек довольно много, что не свойственно для большинства ноутбуков, в т.ч и пункты связанные с отладкой. С чем связано — не знаю, возможно у меня предсерийный образец и на него заливали дебаг-UEFI.
После того, как система стартовала и нужный софт был установлен, можно визуально оценить производительность девайса по скорости выполнения базовых задач: сёрфинг в браузере с парой десяток вкладок, встроенный UWP-плеер и редактирование документов — с этим всем девайс, очевидно, справляется замечательно!
Рекурсия
Но без синтетики глупо судить о производительности девайса, поэтому мы накатываем бенчмарки и смотрим конфигурацию нашего девайса в CPU-Z и GPU-Z. На первый взгляд, всё весьма неплохо:
Запускаем бенчмарк CPU-Z и получаем следующие результаты:
424.5 очка в режиме теста работы в одном потоке, что по «попугаям» равно Ryzen 5 2600, Ryzen 5 3400G и чуть меньше легендарного i7-7700
2327.6 очков в режиме теста работы в несколько потоков, что в целом, немного шустрее i7-7700, равно тому же 3400G и когда-то желаемому многими i7-4790K
Для честности теста, запускаем бенчмарк CPU Queen в AIDA64 и узнаем, что процессор выдаёт 38025 попугаев. Для портативного и не особо дорогого девайса результаты вполне достойные :
В тесте FPU Julia, 11390H выдаёт 23841 попугаев.
Давайте разберем девайс и глянем, что-же у него «под капотом»?
Что под капотом?
В ультрабуке предусмотрен отдельный отсек для быстрой замены и обслуживания ОЗУ и NVMe. К сожалению, как уже было оговорено выше, слот под ОЗУ только один — возможность проапгрейдить оперативку есть, но работать она будет только в одноканальном режиме. NVMe, как и обещано, на 1Тб, одним чипом памяти. Маркировка на плате говорит о том, что потенциально можно попробовать распаять второй чип памяти и получить 2Тб… Может, как-нибудь попробовать? :)
Вообще, это забавно прозвучит, но меня порадовало наличие коннектора АКБ в открытом доступе без необходимости полной разборки ноутбука. Казалось бы, что в этом такого, но иногда меня просят перебрать и обслужить свежие ноуты, а в некоторых моделях АКБ можно отключить только после частичной разборки девайса… что, в общем-то, весьма рискованно. Кроме того, это полезно если вам необходимо на долгое время убрать девайс на полку и вы не хотите, чтобы АКБ ушёл в защиту.
Разбирается девайс очень просто, без необходимости снятия клавиатуры: просто откручиваем поддон, расщёлкиваем клипсы и снимаем его.
Конструктивно девайс весьма неплохо продуман. Охлад состоит из двух кулеров, хаб и процессор с GPU «сидят» на разных тепло-трубках, что обеспечивает достойный уровень охлаждения. Ещё-бы, с достаточно горячим по мобильным меркам процом!
В ноутбуке хоть и классическая, но весьма надежная конструкция петель: с завода девайс хоть и не открывается одной рукой, как макбук, однако петли не вызывают нареканий с точки зрения пользовательского опыта. На 5+ лет активной работы их должно хватать с головой!
Обратите внимание на наличие UART на плате. С учётом того, что в ноутбуке прошита debug-версия UEFI, диагностика аппаратных проблем лэптопа может стать проще:
С пользовательской точки зрения, ноутбук легко обслуживается: весь охлад снимается за пару минут, ОЗУ не распаяна и её без проблем можно заменить, NVMe-диск также легко поддаётся замене. Для рабочей и недорогой машинки — самое то!
Подходит ли девайс для разработчика?
Мой основной стек технологий — это C/C++ (Embedded-разработка и системное программирование), .NET (игры, мобильные приложения) и Java (Android, ну и по малёху J2ME из интереса), поэтому в этом тесте мы будем смотреть, как будет проявлять себя девайс при работе в современных и тяжелых IDE (IDEA-подобная Android Studio, привет!), как шустро девайс сможет справляться с компиляцией больших проектов и работой с тяжелыми системами сборки (Gradle).
Первым у нас будет VS2022 Community Edition. IDE работает достаточно плавно как в маленьких, так и относительно больших проектах. С .NET нет никаких проблем: студия практически моментально собирает и запускает отладчик для любых моих небольших проектов, а также быстро собирает сторонние библиотеки. Время сборки после clean моего самопального 3D-шутера на ~4к строк кода с учетом фреймворка — менее секунды!
Переходим к плюсам. Собирать мы будем 3D движок Urho3D. Накатываем CMake, генерируем проекты VS и переходим к компиляции…
Полное время сборки комплексного проекта с учетом сборки физ. движка, статической библиотеки самого движка и демок — 03:16, что весьма достойно.
Дальше у нас идёт Android Studio, известный своей системой сборки Gradle. Первая сборка всегда довольно долгая, поскольку Android Studio качает необходимую для проекта версию Gradle, однако основным показателем будет являться время Gradle sync и фактическое время сборки проекта после его очистки.
Мой клиент «вкшечки» собирается за 15 секунд, с учётом того, что Gradle уже развёрнут и проводится clean-сборка проекта. Gradle сам по себе неповоротлив до жути, но результат в любом случае неплохой!
Играем
Ну и само собой, самое время погонять девайс в играх! Если честно, я практически не играю в свежие релизы и не вижу особого смысла прогонять бенчмарки условного Cyberpunk 2077 на встройке… Но некоторую классику мы, пожалуй, с вами можем погонять!
Начинаем с GTA V, минимальные настройки графики, но при этом FHD-разрешение. 20-30 нестабильных кадров в портативном режиме. Уже не очень, да?
Black Mesa, релизная Steam-версия, в одной из самых тяжелых сцен с поездкой на «поезде» мы получаем ~30-40FPS на минимальных настройках графики, но в нативном разрешении. Казалось бы, первому Source уже вот-вот 20 лет стукнет, а всё равно лучшая его ветка способна нагрузить даже современные GPU!
Counter-Strike: Source. Не поймите меня неправильно, CS2 девайс тоже вполне тянет и в портативе, однако производительность слишком нестабильная для комфортной игры. Зато CSS — вполне! Кроме того, интеловский драйвер форсирует во всех D3D-приложениях 60FPS и отключить лок в текущей версии софта невозможно :(
Ну и Flatout 2. Здесь всё замечательно, как и в большинстве гоночек тех лет :)
Заключение
Давайте подведем итоги на основе проведенных нами тестов:
Игры: Для свежих релизов девайс не подойдет от слова совсем. Iris XE в текущей конфигурации — достаточно слабая встройка, которая с трудом вытягивает игры 5-6 летней давности в 1080p. Но тем не менее, если вы покупаете лэптоп в первую очередь для работы, но время от времени любите погонять в условный New Vegas, или, например, CSS, то почему бы и нет?
Разработка: Для целей разработчика девайс подходит весьма неплохо. Шустрый террабайтный NVMe SSD вкупе с не самым плохим i7 11390H позволяют с комфортом работать в IDE, а также собирать и дебажить проекты «на лету». Можно накатить osx86 и будет «почти макбук», учитывая моду на дизайн лэптопов от Apple.
Офис и учёба: Подойдёт замечательно. Девайс без проблем можно использовать для подготовки презентаций в поверпоинте, работы с документами, таблицами и т.п.
Сёрфинг, просмотр видосов и онлайн-кинотеатров: С этим тоже никаких проблем нет. Девайс легко вывозит с десяток открытых вкладок, при просмотре видео девайс практически не греется — GPU поддерживает аппаратное декодирование VP9 в 2160p.
Если девайс подходит вашим требованиям — можете смело брать на официальном сайте производителя. Склады есть и в РФ, так что проблем с сроком доставки не будет :)
Друзья! Ninkear прислали мне данный ноутбук в обмен на обзор. Но пожалуйста, смотрите на это не с позиции «автор, ты продался», а с позиции того, что ребята заслали мне удобную машинку, которая поможет сделать будущий контент лучше! Мне лишь оставалось расписать свои искренние впечатления касательно девайса и лично я считаю, что ноут вполне можно рассматривать к покупке.
Моддинг девайсов — тема очень широкая и невероятно интересная. При желании, чего только не сделаешь со своим любимым устройством: можно кастомизировать и преобразить интерфейс девайса, портировать свежую версию системы, прошить ядро с разгоном ЦПУ… Однако помимо программного моддинга, существует и аппаратный: умельцы умудряются наращивать объем ОЗУ и постоянной памяти, менять дисплеи на более качественные и даже добавлять поддержку беспроводной зарядки/квикчарджа! Предлагаю вам взглянуть на относительно редкую, дорогую, но такую желаемую в нулевых модификацию: наращивание ОЗУ на КПК аж в два раза! Сегодня мы с вами: узнаем предысторию моддинга телефонов в нулевых, самостоятельно перепаяем чипы ОЗУ на модули большего объёма, а также разберемся в программной стороне этого вопроса. Интересно? Тогда добро пожаловать под кат!
Пожалуй, КПК и коммуникаторы на Windows Mobile можно назвать одними из самых интересных девайсов из середины нулевых годов. Пока подавляющее число пользователей только-только пересело на кнопочные телефоны с цветными дисплеями и поддержкой WAP-интернета, владельцы КПК носили в кармане полноценный компьютер, который мог выполнять многие задачи своего «большого брата». Сёрфинг полноценного Web 2.0 интернета, редактирование и просмотр документов, прослушивание музыки и воспроизведение видео и конечно-же игры — для портативного девайса в середине нулевых это было очень круто!
i-Mate jasjar
Характеристики КПК были практически идентичными на всех устройствах: большинство девайсов работало на базе ARMv5 процессоров Intel PXA 27x с частотой 400-600МГц, Samsung S3C6410 ~400МГц, а также TI OMAP 850 на частоте ~200МГц, оснащались ~64Мб встроенной Flash-памяти и 64-128Мб оперативной памяти SDRAM. Самым ценным ресурсом была оперативная память: большинство устройств на базе PocketPC 2003 так или иначе не могли использовать встроенную Flash-памяти для хранения пользовательских данных. Девайсы с 128Мб ОЗУ ценились гораздо выше более доступных устройств с 64Мб ОЗУ.
Происходило это из-за того, что Flash-память в те годы была слишком медленной, что негативно сказывалось бы на производительности всей системы. Поэтому производители устройств пошли на хитрый шаг: они решили использовать некоторый объём ОЗУ в качестве диска для пользовательских данных, а дабы пользователь не потерял важные ему файлы при, например, замене аккумулятора, они реализовали схему отдельного запитывания модуля обновления DRAM от резервной батарейки.
Динамическая RAM устроена так, что требует процедуру регулярного обновления (термин называется RAM refresh) данных во всей банке памяти в определенные промежутки времени. Упрощенно эта процедура выглядит так: контроллер памяти в чипсете вычитывает информацию из каждой банки, а затем записывает обратно, благодаря чему информация в банке памяти не теряется. Именно для этого контроллеру ОЗУ необходимы настройки таймингов, а также для процесса, именуемый «тренировкой памяти».
Поэтому в Windows Mobile был предусмотрен отдельный «бегунок», отвечающий за объём памяти, выделенный для программ и для пользовательских данных. Хочешь запустить одновременно TouchFlo, Скайп, Аську, PocketIE и гонять в фоне музыку? Готовься переносить фотографии любимого кота на SD-флэшку и тянуть бегунок в сторону программной памяти! По умолчанию, система выделяла около 32Мб памяти под пользовательские данные и остальные 32Мб под программы. Пользователь мог выделить до ~48Мб ОЗУ для программ, чего действительно хватало для параллельной работы нескольких относительно тяжелых программ в фоне!
Однако КПК на «винде» — отнюдь не современные устройства на Android и iOS и сами программы без крайней необходимости из памяти не выгружают. В iOS и Android практикуются «скриншоты» программ, когда в диспетчере задач мы видим сохраненное состояние приложения, но по тапу приложение снова запускается и быстренько восстанавливается из ранее сохраненного состояния. Поэтому, если в устройстве заканчивалась память для программ, уже открытые приложения могли крашиться, а новые не запускаться из-за слишком малого объёма свободной ОЗУ.
Устройства на WinMobile замечательно поддавались моддингу: некоторые энтузиасты портировали более свежие версии системы, другие выпускали собственные сборки системы, подчищенные от ненужных, по их мнению, программ, дабы освободить ещё немного ОЗУ под собственные приложения. Программный моддинг был очень развит: вспомнить только «кухни» — специальные наборы программ для модификации прошивок устройств и целые ветки на форуме 4pda, где обсуждалось добавление нового функционала в девайс. Чего-уж говорить, я сам год назад добавлял поддержку Direct3D Mobile в WM2003 и подкидывал софтварный рендерер от Intel в устройство на OMAP850!
Год назад я за пару дней запилил «тридэ» леталку, использующую D3DM — софтварный рендерер в Windows Mobile.
Однако другое дело — это аппаратный моддинг, связанный с физическим вмешательством в плату устройства. Самым частым модом была замена вечно ломающегося концевого выключателя (маленький рычажок, который прижимает задняя крышка устройства. Без него девайс чаще всего не включался) на обычную перемычку, дабы девайс не подвёл в самые ответственные моменты. Другой мод — перепаковка аккумуляторов для увеличения его ёмкости. Были ещё и другие, специфические модификации — насколько я знаю, на некоторых коммуникаторах Rover радиомодуль частенько «отваливался», а девайс уходил в белый экран. Радиомодуль либо выпаивали, либо грели (а то и перекатывали), дабы он ещё поработал какое-то время. Однако самым редким, дорогим и желанным многими модом было увеличение объёма ОЗУ! Данная процедура довольно простая, однако проводилась чаще всего в мастерских: старые чипы памяти выпаивались, а на их замену припаивались новые, большего объёма. На словах все просто, однако на деле далеко не каждый мог провести такую процедуру дома: необходимо было купить чипы памяти (которые стоили около 500 рублей за один), а сами они были в корпусе BGA и для пайки необходим был паяльный фен (на строительный тоже можно было посадить — но рискованнее) и адекватный флюс для BGA (хотя я слышал истории, как мастера в нулевых сажали чипы «на пузо» чуть ли не на таблетке аспирина).
Как видите, цена на работу в СЦ была не менее 3.000 рублей, время работы — полчаса-час. Теперь вспомните, что в некоторых регионах зарплата была около 6-7 тысяч рублей в месяц… вот так вот :)
Недавно я и сам заинтересовался таким видом моддинга и решил повторить опыт умельцев из нулевых: мне удалось найти НОВЫЕ (не реклама, это единственный магазин где можно купить эти чипы в РФ) чипы памяти в блистере по 100 рублей за штучку. Давайте же проапгрейдим легендарный коммуникатор своих лет — QTek S100 aka O2 Xda Mini II aka MDA Compact!
Подобному апгрейду поддаются далеко не все девайсы. К сожалению, фактически проапгрейдить можно устройства только на базе чипсетов Intel PXA, например Asus P525/550, ранние HTC и многие HP iPaq. Устройства на базе Samsung S3C6410 имеют 64Мб ОЗУ прямо на одной подложке с чипом без площадок под дополнительную память на плате, а про устройства на OMAP 850 известно мало: скорее всего, чип не поддерживает возможность использования сразу четырех банок памяти одновременно.
Этого красавца проапгрейдить не выйдет :(
Изначально с завода, на большинстве устройств с чипсетом PXA используется два чипа мобильной SDRAM памяти типа HYB25L256160AC, производства Infineon, в корпусе BGA, по 32Мб каждый. Однако существует 64Мб версия того же чипа с идентичной распиновкой, где в одном чипе расположилось сразу две банки памяти, по 32Мб каждая. По итогу нам остается только сдуть старые чипы с помощью фена, почистить посадочные площадки от остатков старых шаров и установить новые чипы памяти с помощью всё того же фена. Давайте приступим!
Я купил свой QTek S100 два года назад в состоянии «как из помойки», всего за 100 рублей. Без шуток, возможно продавец действительно посещал свалки и потом продавал по дешевке различные интересные девайсы! Лично для меня в этом нет ничего брезгливого: корпус помыть с мылом, плату почистить спиртом и вот — крутейший девайс снова в рабочем состоянии и вполне чистенький :)
Аккумулятора у меня не было вообще и найти донора под перепаковку я даже не надеялся, поэтому запитывал девайс от BL-4C.
Разбираем девайс и видим плату с защитным экраном над процессором и ОЗУ. Сам экран съёмный, выпаивать его не нужно, но дабы аккуратно выпаять чипы памяти и не сдуть обвязку, придётся удалить лезвием «перекладину» на экране.
Выдавливаем под пузо чипов памяти немного флюса для BGA, берём прецизионный пинцет, фен, выставляем небольшой поток воздуха, температуру в 350 попугаев и начинаем выпаивать память по отдельности. Оба чипа сидят на бессвинце, поэтому для того, чтобы чип начал покачиваться, необходимо погреть его некоторое время. Как только чип начал «плавать» при покачиваниях пинцетом, его можно осторожно снимать пинцетом. Если снесли мелочуху, то её можно аккуратно выравнять пинцетом и поставить тем же феном обратно: поверхностное натяжении притянет элемент обратно и он встанет на место ровно, как и должно быть.
Я сначала не думал пилить контент об апгрейде памяти, поэтому фоточка совсем всратая :( Извините
Зачищаем площадку от старых шаров с помощью паяльника на 350гр и оплетки. Впрочем, шары достаточно большие — можно просто покатать шарик припоя и собрать излишки на паяльник, идеально ровно зачищать их не нужно.
Наносим флюс на посадочные площадки, примерно центрируем чип на плате и начинаем греть. Если вы не перелили флюса, благодаря поверхностному натяжению чип сам встанет на место!
Почти по заводу!
Но девайс не увидит всей ОЗУ, если не поставить резистор номиналом ~0.33Ом на линию CS1 - именно она отвечает за выбор второй банки в одном чипе памяти. Можно попробовать и просто перемычку поставить, но я не гарантирую результат.
Но это не весь моддинг на сегодня! Чуть позже я кинул нормальную, красивую перемычку вместо концевого выключателя, а также перепаковал аккумулятор, установив банку от BL-4C. Она, конечно, меньшей емкости, но девайс всё равно с ней держит довольно неплохо. Обратите внимание, что BMS (плату защиты) BL-4C необходимо выпаять: коммуникатор при поиске сети потребляет довольно много, из-за чего BMS BL-4C уходит в защиту.
Включаем девайс и… он работает!
Лучше перепрошить девайс официальной прошивкой: я даунгрейдился еще до замены памяти (до этого стояла прошивка WM6.5 от Cotulla), однако после апгрейда «винда» не всегда загружалась нормально, при том что сама ОЗУ инициализировалась правильно, без каких либо проблем и ребутов. После прошивки всё снова стало нормально. Если хотите накатить кастом — то ставить нужно версию с поддержкой 128Мб ОЗУ.
Обратите внимание, что флэшер вполне честно заявляет о времени обновления в 20 реальных минут времени. В этом вина как USB 1.1, так и медленной флэши.
Сейчас мы рассмотрели только физическую часть замены памяти. Но некоторые читатели наверняка спросят, каким же образом коммуникатор определяет всю установленную память, если конфигурация DDR статически слинкована с первичным загрузчиком?
На ПК у нас есть SPD— Serial Presence Detection, специальная небольшая флэш-память, в которой хранится конфигурация чипов и общий объём памяти на планке. В embedded-окружении чаще всего конфигурация контроллера памяти хранится в первичном загрузчике (после BootROM) — известном также как SPL.
Загрузчик HTC на устройствах PXA поддерживает несколько конфигураций ОЗУ — как минимум 64Мб и 128Мб. И судя по всему, на манер BIOS на ранних x86 машинах, загрузчик ещё на этапе тренировки ОЗУ проверяет всё доступное адресное пространство: если доступны «верхние» 64Мб ОЗУ, тогда загрузчик передаёт в Windows CE информацию о том, что установлено 128Мб памяти.
На коммуникаторах Asus, загрузчик патчили для поддержки 128Мб.
Очевидно что без установки второго чипселекта (линии CS1), контроллер DRAM не сможет обратиться ко второй банке памяти в одном чипе, поэтому его установка обязательна. Иначе загрузчик не видит верхние 64Мб ОЗУ и считает, что в устройстве установлено лишь 32Мб.
Давайте глянем, как же девайс работает теперь. Пожалуй, сразу стоит упомянуть то, что у девайса изначально были перспективы к увеличению производительности: помимо возможности увеличения ОЗУ, чипсет легко разгоняется до 624МГц с стоковых 412. Очень даже бодрый результат.
Сначала я решил поиграть в классику. AoE замечательно шла и на устройствах с ~32Мб ОЗУ (т.е ранних КПК), очевидно что и на гораздо более шустром девайсе она будет идти очень хорошо. Хороший способ ознакомиться с классикой RTS, кстати!
Переходим сразу к тяжелой артиллерии. Самыми тяжелыми играми для ранних коммуникаторов считались PocketFallout и Heroes Mobile: они кушали довольно большой объём ОЗУ и что-то запустить параллельно с ними было проблематичным. Не менее тяжелой была Quake 1: игра аллокейтит для себя кучу (динамическая память) в 16Мб. Это был уже серьезный удар по свободной ОЗУ на устройствах с 64Мб памяти, QIP и PocketIE уже придется закрыть:
Но будем честны: ради игр можно было закрыть почти все приложения в диспетчере задач. А как насчет повседневных задач? Давайте откроем кучу приложений и узнаем, какое у нас будет потребление ОЗУ и общая производительность системы:
Не хило, да? Коммуникаторы и сейчас подойдут в качестве звонилок с функционалом смартфона, однако приложения под себя придётся допиливать самому. Благо API очень знакомое: в WinMobile и WinCE у нас самый обычный WinAPI, очень схожий с десктопным, а также есть немного урезанный .NET!
Вот таким был аппаратный моддинг девайсов в нулевых. Столько всего можно было сделать, имея лишь базовое оборудование! А ведь если включить смекалку, то можно заюзать КПК и в качестве одноплатников: на подавляющем числе девайсов UART без проблем можно получить с разъема для док-станции, а сама шина без проблем доступна из юзерспейса. Постараюсь развить эту тему в одной из будущих статей.
Информации по апгрейду памяти на КПК очень мало (ведь когда-то это был хлеб для СЦ) и сейчас её можно найти исключительно в архивах. Однако чем больше я посещаю паблики посвященные ретро девайсам, профильные каналы в Телеге и форумы по ремонту девайсов, я вижу всё больше упоминаний таких любимых нами наладонников! Поэтому я постарался систематизировать и собрать в кучу всю необходимую информацию для того, чтобы любой читатель мог и сам провести такую операцию в домашних условиях.
Сейчас мы привыкли с вами, что в смартфонах объём ОЗУ зачастую больше, чем в некоторых десктопных машинах. 6, 8, 12Гб — куда дальше!? А ведь когда-то и 128Мб уже было за счастье :)
А какие модификации КПК были у вас и как использовали свой девайс вы? Может вы сами апгрейдили КПК? Пишите в комментариях!
P. S.: Друзья! Время от времени я пишу пост о поиске различных китайских девайсов (подделок, реплик, закосов на айфоны, самсунги, сони, HTC и т. п.) для будущих статей. Однако очень часто читатели пишут «где ж ты был месяц назад, мешок таких выбросил!», поэтому я решил в заключение каждой статьи вставлять объявление о поиске девайсов для контента. Есть желание что-то выкинуть или отправить в чермет? Даже нерабочую «невключайку» или полурабочую? А может, у этих девайсов есть шанс на более интересное существование! Смотрите в соответствующем посте, что я делаю с китайскими подделками на айфоны, самсунги, макбуки и айпады!
Понравился материал? У меня есть канал в Телеге, куда я публикую бэкстейдж со статей, всякие мысли и советы касательно ремонта и программирования под различные девайсы, а также вовремя публикую ссылки на свои новые статьи. 1-2 поста в день, никакого мусора!
Материал подготовлен при поддержке TimeWeb Cloud. Подписывайтесь на меня и @Timeweb.Cloud, дабы не пропускать новые статьи каждую неделю!
Китайские производители не перестают удивлять: многие видят явные перспективы рынка одноплатных компьютеров и стараются представить целую линейку девайсов на самых разных чипсетах, а разработчики стараются использовать уже привычное и поддерживаемое долгие годы железо. К ним относятся решения на чипсетах AllWinner, RockChip, Tegra. Другие же стараются взять малоизвестный, но дешевый чип для иного круга применений, развести на нем компактную плату и продавать по цене пачки сухарей, подобные решения появляются регулярно. Один из таких одноплатников я недавно купил на AliExpress — некий DongShan Pi Pico W, на базе экзотического чипсета SigmaStar SSD210, всего за 600 рублей. И тут действительно есть на что посмотреть: два ядра Cortex-A7, контроллер TTL матриц, 2D GPU, Wi-Fi, 64Мб ОЗУ и Embedded Linux на борту. Более того, девайс поставляется в виде System on Module с переходной Evaluation-платой, что позволяет использовать это устройство в составе других гаджетов! Что это за красавец и на что он способен? Читайте в статье!!
Думаю, большинство моих читателей когда-либо слышали об одноплатных компьютерах. Это компактные и достаточно мощные устройства, которые можно использовать как в качестве компактных серверов или даже десктопных машин, так и собрать своё устройство на базе готового одноплатного компьютера. Одноплатники используется во многих сферах: вендинговые автоматы, умные экраны, самопальные игровые консоли и смартфоны, DIY-ноутбуки!
Однако чаще всего можно увидеть обзоры и проекты на базе довольно известных устройств: Raspberry Pi, Orange Pi, Olimex. Эти платы, скажем так, достаточно дорогие: и если Orange Pi One/Zero ещё можно ухватить за 1.000 рублей на вторичке (один из таких я купил еще летом. Узнав о моем блоге, продавец стал моим читателем и вместо одного OPi прислал мне целых два — один в подарок!), а за RPi Zero придется выложить как минимум 2.000 рублей. Однако есть ещё один сегмент одноплатных компьютеров: ультра-дешевые, разработанные на базе чипов для конкретного применения. Один из самых известных представителей — MangoPi/CherryPi R3, который работает на базе AllWinner F1C200s — чипа для… электронных книг!
Информации по дешевым, почти неизвестным одноплатникам довольно мало. У них не очень хорошая поддержка (кроме AllWinner, там почти все чипсеты есть в mainline-ветке Linux), в них могут обнаружится аппаратные баги, да и многие люди вообще не замарачиваются с ними, предпочитая переплатить, но купить что-то более стабильное. Но не я! Я просто обожаю различные ультрадешевые девайсики, поэтому недавно по наводке моего активного читателя NutsUnderline, я заказал интереснейший девайс — DongShan Pi Pico-W. Устройство обошлось мне всего в 600 рублей, но в первую очередь, меня привлек форм-фактор устройства и его чипсет. Некий SigmaStar SSD210!
Я заказал сразу два устройства: первую партию очень быстро разобрали, поэтому я взял «с запасом». Сейчас конкретно этот одноплатник пока-что не доступен в магазине продавца, однако у него же продаются другие устройства на базе SSD210. Можете найти их по ключевому слову: «SSD210» (прямые линки публиковать не буду, дабы не сочли за рекламу). Через месяц оба красавца пришли ко мне и я принялся их изучать.
Какое же было моё удивление, когда я обнаружил, что это по сути System on Module, который вручную надо припаять к Evaluation-плате! Вкратце это значит, что на базе таких SoM вы можете развести плату, протравить её, а затем припаять одноплатник поверх нее и сделать своё полноценное устройство, «без соплей»! Производителю плюсик за такую гибкость — я не очень люблю одноплатники с штырьковыми гребенками. Хотя, конечно, это очень сильно помогает при разработке макета устройства.
Но чем он так меня привлек, помимо SoM направленности? Своим крутым чипсетом! Давайте ознакомимся с его характеристиками поближе:
Процессор: SigmaStar SSD210. 2 ядра Cortex-A7, работающие на частоте до 1ГГц. 16Кб кэш инструкций и 16Кб кэш данных, плюс 128Кб L2-кэша. В процессоре есть FPU и поддержка SIMD-инструкций Neon (альтернатива SSE в x86). Нехило, правда?
Поддержка дисплеев: У чипсета есть выделенный модуль для работы с внешними матрицами. Поддерживаются TTL дисплеи (до 1024x768), SPI-матрицы с клоком до 54МГц (480x320), а также прямой RGB аналоговый RGB сигнал (этот интерфейс можно использовать для подключения к ТВ с тюльпанами или аналоговым матрицам). Про типы дисплеев, вы можете прочитать в моей статье.
2D GPU: Поддержка отрисовки линий, прямоугольников, градиентной заливки, BitBLT, клиппинг, дизеринг, автоматическая конвертация формата пикселя (с RGB888 в RGB565). Это серьёзно снимает нагрузку с ЦПУ при рисовании графики, однако поддерживается ли он в Linux — вопрос другой.
ОЗУ: 64Мб DDR2 памяти «бутербродом» прямо с чипсетом, плюс поддержка до 512Мб DDR2 внешней памяти, до 1333Мб/с.
Звук: Один моно-выход DAC, два выходных канала I2S, вход микрофона. Входные каналы поддерживают частоту дискретизации до 96КГц. Можно организовать вывод звука лишь подключив внешний усилитель. Внешний ЦАП не обязателен, если вам не нужен стерео-звук.
Память: Контроллер NOR/NAND SPI-памяти, до двух параллельно подключенных чипов, плюс поддержка SDIO. BootROM поддерживают загрузку с MicroSD карт.
Сеть: Ethernet, на DongShan Pi есть Wi-Fi.
USB: Как хост, так и ведомое устройство
Периферия: 4 канала ШИМ, GPIO, 4 UART, 2 канала SPI, 2 канала I2C
Камера: До двух камер по интерфейсу MIPI CSI
Безопасность: Есть аппаратное шифрование.
Питание: 0.9В ядро, 1.8В ОЗУ, 3.3В I/O
Очень даже бодро, согласитесь? Вообще, производитель подразумевает SSD210 как чипсет для HMI-дисплеев — т. е. умные дисплеи, которые могут, например, служить стендами в музеях, или служить для заказа билетов в кино. Есть внешние HMI-дисплеи, которыми можно управлять используя другие МК: просто посылая команды и реагируя на нажатия кнопок. Тут мы и видим, как китайский производитель решил применить этот чипсет для другой сферы: одноплатный компьютер для DIY!
На SSD210 есть порт Linux, предлагается использовать Embedded Linux в качестве основной системы. Никаких дистрибутивов по типу Ubuntu для устройства нет — предполагается, что вы сами реализуете весь необходимый для ваших программ функционал (отрисовку графики, обработку ввода, звук и т. п.). Есть Build root и исходный код ядра, а также U-Boot.
Помимо этого, вендор предлагает целое SDK для разработки уже готовых устройств на этом чипсете. Но есть один нюанс: документации практически нет :( Такие пакеты предлагаются крупным коммерческим производителям устройств, поэтому и основная поддержка есть только для них. Есть некоторые сэмплы, как, например, использовать графические дисплеи (показан пример с TTL-матрицей 1024x600), но совершенно не ясно как использовать SPI-матрицы, поскольку они требуют отдельной инициализации.
Но сначала наш одноплатник нужно собрать и запустить. И здесь есть множество тонких моментов, которые необходимо знать перед покупкой такого девайса. Переходим к сборке!
Для более удобного процесса разработки нашего устройства, лучше всего заказывать сразу две платы: одну припаять к переходной плате с штырями, а другую использовать на нашем устройстве. Как я уже говорил ранее, одноплатник предлагается в виде System on Module, которые можно при желании распаять на переходной плате:
Честно сказать, я очень люблю такой тип монтажа и топлю за то, чтобы другие одноплатники не форсировали использование штырьков, а позволяли припаять себя «бутербродом» к другой плате. Обычно SoM дороже чем простые одноплатники, один из примеров — Olimex A20 SoM. Припаиваем основную плату к eval-плате. Обратите внимание, что припой должен находится «скосом» с внешней стороны пинов!
После этого, можно распаять гребенку. После окончания процесса сборки, вызваниваем все пятачки на плате и гребенку, дабы исключить непропай в каком-то месте.
Теперь подключаем питание. На плате уже разведены Step-down преобразователи с 5В на 3.3В (основная логика), 1.8В (DDR2), и 0.9В/1.0В (ядро), нам достаточно подключить лишь 5В, либо запитать плату от 3.7В аккумулятора. Устройство стабильно работает и от 0.5А порта ПК (если не юзать Wi-Fi).
Для работы с одноплатником, обязательно нужен COM-преобразователь. Открываем Putty, задаем COM-порт, выставляем бодрейт 115200 и отключаем контроль четности. После подачи питания на устройство, в консоли побегут логи, U-Boot начнет загружать систему… однако, есть один важный нюанс…
Все платы прошиваются на заводе с помощью фирменного флэшера SSD210. Но фирменный флэшер, по каким-то причинам, на некоторых платах не может сохранить U-Boot Environment (переменные окружения, которые в том числе определяют таблицу разделов и коммандлайн ядра).
Поэтому если ваша плата повисла на CRC Error, нужно ввести следующие команды:
setenv mtdids nand0=nand0
setenv mtdparts ' mtdparts=nand0:0x140000(CIS),0x1a0000(BOOT0),0x1a0000(BOOT1),0x40000(ENV),0x40000(ENV1),0x20000(KEY_CUST),0x500000(KERNEL),0x500000(RECOVERY),0x600000(rootfs),0xa0000(MISC),-(UBI)
setenv bootargs ubi.mtd=UBI,0x800 root=/dev/mtdblock8 rootfstype=squashfs ro init=/linuxrc LX_MEM=0x3FE0000 mma_heap=mma_heap_name0,miu=0,sz=0x1E00000 cma=2M highres=off mmap_reserved=fb,miu=0,sz=0x300000,max_start_off=0x3C00000,max_end_off=0x3F00000 ${mtdparts}
setenv bootcmd ' nand read.e 0x22000000 KERNEL ${kernel_file_size}; dcache on ; bootlogo 0 0 0 0; bootm 0x22000000;nand read.e 0x22000000 RECOVERY ${recovery_file_size}; dcache on ; bootm 0x22000000
setenv autoestart 0
setenv sstar_bbm off
setenv ipl_version "##p3##gdf99011IPL_##########
setenv ipl_version "DUALENV=1 SILENT_CONSOLE=1 CFG_SDMMC_DISABLE=n ALK=1 SPINAND=1 CHIP=pioneer3""
saveenv
После этого отправляем плату в ресет и система загружается как ни в чем не бывало!
Поскольку на плате не разведен разъем USB, для прошивки нужно распустить нерабочий кабель для зарядки смартфона, либо купить внешний USB-разъем на плате. VBUS кидаем на вход питания, белый провод на DM-, зелёный на DM+. Не забывайте провести общую землю между UART-преобразователем и основным питанием платы, дабы не потерять логи.
Замыкаем два пина в центре платы пинцетом и жмем RESET. Плата определится как MSDC-флэшка (не удивляйтесь). Прошивальщик глючный и бывает не с первого раза может прошить устройство. Если девайс после прошивки не включается — введите команды в консоль U-Boot выше.
Теперь переходим к самой системе.
Девайс работает на базе ядра Linux 4.9. Тем не менее, производителем заявлена поддержка Mainline-ядра, что даёт надежду на поддержку устройства в будущем.
Таблица разделов устройства организована в виде ubifs. Вообще, предполагается, что для тестов можно будет запускать ваш софт без перезагрузки, однако когда речь заходит о серьезных модификациях, ребут и прошивка устройства глючным софтом — дело неизбежное.
«Из коробки» на устройстве доступен лишь i2cdev, благодаря которому можно свободно общаться с i2c-устройствами из юзерспейса. Хотите получить доступ к SPI? Готовьтесь качать билдрут, вручную включать spidev в конфиге и редактировать DeviceTree, дабы spidev мог получить доступ к физическим spi-устройствам ядра.
Кроме того, конечно же, есть доступ к GPIO из sysfs.
На самой плате, Wi-Fi реализован в виде внешнего USB-хаба + Wi-Fi адаптера. Чипсет также поддерживает Ethernet.
Для разработки устройств, производитель предлагает отдельное SDK для общения с периферией устройства из юзерспейса. С помощью этого SDK, можно получить доступ к камере, аппаратному декодеру, звуку и настроить матрицу. Судя по всему, общение происходит с помощью ioctl к необходимым устройствам. Это сделано для того, чтобы разработчики не копались в низкоуровневых драйверах, ведь например, ALSA, на устройстве нет совсем.
Если включить нужные нам модули в юзерспейс (spidev, i2cdev, gpio), то можно будет проектировать устройства более простым путем. Например, подключить дисплейчик и прямо из юзерспейса выводить на него графическую информацию. Это открывает перспективы для самых разных применений: опрос датчиков и хранение информации в внутренней памяти, умные сигнализации, самодельные часы, DIY игровые консоли, самодельные телефоны и т. п. Применений просто куча!
Вот мы и посмотрели с вами на дешевые одноплатники, где используются чипсеты, которые разработаны для использования в совершенно других сферах. Девайсы весьма своеобразные и для полноценной работы с ними нужно обладать навыками прожженного линуксоида и иметь навыки системного программирования. Но, чего уж точно нельзя отрицать, так это перспектив подобных девайсов для своих проектов. Да, под них нет готовых гайдов, как для Raspberry Pi или Orange Pi, информации по ним минимум… но если захочется — то всегда можно «сварганить» самопальное устройство за минимальный прайс!
Вероятнее всего, я применю один из этих одноплатников для своего проекта немного позже. И конечно же, я напишу об этом отдельный материал — ведь про экзотические чипсеты на Пикабу пишут не так часто!
Чуть позже выйдет материал про Repka Pi. Их одноплатник получился не менее интересным и как раз таки метит в нишу одноплатников с хорошей поддержкой, где есть уже готовые гайды, информация и даже сами разработчики могут помочь с решением некоторых проблем. Без косяков не обошлось: есть пару аппаратных проблем, о которых я расскажу открыто, но в целом девайс выглядит интересным!
Материал подготовлен при поддержке TimeWeb Cloud. Подписывайтесь на меня и @Timeweb.Cloud , дабы не пропускать свежие статьи каждую неделю!
Взять с собой побольше вкусняшек, запасное колесо и знак аварийной остановки. А что сделать еще — посмотрите в нашем чек-листе. Бонусом — маршруты для отдыха, которые можно проехать даже в плохую погоду.
Друзья! Многие ли из вас застали такую легендарную видеокарту, как S3 ViRGE? Когда-то этот GPU стоял чуть ли не в каждом втором офисном компьютере: благодаря дешевизне и заявленной поддержке 3D-ускорения, эту видеокарту просто сметали с полок магазинов. Далеко не все могли себе позволить ATI Rage, Riva TNT и уж тем более 3dfx Voodoo и очень разочаровывались в свежекупленной видеокарте, когда пытались поиграть в новомодные игры тех лет. На момент написания статьи, в сети слишком мало материала о том, как работали видеокарты 90-х «под капотом», однако мне удалось найти даташит на видеочип, SDK для программирования 3D-графики специально под него и некоторую документацию. Я решил исправить это недоразумение и начать развивать отдельную рубрику о работе старых видеочипов: начиная от S3 ViRGE и заканчивая GPU PS2 и PSP. Сегодня мы с вами: вспомним о S3 ViRGE, узнаем о том, как работали видеокарты в 90-х годах, затронем 2D и 3D режим и почему они тесно связаны между собой, посмотрим на проприетарное графическое API S3 ViRGE и раскроем причину, почему же этот GPU был таким медленным!
В начале 90-х годов 3D-графика на обычных домашних компьютерах была редкостью. Профессиональные GPU применялись только на дорогущих графических станциях, которые использовались в кинематографе или различных симуляциях, а также на дорогих японских игровых автоматах. У простого обывателя не было доступа к аппаратным средствам рендеринга 3D-графики.
SGI Indigo
Однако это не значит, что 3D-графики не было вообще. Прогресс развития домашних процессоров шёл семимильными шагами и гиганты рынка —Intel,AMDи в некоторой степени Cyrix, выпускали всё новые и новые процессоры с повышенными тактовыми частотами, а ближе к середине 90-х — и с SIMD (MMX). Поскольку многие техники для отрисовки трехмерного изображения были разработаны ещё в 60-х — 70-х годах, игроделы к началу-середине 90-х во всю использовали некоторые наработанные техники из кинематографа для растеризации 3D-графики прямо на процессоре — так называемыйсофтварный рендеринг.
Одной из самых известных техник 90-х являлась 2.5D графика с использованием рейкастинга — когда картинка на экране выглядит как трёхмерная, однако по факту весь мир представлен в виде 2D-координат, а эффект «пола и потолка» был как бы фейковым. Принцип его работы довольно прост: от глаз игрока для каждого горизонтального пикселя (т. е. при разрешении 240х320, у нас будет 240 проходов) пускаются «лучи» и ищется пересечение с ближайшей стеной относительно угла обзор из глаз игрока. Из этого пересечения берется дистанция до этой стены (на основе дистанции и угла считается «высота» данной строчки стены) и считается какую строчку текстуры необходимо вывести в этой точке. Одними из первых игр с применением этой технологии стал Hovertank и Wolfenstein 3D, а технология применялась практически до конца 90-х. Одной из самых лучших реализаций рейкастинга — движок Duke Nukem 3D, Build Engine, написанный Кеном Сильверманом.
Однако не одним 2.5D мы были едины. Шли годы, в СНГ многие люди продолжали наслаждаться 8-битными и 16-битными играми на клонахNESи SMD. У некоторых уже появлялась PS1, которая позволяла играть в игры с довольно хорошей 3D-графикой, однако на ПК 3D-игры были доступны не всем. Но в 1996 году выходитQuake— новейший шутер от первого лица от id Software с настоящей, трушной 3D-графикой и переворачивает всю индустриюFPSс ног на голову. Посудите сами: Джон Кармак умудрился реализовать достаточно быстрый софтварный рендерер, который мог вполне сносно работать на Pentium 75Мгц в разрешении 320x240. А ведь помимо отрисовки кадра, игре нужно было просчитывать логику монстров (довольно примитивную, к слову), обрабатывать столкновения, просчитывать видимую геометрию с помощью BSP-дерева и обрабатывать клиент-серверную логику самой игры. Это была самая настоящая революция в мире 3D игр на ПК.
В 1997 году, id Software выпустили glQuake — порт Quake с софтрендера на OpenGL, плюс своеобразную прослойку для совместимости с API 3dfx Glide (на видеокартах Voodoo) и подмножества OpenGL, используемым в игре. Порт на OpenGL позволял разгрузить ЦПУ, перенеся всю отрисовку графики с процессора на 3D-ускоритель. Сам по себе, OGL как графическое API, представлял из себя лишь набор спецификаций, который мог быть реализован как в программном виде, так и в аппаратном производителем видеокарты (на примере Windows — OpenGL32.dll это программная реализация, которая при необходимости обращается к atioglxx.dll/nvoglvxx.dll — аппаратной реализации OpenGL от вендора видеочипа). Однако, OpenGL корнями уходил именно в отрисовку промышленной графики, а DirectX всё ещё находился в зачаточной форме, из-за чего многие производители разрабатывали собственное графическое API: из известных мне, могу подчеркнуть ATI CIF (C Interface), 3dfx Glide и проприетарное SDK S3 ViRGE. Некоторые вендоры поддерживали целые игровые движки — например, BRender и RenderWare.
Отдельные 3D-акселлераторы потихоньку начали завоевывать сердца геймеров и создавать новый сегмент рынка. Серьезные видеокарты от известных производителей, такие как 3dfx Voodoo, ATI Rage и Riva TNT стоили достаточно дорого и многим были не по карману. Зато существовало множество видеокарт с 3D-ускорителями от других производителей, про некоторые из них вы могли даже не слышать: отдельные дискретные видеокарты Intel (i740), видеокарты от производителя чипсетов SiS и конечно же, видеокарты от S3 с сериями ViRGE и Savage. Видеочипы от Intel и SiS делали упор на D3D 7.
Intel i740
S3 ViRGE была весьма неплохой видеокартой с точки зрения 2D-ускорения. Сейчас 2D принято считать частным случаем 3D (по факту, 2D-спрайты — это 3D-квады, состоящие из двух треугольников), однако в то время для работы с памятью видеокарты и аппаратного ускорения некоторых операций, таких как блиттинг (BitBlt) существовало отдельное графическое API — DirectDraw. С этим у ViRGE было всё хорошо — он поддерживал довольно высокое разрешение экрана (при желании, объём видеопамяти можно было нарастить и установить разрешение ещё выше) и умел ускорять часть операций как DDraw, так и GDI.
Однако, ViRGE разочаровывал многих геймеров 90х своей производительностью в 3D-графике. На коробке с бюджетной видеокартой красовались красивые надписи о 3D-графике следующего поколения, а на фотографии можно было увидеть некую игру про мехов с невиданной графикой!
По факту, ViRGE подходил для 3D-игр не особо хорошо. Конечно в те годы никто особо не плевался от FPS и при желании, игру могли пройти и в 15, и в 20 FPS. Однако производительность софтварного рендерера иногда была даже выше, чем у растеризатора ViRGE, а игры должны были быть специально адаптированы под неё (т. е. портированы для использования S3DTK). Тайтлов с адаптацией по этот GPU было немало: как минимум, Tomb Raider и MechWarrior 2 (который шел в комплекте с игрой). Польские ребята из известной многим Techland даже написали прослойку S3D -> OpenGL, позволявшей запускать Quake на ViRGE. Производительность была не ахти…
Видеокарт от S3 нашлись и у меня, причём сразу несколько — ViRGE в PCI-исполнении и Trio в AGP-исполнении! Иногда я их использую для проверки старых материнских плат, которых у меня не так уж и много — рабочих на PGA370 и ниже у меня совсем нет. Однако остаётся вопрос, как эти видеокарты работали под капотом? Давайте узнаем!
Исторически сложилось так, что 3D и 2D акселераторы могли быть отдельными и формально не зависящими друг от друга устройствами. Архитектура IBM PC в зависимости от «поколения», предполагала сразу несколько типов видеоадаптеров, которые были стандартизированы под определенный тип мониторов. Один из таких адаптеров, VGA, стал стандартом на долгие годы, в то время как два других использовались в совсем ранних машинах. Их ключевое отличие было в организации видеопамяти и цветности — CGA/EGA предполагал разбитие пространства экрана на т. н. битплейны (один байт содержал информацию о нескольких пикселях и если не ошибаюсь, для сохранения адресного пространства сегменты экрана необходимо было переключать аля банки памяти) и былпалитровым, в то время как VGA предполагал как палитровый режим, так и полноценный RGB и мог отразить весь фреймбуфер в линейную область адресного пространства. Кроме того, долгое время VGA использовался для обозначения разрешения дисплея: QVGA — половина VGA (320x240), VGA (640x480), широкоформатный WVGA (800x480) и т. п.
EGA-монитор
Другой особенностью была полная (насколько мне известно) обратная совместимостью друг с другом. Например, GeForce 7xx, как один из последних GPU, который поддерживал Legacy BIOS, теоретически вполне мог работать и с EGA режимами, и с CGA через соответствующие видеорежимы int 10h!
3D-режимы же никак не были стандартизированы и каждый производитель реализовывал работу с ними по разному — как уже говорилось ранее, кто-то реализовывал поддержку совсем молодого D3D и OpenGL (насколько мне известно, лучше всего с OpenGL было у NVidia. Остальные вендоры поддерживали OGL, но были свои болячки — у ATI они тянулись чуть ли не до середины-конца нулевых), а кто-то делал собственное графическое API и работал с видеочипом почти напрямую. Первые 3D GPU использовали шину PCI, которую почти сразу заменила более скоростная, но интерфейсно и софтварно почти идентичная шина AGP, а затем уже появился PCI-E, который оставался тем же PCI в софтовом плане, но был дифференциальным и последовательным, а не параллельным как интерфейсы-предшественники.
Дабы понять, как работают первые видеокарты, необходимо узнать о том, как происходит процесс отрисовки 3D-графики в общем случае. В мире программирования графики это называетсяконвейероми состоит он как минимум из нескольких этапов:
Установка состояний: Программа задаёт источники света на сцене, параметры Z-буфера и Stencil-буфера, какую текстуру(ы) следует наложить на рисуемую геометрию и с какой фильтрацией, какой тип аппаратного сглаживания использовать и т. п.
Ранее, каждый стейт необходимо было устанавливать отдельно, при необходимости — для каждого DrawCall'а. После подготовки состояния, программа вызывает соответствующую функцию отрисовки.
Обработка геометрии: Геометрия не поступает в растеризатор «как есть», в мировых координатах. Растеризатор оперирует вершинами в нормализованныхClip Spaceкоординатах — обычно, это [-1, -1… 1, 1], где 0.5 — центр экрана по каждой оси. Именно поэтому сначала необходимо провести этап трансформации геометрии для перевода из некой глобальной системы координат (которая может выражаться в метрах или, например, в пикселях) в Clip Space. Для этого чаще всего координаты (корректнее — трансформации) представляются в виде трех перемноженных матриц — model (мировые координаты геометрии), view (положение «глаз» в мире, или по простому камера. Умножая model на неё, мы получаем координаты объекта в пространстве камеры) и projection (матрица проекции, которая преобразовывает координаты из пространства глаз в тот самый Clip Space. Именно в этой матрице задается FOV для перспективной проекции и виртуальные размеры экрана для ортографической матрицы). После этого, координаты каждой вершины трансформируются полученной ModelViewProjection матрицей и получается финальная позиция для Clip Space. Звучит как сложный учебник матану, по факту всё очень просто. :)
Детали реализации низкоуровневого матана, в том числе перемножения матриц и построения матриц трансформаций и проекции знать желательно, но необязательно. Сейчас этим занимаются очень удобные математические библиотеки — например, glm, dxmath или d3dx.
Кроме того, ранее именно на вершинном этапе считалось освещение для уровня. В некоторых видеочипах была возможность аппаратного расчета источников света, в некоторых — только программная на ЦПУ.
На видеокартах тех лет, в том числе и S3 Virge, трансформацией вершин занимался центральный процессор, из-за чего было довольно серьёзное ограничение на количество вызовов отрисовки и число треугольников в одной модели. Видеокарты с аппаратной, но всё ещё не программируемой трансформацией вершин появились лишь к GeForce 2 — называлась эта технология T&L (Transform and Lightning) и её преимущество было в том, что у видеокарты были специализированные векторные сопроцессоры, способны быстро пересчитывать векторные операции (а у ЦПУ, в свою очередь, развивались SIMD наборы инструкций, позволяющие выполнять несколько операций над float одновременно). В некоторых случаях, был даже отдельный программируемый векторный сопроцессор как, например, в PlayStation 2, что позволяло реализовать вершинные шейдеры ещё в 2000 году! На современных видеокартах, этапом трансформации в самом простом случае управляют вершинные шейдеры. Помимо этого, есть возможность создания геометрии «на лету» с использованием тесселяции и геометрических шейдеров, а совсем недавно появились Mesh-шейдеры, которые объединили несколько подэтапов конвейера в один.
Растеризация: Сам процесс отрисовки геометрии на дисплей с данными, полученными с прошлого этапа. Именно на этом этапе треугольники (или иные геометрические примитивы) закрашиваются определенным цветом или на них накладывается текстура. В процессе растеризации есть такое понятие, как интерполятор — специальный модуль, который интерполирует несколько значений в барицентрических координатах растеризуемого треугольника, дабы текстурный юнит мог наложить определенный участок текстуры на фрагмент треугольника.
В современных видеокартах этот этап конвейера программируется пиксельными (или фрагментными) шейдерами. В старых видеочипах (исключение — вроде-бы частично программируемый GPU Nintendo 64, поправьте в комментариях, если не прав) этот процесс строго определен в каждом GPU и не программировался. Именно поэтому такой подход к рисованию графики назывался Fixed function pipeline. Были ещё комбайнеры, но они появились заметно позже — когда в видеокартах появилось уже несколько текстурных юнитов, способных смешивать несколько текстур одновременно.
Делая вывод, мы можем понять, что S3 Virge и другие видеочипы были устройствами, которые умели рисовать лишь тот уровень графики, который был заложен производителем с завода. Такой подход называется фиксированным конвейером — Fixed Function Pipeline. Сейчас разработчики видеочипов перешли с фиксированного конвейера на программируемый (шейдерный). Уже начиная с SM2.0-SM3.0, на современных видеокартах появилась возможность создавать крутое и достаточно сложное освещение и различные эффекты, которые стали неотъемлемыми в современных играх.
Кроме того, важно понимать, что в видеопамяти ранних видеочипов хранился только фреймбуфер, а немного позже — текстуры, именно поэтому VRAM в старой документации называют «текстурной памятью». Вообще, некоторые нюансы первых версий OpenGL тянуться именно из особенностей работы первых видеокарт. Вспомнить хотя бы первые функции для старта отрисовки геометрии и загрузке вершин на видеокарту — это были связки glBegin/glVertex/glEnd:
glBegin(GL_TRIANGLES);
glVertex3f(0, 0, 0);
glVertex3f(1, 0, 0);
glVertex3f(1, 1, 0);
glEnd(); // Для одного треугольника
glBegin(GL_TRIANGLES);
for(int i = 0; i < numTriangles; i++) { glVertex glVertex glVertex }
glEnd(); // Для меша
Даже сам glBegin/glVertex/glEnd появились не спроста. Геометрию на видеокарте начали хранить только в начале нулевых (и то не везде — привет встройкам Intel и S3).
Но перейдем к особенностям работы S3 ViRGE. Даташит лежит в свободном доступе, благодаря чему мы можем более подробно ознакомиться с характеристиками этого видеочипа и о том, как он работал под капотом.
В основе у нас лежит 64-х битное ядро, которое могло обрабатывать как 2D-графику с аппаратным ускорением, так и 3D-графику. Ядро работало на частоте 135МГц с встроенным RAMDAC (модуль, отвечающий за вывод картинки на аналоговые разъемы — VGA и DVI, однако выводом на TV-тюльпаны занимался отдельный чип TV-энкодер). Современные видеочипы перешагнули планку 1ГГц, однако сравнение исключительно по частоте некорректны — архитектуры очень сильно отличаются. Помимо этого, видеочип умел декодировать видео с интерполяцией и аппаратно «помогать» процессору с скейлингом видео (например, когда вы разворачиваете плеер на весь экран) и даже рендерить видео в текстуру (что позволяло реализовать, например, телевизоры в играх)!
3D движок поддерживал следующие возможности:
Затенение по Гур.о
Маппинг текстур с перспективной коррекцией и билинейной/трилинейной фильтрацией, а также мипмаппингом.
Depth-буфер, сэмплинг тумана и поддержка альфа-блендинга (прозрачной геометрии).
Чип поддерживал две шины — PCI и менее известную VLB (Vesa Local Bus, очень условно ISA)
Помимо этого, у чипа не было встроенной памяти — к нему необходимо было подключать внешнюю DRAM-память 2/4/8Мб. От её количества зависело максимально-поддерживаемое разрешение экрана. Текстуры при необходимости хранились в ОЗУ.
Видеопамять когда-то расширялась за счёт дополнительных модулей! Эту видеокарту можно расширить аж до 8МБ!
Поддерживаемые разрешения экрана:
Для DirectDraw и ускорения 2D-графики в Windows была реализация аппаратного BitBLT — копирования пикселей в точку на экране. Она поддерживала все режимы, которые были в реализации этой функции в Windows — от монохромных, до 24-х битных. Без альфа-блендинга, само собой. Но тут нет ничего необычного — многие видеочипы тех лет предоставляли простое 2D-ускорение.
Интереснее реализация отрисовки 3D-графики. Каждый треугольник описывался 3-мя регистрами на каждый параметр — координата X, Y для каждой точки, текстурные координаты и т. п. Всего для отрисовки одного треугольника могло потребоваться до 43 регистров! Весьма немало. И именно из-за этого в свое время появились glBegin/glVertex/glEnd!
Параметры сэмплера (текстурного юнита) задавались регистрами, которые определяли формат пикселя текстуры и сам тип фильтрации. Как я уже говорил выше — поддерживалась билинейная и трилинейная фильтрация и проприетарный формат сжатия текстур, который стал стандартом: S3TC или DXT.
Для программирования S3 ViRGE было разработано собственное C SDK — S3DTK, которое состояло из сэмплов и заголовочных файлов для общения с GAPI видеочипа (или видеочипом напрямую, если игра предназначена для DOS). При этом вполне не исключено, что GAPI для Windows работало с видеокартой напрямую, предоставляя PCI-драйвер лишь как прослойку для обмена данными. Поскольку это не D3D, для игр с поддержкой видеоускорения требовалось качать специфические версии. Некоторые игры (как Quake 2) поддерживали мультирендер, но не поддерживали S3 ViRGE.
Весь графический API помещался в один заголовочный файл. API было не простым, а очень простым и понятным — думаю, даже разработчикам-новичкам было легко начать программировать под ViRGE!
Формат вершин был фиксированным и зависел от того, как вы рисовали геометрию на экране:
GAPI поддерживало различные типы треугольных списков, а также точки (POINT для спрайтов и систем частиц) и линии:
#define S3DTK_TRILIST 0
#define S3DTK_TRISTRIP 1
#define S3DTK_TRIFAN 2
#define S3DTK_LINE 3
#define S3DTK_POINT 4
Фактическое API для рисования умещалось в 9 функций и ещё несколько функций для инициализации библиотеки, преобразования адресного пространства и работы с Windows.
Для работы с состоянием видеочипа служили две функции — SetState и GetState. Именно они отвечали за то, как рисовалась геометрия на экране:
А для фактического рисования примитивов служили функции TriangleSet и TriangleSetEx! Да, это альтернатива DrawPrimitives/DrawArrays в современных GAPI. Никаких индексов тогда ещё не использовалось! Функции принимали указатель на массив вершин и их количество, а также на тип рисуемой геометрии (треугольники, линии и т. п.). В Ex версии, можно было «пачкой» установить стейты параллельно с рисованием — такой подход используется в DX10+ API — стейты тоже задаются исключительно «пачками», только теперь они поделены на подгруппы.
Для 2D-рисования были свои, отдельные функции — для блиттинга. Поддерживался ColorKey/хромакей — прозрачным считался определенный цвет, переданный как параметр функции
Основной причиной медлительности S3 ViRGE был низкий филлрейт. При отрисовке примитивов, которые занимают большое пространство экрана, FPS резко просаживался даже с примитивными кубиками и пирамидками. Однако, если не насаживаться на филлрейт и делать что-то типа 2D-поля и 3D-танчиков, то производительность оставалась вполне приемлимой.
История S3 закончилась поглощением компанией VIA. После этого, компания разрабатывала интегрированную графику специально для чипсетов VIA, а материнские платы на этих чипах пользовались довольно высоким спросом. Поэтому нередко взяв старый бюджетный ноутбук, года эдак 2005, можно найти в нём VIA Chrome — наследника легендарного S3 Savage! Проблемы у такого подхода тоже были — из-за наследия из конца 90х, ранние Chrome по сути поддерживали только D3D 7.0 и OpenGL ~1.4. Несколько позже, в 2009 году, компания выпустила S3 Chrome 540 GTX — одну из последних видеокарт на собственной архитектуре. Этот видеочип был достаточно современным и поддерживал DX10.1, OpenGL 3.0. Интересно, реально ли найти эту видеокарту сейчас?
По итогу мы можем сделать вывод, что первые 3D-ускорители были относительно простыми устройствами «под капотом» и их можно было программировать чуть ли не «напрямую». Многие старые видеочипы получили свои локальные прозвища и стали легендарными, однако их архитектура и принцип работы оставались тайной. По крайней мере, в рунете точно.
S3 Trio
Насколько я понимаю, неравнодушные инженеры после закрытия 3dfx и слияния S3 с VIA решили «слить» даташиты в сеть, за что им большое спасибо! Ведь теперь мы имеем возможность посмотреть на принцип работы таких устройств сами!
Материал подготовлен при поддержке TimeWeb Cloud. Подписывайтесь на меня, мой Telegram и @Timeweb.Cloud, чтобы не пропускать новый материал каждую неделю!