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

Мне всегда очень нравились компактные полноценные компьютеры, которые можно куда-нибудь применить и они не будут потреблять слишком много энергии. Время от времени я мониторю различные онлайн-барахолки на манер интересных предложений — с годами, рыночная цена на различные «офисные» девайсы только падает. Недавно я увидел, что цены на неттопы на базе Intel Atom пробили дно и начали стоить какие-то сущие копейки: 400 рублей, 800 рублей, 1300 рублей — и это всё за полноценные, полностью рабочие компьютеры на одно-двух ядерных Intel Atom и с 2-4гб ОЗУ! Но главный интерес заключается не столько в самом атоме, сколько в их «мультимедийной» направленности: многие неттопы тех лет построены на базе чипсета NVidia ION, который был эдакой попыткой сделать нетбуки с более широкими мультимедийными возможностями — в том числе, с довольно неплохим интегрированным GPU GeForce 9400. На что способна компактный «мультимедийный» ПК за 1.000 рублей? Давайте смотреть!

❯ Немного предыстории

Компактные компьютеры появились отнюдь не с появлением первых одноплатников и различных тв-боксов/тв-стиков. Спрос на компактные и недорогие машинки, которые можно использовать для офисных задач, удаленной работы и серфинга в интернете, был практически всегда и их история тянется ещё с прошлого века. Ещё 20-25 лет назад можно было купить полноценный минипк на базе настоящего x86 процессора — Cyrix MediaGX (aka AMD Geode), хотя его производительность была достаточно невысокой. Чаще всего, системы на базе этого процессора работали на Win 3.1/Win95, а в нулевых — на базе Windows CE.

Однако, минипк до конца нулевых в основном оставались исключительно «рабочими» машинами: чаще всего, это были либо тонкие клиенты, либо POS-терминалы а-ля кассы, либо промышленные материнские платы с собственной гребенкой GPIO для управления различными станками. Всё изменилось с выходом Intel Atom в 2008 году, появлением первых APU от AMD и развитием ARM-чипсетов и Linux на них. Техпроцесс уже позволял поместить как само вычислительной ядро/ядра, так и всю необходимую логику под один кристалл — что и дало жизнь двум новым классам устройств: неттопы и нетбуки (правда, тут с оговоркой, поскольку OLPC и EEEPC 701 — это тоже нетбуки, вышедшие аж за год до появления первого Atom, а ещё раньше были UMPC в виде промышленных планшетов на Celeron'ах).

В наше время, концепцию неттопов переняли множество самых разных устройств: ТВ-боксы/стики, NUC'и, Compute-стики и в очень большой степени — одноплатные компьютеры, хотя действительно шустрые минипк могут ощутимо ударить по карману. Но, у неттопов-старичков есть одно очень большое преимущество, которое буквально даёт им вторую жизнь в 2023 году: это крайне низкая цена на различных барахолках. Недавно я листал объявления и наткнулся на два интереснейших варианта за реальные копейки:

Acer Aspire Revo — очень симпатичный и компактный девайс на базе Intel Atom 230 и с чипсетом Nvidia ION. Купил я его за 900 рублей (9$ на момент написания статьи).

И неттоп ICL, который по старинке называют тонким клиентом. На самом деле, это Pegatron Amis L6 — OEM-устройство, на которое просто перекинули свои шилдики. Этот девайс уже немного новее и работает на базе Atom D425 и встроенной графики Intel (в некоторых вариациях — двухядерный Atom D525 и ION 2). Цена этого девайса, внимание, всего450рублей (4.5$ на момент написания статьи) — правда у него не было HDD, но заявлен он был как рабочий!

Конечно не стоит забывать и о Mac Mini, который появился ещё в 2005 году: инженеры Apple умудрились уместить в небольшой корпус довольно мощный по тем временам PowerPC G4, а через два года — уже полноценный Core 2 Duo и это учитывая крайне миниатюрный корпус девайса. Но всё же мак был явно не таким дешевым и массовым устройством, как неттопы на базе Atom, хотя и сейчас их можно найти на барахолках по весьма низким ценам: в среднем 2-3 тысячи рублей за модели 2007 и 2008 года, однако учтите что обязательно придётся апгрейдить ОЗУ (ноутбучная DDR2 стоит копейки).

Предлагаю посмотреть на купленных мной красавцев поближе!

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

Несмотря на то, что оба девайса работают на Intel Atom, построены они на совершенно разных платформах. Aspire Revo работает на базе самых первых Intel Atom, которые имели только одно ядро и были не особо шустрыми в повседневных задачах, да и с мультимедией у них были проблемы — ведь GMA3150 особо не переваривал FHD видео. Неттоп от Pegatron построен на базе более свежей платформы Pine Trail, в которой некоторые процессоры имели 2 ядра и 2 потока, что давало неплохой буст производительности. Однако а моем экземпляре, место под ION2 и VRAM на плате было пустым — графику, к сожалению, не распаяли.

Давайте посмотрим на характеристики обоих девайсов поближе:

Aspire Revo R3600:

• Процессор: Intel Atom 230 на частоте 1.6Ггц, L2 кэшем 512Кб и тепловыделением 4Вт.

• GPU: GeForce 9400 из NVidia ION. Поддерживается декодирование 1080p видео, DX11, GL 3.0, есть HDMI и VGA одновременно.

• ОЗУ: 4 гигабайта DDR2 памяти.

• HDD: 250гб 2.5" SATA + порт eSATA (кто-то помнит такой?).

• Питание: 65вт, обычный Acer/Asus штекер, практически любой 12в ноутбучный БП должен подойти.

Pegatron Amis D425:

• Процессор: Intel Atom D425 на частоте 1.8Ггц, L2 кэшем 512Кб и тепловыделением 8Вт.

• GPU: GMA3150 — GL1.4, DX9 — да и то не полностью. Из видеовыходов только VGA и LVDS (который не задействован т.к у нас неттоп, а не нетбук), HDMI нет.

• ОЗУ: 2гб одной планкой DDR3. При желании можно и расширить.

• HDD: 250Гб 2.5" SATA. Порта eSATA нас лишили взамен более компактным размерам устройства.

Самое время обслужить оба девайса. Иногда за 1.000-1.500 рублей можно встретить абсолютно новые неттопы, но в моём случае, девайсы были сильно Б/У. И если Revo ещё выглядел вполне презентабельно, за исключением мелких царапок и даже ни разу не разбирался (пломба была на месте), то Pegatron пришлось тяжко — кто-то явно вскрывал его отверткой. Сами клипсы здесь действительно очень жесткие и снимать их без съемника проблематично, но не отверткой корпус гнуть же! Обратите внимание на «ушко» для открытия корпуса: от него ведите в сторону передних USB-портов и аккуратно расщелкивайте корпус:

Как и было заявлено, в устройстве не оказалось HDD. В остальном, девайс был в хорошем состоянии и его явно когда-то обслуживали.

На фото HDD уже стоит.

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

Обратите внимание: на плате есть места, где должен быть распаян ION и видеопамять для него. Поскольку ION был построен на базе десктопного GPU, он требовал отдельную видеопамять, несмотря на возможность резервировать часть ОЗУ под свои нужды.

Кроме минорной чистки кулера и радиатора, девайс требовал HDD, благо читатели мне заслали несколько 2.5" HDD и SSD, за что им большое спасибо! Собираем всё обратно и начинаем перебирать второй девайс, пока на первый устанавливается система.

Aspire Revo — вообще верх продуманности как по мне. Крышку держит всего один винт, который закрыт гарантийной пломбой. Срываем пломбу, откручиваем винт и снимаем крышку с клипс — и все! Очень удобно.

Этот девайс уже гораздо серьезнее — здесь довольно большой радиатор охлаждает как здоровенный чипсет (обратите внимание на размер кристалла), так и процессор. Сравните размеры кристаллов на обеих чипах :)

В остальном, обслуживать его тоже очень легко и просто — нам доступно два слота для мобильной DDR2-памяти, так что если у вас тоже будет Revo, но чуть более слабый — не беда, можно проапгрейдить, благо DDR2 стоит копейки.

У моего девайса HDD был жив, однако если вам попадётся экземпляр с мертвым «винтом», то для замены придётся разобрать устройство полностью. Достаточно открутить винты, крепящие плату к корпусу, осторожно вытащить плату с кнопкой включения, eSATA и USB и аккуратно вытащить плату. HDD крепят 4 винта с обратной стороны.

После развертывания системе, предлагаю перейти к практическим тестам!
На Pegatron я накатил Windows XP, на Revo Windows 7 — дабы понимать разницу в производительности.

❯ Синтетика и бенчмарки

В синтетике всё с виду неплохо: производительность ЦПУ обеих девайсов находится примерно на одном уровне: между Pentium 4 Extreme Edition (топовые процессоры 2003 года). Оба процессора имеют одно ядро и два потока.

Тест CPU Queen. В синтетике, процессор весьма близок к сборке из двух Pentium D, пусть и не самых топовых. Revo, конечно же, немного шустрее:

Обе машинки тихие и не сказать, что горячие. Температура Pegatron при пиковой нагрузке не превышала 40-45 градусов, в то время как Revo грелся до 65 градусов в пике. Даже на нетбуках тех лет, результат обычно хуже: некоторые атомы были достаточно горячими.

Касательно графики, у Pegatron используется известный многим чипсетный GPU GMA 3150. Это очень слабенький графический ускоритель, у которого большие проблемы с драйверами на OGL — поддерживается DX9.0c (с SM 3.0, но есть болячки совместимости) и OpenGL 1.4 (т.е без шейдеров вообще). Кроме этого, у него полностью программный вершинный конвейер, из-за чего на и без того слабый процессор ложится дополнительная нагрузка. Начиная с 2000 года, как раз с выходом GeForce 2, большинство видеочипов уже обрабатывали всю геометрию на GPU (трансформация из World space в Clip space), а S3 (VIA), SIS и Intel продолжали просчитывать геометрию на процессоре, из-за чего производительность игры падала обратно пропорционально количеству треугольников на экране. Даже на PS2 уже сделали некое подобие вершинных шейдеров — программируемый VPU, где трансформировалась вся геометрия, но производители «встроек» упорно не хотели следовать тендециям. Ситуация изменилась ближе к выходу Intel HD Graphics — там с этим было всё хорошо :)

Помимо ускорения 3D-графики, он умеет декодировать h263 видео с разрешением до 720p, но для потокового видео из браузера, его конечно же не хватит. Хотя, если предварительно качать видео — то вполне потянет.

Другое дело — Revo с его GeForce 9400. Вообще, выходило целых две версии платформы ION: первая, как уже было сказано выше, использовала GF 9400, а вторая использовала GF 305 (это номер модели, а не чипа). Да, даже слабее «затычки» GT 310. GF9400 уже имел нормальный вершинный конвейер, поддержку DX10, умел декодировать видео до FHD и имел видеовыход на HDMI. Кроме того, с этими GPU нет проблем на Linux: 9400 поддерживает как Nouveau, так и официальные драйвера NV.

Скажу сразу: серфить нормально интернет на этих девайсах не получится. Современный веб очень сильно разжирел: если в 2010-2015 годах, с подобных машинок вполне можно было сидеть в интернете тех лет с относительным комфортом, то сейчас даже Хабр едва ли загружается :( Windows 10 накатывать сюда даже смысла нет — будет неюзабельно!

❯ Играем

Одна из главных ION была встроенная графика. В десктопном и ноутбучном исполнении, GF9400 весьма неплохой видеочип: из ПК на его базе вполне можно соорудить машину для игры в игры эпохи PS2/PS3 с комфортом. Однако, в Revo GF 9400 совсем уж подрезали: производительность игр начала нулевых даже в 720p достаточно печальная.

HL2 с mat_dxlevel 80 идёт… с жалкими 10-15 FPS на сценах с водичкой и 20-30 на закрытах сценах. Да, это очень плачевный результат, при том что остальные настройки выкручены в минимум. На GMA3150, например, с mat_dxlevel 70, у нас есть… кадров 10 максимум :)

GTA VC идёт ощутимо получше. Здесь игра относительно нормально работает в 1080p, с просадками до 20 кадров. Такое себе удовольствие, не этого ожидаешь от GF9400! На GMA3150 дела совсем плохи, скажу честно — я удивлен такому результату. У меня есть ноутбук iRu, топовый для своих лет: дискретный GF 4 440 Go + десктопный Pentium 4. Там Vice City «летает» в стабильных 30FPS при 720p, а тут гораздо более свежая встройка не вытягивает и 15 нормально…


А ведь GF4 MX440 когда-то считалась хоть и народной, но слабой карточкой…

NFSU2 обоим девайсам даётся плохо. На GF9400, мы получаем лаги при разрешении выше HD и с средними настройками. На GMA3150 игра идет плохо вообще при любом раскладе. Однако, судя по всему, рендерер NFS тех лет сам по себе не очень оптимален.

Но во что тогда играть на них! Правильно, в «героев» :)

К сожалению, игровые возможности обеих девайсов оказались не сильно выше тонкого клиента из 2006-2007 года за 500 рублей. ION чуточку нас подвел… хотя интересно было бы разжиться девайсом на базе ION 2 — авось там ситуация лучше.

Пока что я вижу единственный вариант для миниатюрной консоли с эмуляторами + нативными играми на базе ПК-железа — это взять плату от ноутбука 2006-2009 года с дискреткой уровня GF8400, сделать для неё свой корпус на 3D-принтере, развести кнопку включения, дописать «морду» и только тогда получится нормальная машинка для игр уровня PS3!

Может у кого есть битый и распотрошенный ноут середины-конца нулевых? Попробуем дать ему новую жизнь!

❯ Заключение

И хотя ION оказался далеко не таким шустрым, как хотелось бы, применения у этих машинок все еще есть:

• Торрентокачалка, файловый сервер, DLNA-сервер для мультимедиа

• Простенький сервер для домашней странички. Сюда же можно складывать бэкапы.

• Репозиторий для хранения кода.

• Офисная машинка

• ТВ-приставка + консоль для ретроигр «в гараж». Почему бы и нет? :)

В целом, если у вас в кармане всего 500-1.000 рублей и вам нужна слабенькая, компактная машинка для каких-либо задач — почему бы не прикупить себе подобный девайс?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

NDK_DIR = D:/android-ndk-r11c/

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

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

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

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

OUTPUT_NAME = cmdprog

build:

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

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

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

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

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

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

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

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

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

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

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

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

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

void m2dAllocFrameBuffer()

{

fbDev = open(PRIMARY_FB, O_RDWR);

fb_var_screeninfo vInfo; fb_fix_screeninfo fInfo;

ioctl(fbDev, FBIOGET_VSCREENINFO, &vInfo);

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

fbDesc.height = vInfo.yres;

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

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

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

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

}

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

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

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

{

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

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

if(alpha >= 0.99f)

{

absPtr[0] = b;

absPtr[1] = g;

absPtr[2] = r;

}

else {

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

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

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

} absPtr[3] = 255; }

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

{

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

{

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

}

}

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

CImage* m2dLoadImage(char* fileName) {

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

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

if(!f)

{

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

return 0;

}

CTgaHeader hdr;

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

if(hdr.paletteType)

{

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

return 0;

}

if(hdr.bpp != 24) {

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

return 0;

}

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

assert(buf);

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

fclose(f);

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

ret->width = hdr.width;

ret->height = hdr.height;

ret->pixels = buf;

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

return ret;

}

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

m2dInit();

test = m2dLoadImage("test.tga");

test2 = m2dLoadImage("habr.tga");

while(1)

{

m2dClear();

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

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

m2dFlush();

}

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

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

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

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

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

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

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

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

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

void m2dUpdateInput()

{

input_event ev;

int ret = 0;

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

{

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

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

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

}

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

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

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

if(isTouching)

{

tsX = x;

tsY = y;

}

}

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

printf("Test\n");

m2dInit();

test = m2dLoadImage("test.tga");

test2 = m2dLoadImage("habr.tga");

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

m2dAttachTouchCallback(&onTouchUpdate);

while(1) {

m2dUpdateInput();

m2dClear();

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

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

m2dFlush();

}

return 0;

}

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

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

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

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

❯ Заключение

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

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

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

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

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

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

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

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

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

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

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

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

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

cd ../OrangePi3G_iot/
./build.sh

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

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

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

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

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

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

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

insmod i2c-dev.ko


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

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

insmod spidev.ko
Device or resource busy.


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

GPIO

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

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

void gpioInit();

void gpioSetDir(int num, byte dir);

byte gpioGetDir(int num);

void gpioWrite(int num, byte value);

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

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

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

#define GPIO_IMPL

#include "gpio.h"

#include <stdio.h>

void testPin(int pin)

{

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

gpioSetDir(pin, 1);

gpioWrite(pin, 0);

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

gpioWrite(pin, 1);

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

}

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

gpioInit();

testPin(141);

}

Модем

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

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

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

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

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

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

Заключение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• ОЗУ: 256мб.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

dmesg -n 1

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

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

nano interfaces

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

auto wlan0

iface wlan0 inet dhcp

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

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

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

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

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

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

nano /etc/apt/sources.list

...

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

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

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

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

GPIO

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

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

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

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

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

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

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

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

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

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

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

UART

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

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

SPI/I2C

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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