Amlogic

Тестируем железо на плате

• 4-ядерный ARM Cortex-A53
• Графический процессор ARM Mali-470 MP4
• Декодер H.265 4K 60 fps, VP9 4K 60 fps, H.264 4K 30 fps
• Кодировщик H.264 1080P 60 fps
• HDR10, HLG, TCH Prime, Dolby Vision, HDR10+
• USB2.0 хост/устройство
• HDMI Tx v2.0b + CEC
• 10/100 MAC и PHY + Gigabit Ethernet MAC
• PCIe 2.0
• SGMII
• SDIO 3.0 и SD 3.0
• I2S ввод/вывод
• S/PDIF вывод

• 2 х USB 2.0 оба работают
• 1 х Ethernet 100 Мбитный порт работает
• 1 х HDMI работает
• 1 х S/PDIF работает
• 1 х 3,5 мм аудиоразъем работает
• 1 х слот для SD-карт работает
• 1 х ИК-порт так как родного пульта у нас не было, а пульт от Amlogic не подошёл, то протестировать не смогли
• 1 х USB Type-C только как питание
• 1 х WIFI/Bluetooth-модуль: wifi работает, bluetooth не проверяли

Тестируем воспроизведение видео

1. Запускаем 56 тестовых роликов

DEBUG (4077 4077)  Fpid: 1815, tid: 4069, name: rvsd@1.0-servic  >>> /vendor/bin/hw/vendor.realtek.rvsd@1.0-service <<<            DEBUG (4077 4077)  Fsignal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------                                                    DEBUG (4077 4077)  FAbort message: 'FORTIFY: pthread_mutex_destroy called on a destroyed mutex (0xa7b1b06c)'

2. Запускаем тест Geekbench3

3. Проверяем разные fps

4. Запускаем стримы HLS и Mpeg-Dash

5. Встроенные тесты видео от Realtek

6. Запускаем приложение OpenCamera

Выводы

В статье детально, с приведением исходного кода, описывается работа, проведенная по переносу и запуску с SD-карты программной прошивки с ОС Андроид для устройств на процессоре Amlogic S912.

Мне нравятся миниатюрные компьютеры, выполненные по технологии система на чипе (SOC). За крошечные размеры и небольшое энергопотребление по сравнению с персональными компьютерами. Используя такие устройства, можно решать широкий круг задач. На миникомпьютеры можно установить как ОС Android (так делает большинство производителей данных "игрушек"), так и различные дистрибутивы Linux или Chrome OS.

Моя текущая работа это разработка приложений для Андроид. В этой работе очень желательны тесты на реальных устройствах на различных версиях системы. Есть у меня пара миникомпьютеров от компаний Rockchip и Amlogic, на которых я также выполняю свои тесты. Андроид, как операционная система, довольно динамично развивается и сейчас на рынке используются ее модификации от 4.4 до 10 версии. А на подходе уже Андроид 11-й версии.

Многие компании, занимающиеся разработкой телеприставок на базе Андроид, вынуждены иметь недолгий срок сопровождения свои детищ в виду быстрого развития как аппаратных, так и программных средств. Один из моих основных рабочих инструментов для тестов это приставка KM8P на процессоре S912 с двумя гигабайтами ОЗУ и предустановленной операционной системой Андроид версии 7.1. Время идет, и за пару-тройку лет на рынке последовательно появились версии 8.1, 9.0 и 10.0 ОС Андроид.

Очень хотелось бы потестировать свое приложение под этими самыми версиями. Но что делать? Или нужно покупать зверушки на новых процессорах и версиях Андроид, или заниматься самостоятельной адаптацией новых версий Андроида на имеющихся устройствах. Первый путь легок и прост: заплатив не очень большую сумму, проблема легко решается. Но легких путей мы не ищем, поэтому выбираем второй путь. Второй путь гораздо труднее, но интереснее. К тому же, и сам чип S912 является отличным 8-ядерным процессором, не намного уступающим по производительности новейшим процессорам Amlogic на чипе S905x.

Итак, был выбран второй вариант, как более интересный и отвечающий моим потребностям. Встал вопрос: а каким путем пойти? Текущая версия Андроид 7.1 под капотом имеет ядро Linux 3.14.29 и ПЗУ NAND на чипе SK Hynix H27UCG8T2ETR, для которого Amlogic разработала собственный драйвер aml_nftl_dev.ko.

Все новейшие версии Андроид базируются на ядре 4.9. И желательно использовать именно его. Однако, политика Amlogic такова, что последние несколько лет SDK Android компания предоставляет только юридическим компаниям, занимающимся производством устройств на базе чипов Amlogic.

Тем не менее, на просторах github'а можно найти исходники ядра 4.9 на основе SDK Android от Amlogic 2017-18 года. Например, git-репозитарий компании Khadas. Однако, дело, в том, что драйвер aml_nftl_dev для версии ядра 4.9 отсутствует. Что делать? Адаптировать данный драйвер для ядра 4.9? Но помимо адаптации драйвера, придется также править так называемое дерево устройств ядра. Это трудный путь.

Множество устройств на процессоре S912 имеет более современное ПЗУ с контроллером EMMC. К счастью, для обладателей таких устройств совсем недавно (в июне-июле 2020 года) появились прошивки на Андроид 9, собранные энтузиастами (ознакомиться можно здесь и здесь). Я не мог воспользоваться данными прошивками в виду отсутствия на моем устройстве чипа EMMC. Однако, прекрасно понимал, что имея на приставке слот для SD-карточки, для работы с которым используется все тот же драйвер MMC, что и для работы с микросхемой EMMC, можно попытаться использовать SD-карту вместо ПЗУ.

К сожалению, ситуация осложнялась тем, что Amlogic изначально не предусмотрел старт системы с SD-карты. Тем не менее, кое-что было. Amlogic реализовала возможность обновления прошивок с SD-карты. Эта и другие возможности были достигнуты компанией Amlogic путем существенной доработки загрузчика u-boot под свои нужды. В частности, имеется возможность запустить ядро системы с FAT-раздела SD-карты. Итак, было принято решение выяснить, можно ли адаптировать драйвер MMC для возможности старта с SD-карты. Я погрузился в изучение исходного кода драйвера.

Изучая исходный код, я выяснил, во-первых, что драйвер для монтирования загрузочного раздела ограничивается работой только с микросхемой EMMC, а остальные устройства игнорирует. А такими устройствами как раз является SDMMC-слот и SDIO-порт. А почему бы не изменить код так, чтобы драйвер не пропускал устройство SDMMC, а продолжал бы с ним работать, как с EMMC?

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

Получается, что разрешив драйверу работать с SDMMC, как с EMMC и записав таблицу разделов по заранее известному адресу на SD-карте, я смогу, таким образом, сымитировать EMMC и загрузить систему с SD-карты! Подумал, почему бы не сделать утилиту, которая будет записывать таблицу разделов в нужном формате и при необходимости проверять ее корректность. Сказано сделано. Тем более, что сделать ее было несложно, благо практически вся инфраструктура уже была описана в исходном коде драйвера. Исходный код утилиты размещен на github'е, репозиторий amlpt. Утилита создана в ОС Ubuntu. Но, думаю, при необходимости, ее не сложно будет перенести и на Windows.

Для начала нужно заполнить параметры таблицы разделов в файле mmcparts_a9.c, указав там имена, смещения, размеры и тип разделов. Для обычных разделов указывается тип 0x1, для разделов типа cache 0x2, а для разделов типа data 0x4. За начальное смещение первого раздела я взял значение 0x2800000 (40Мб). Далее заполнил имена, размеры и типы разделов в структурах partitions согласно таблице разделов из дерева устройств. Для 9-го Андроида таких разделов насчиталось 17.

Заполнив данные в файле mmcparts_a9.c, создаем утилиту для записи таблицы разделов, запустив скрипт make_amlptwrt.sh. Данный скрипт создает исполняемый файл amlptwrt, с помощью которого можно сформировать двоичный файл mmc_parts.bin. Это и есть наша таблица разделов, которую читает драйвер MMC. Аналогично запускаем скрипт make_amlptrdr.sh для создания утилиты чтения таблицы разделов amlptrdr, с помощью которой мы можем проверить правильность заполнения данной таблицы. После запуска amlptrdr в консоли отобразится таблица разделов с именами, смещениями и размерами в мегабайтах. Примерно так:

Для того, чтобы драйвер MMC заработал с устройством SDMMC, я внес два небольших исправления в исходный код драйвера, в файл drivers/amlogic/mmc/emmc_partitions.c:

а) Во-первых, разрешаем драйверу работать с устройствами, отличными от EMMC. Для этого меняем функцию is_card_emmc следующим образом:

static int is_card_emmc(struct mmc_card *card) {     //struct mmc_host *mmc = card->host;     // emmc port, so it must be an eMMC or TSD      //if (!strcmp(mmc_hostname(mmc), "emmc"))         return 1;     //else     //    return 0;     //return mmc->is_emmc_port;}

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

б) Определяем смещение, по которому будет читаться таблица разделов. Правку делаем в функции mmc_read_partition_tbl:

 //start_blk = get_reserve_partition_off(card);         start_blk = MMC_BOOT_PARTITION_SIZE + MMC_BOOT_PARTITION_RESERVED;

Если посмотрим на исходный код драйвера, то сумма констант MMC_BOOT_PARTITION_SIZE + MMC_BOOT_PARTITION_RESERVED равна 36 Мб. Следует отметить, что данные правки подходят для моего варианта, когда в устройстве отсутствует чип EMMC или в дереве устройств он отключен. Для других случаев придется придумывать более корректный вариант правок.

Итак, смещение, по которому будет записана таблица разделов на SD-карте равна 36 Мб. Для того, чтобы разместить нашу таблицу разделов, созданную утилитой amlptwrt, на SD-карте достаточно выполнить команду:

// 36M = 37748736 bytes = 73728 sectors         sudo dd if=mmc_parts.bin of=/dev/sdb seek=73728 bs=512

При этом предполагается, что /dev/sdb это SD-карта.

Далее компилируем ядро, создаем boot.img с нулевым initrd и примерно такими параметрами ядра:

 root=/dev/mmcblk0p14 rootfstype=ext4 rootwait

Вспомним, что u-boot от Amlogic умеет стартовать ядро Linux c SD-карты с раздела FAT. Создаем на SD-карте в самом начале раздел FAT размером 32 Мб. Этого вполне достаточно для размещения нашего boot.img и dtb.img. В дереве устройств dtb.img необходимо отключить EMMC, чтобы нашей SD-карте было присвоено имя /dev/mmcblk0. Или не отключать, но тогда нужно будет изменить в boot.img параметры ядра, чтобы ядро смогло успешно подключить системный раздел, который в данном случае будет иметь имя /dev/mmcblk0p14.
И, как заключительная часть марлезонского балета, осталось записать разделы Андроид-прошивки на SD-карту. Для этого распаковываем прошивку и записываем на SD-карту подходящие разделы согласно смещениям в таблице разделов:

// logosudo dd if=logo.PARTITION of=/dev/sdb bs=1M seek=40 conv=sync,fsync status=progress // recovery sudo dd if=recovery.PARTITION of=/dev/sdb bs=1M seek=48 conv=sync,fsync status=progress // misc sudo dd if=/dev/zero of=/dev/sdb bs=1M seek=72 count=8 conv=sync,fsync status=progress // dtbo sudo dd if=dtbo.PARTITION of=/dev/sdb bs=1M seek=80 conv=sync,fsync status=progress // cri_data sudo dd if=/dev/zero of=/dev/sdb bs=1M seek=88 count=8 conv=sync,fsync status=progress // rsv sudo dd if=/dev/zero of=/dev/sdb bs=1M seek=96 count=16 conv=sync,fsync status=progress // metadata sudo dd if=/dev/zero of=/dev/sdb bs=1M seek=112 count=16 conv=sync,fsync status=progress // vbmeta sudo dd if=vbmeta.PARTITION of=/dev/sdb bs=1M seek=128 conv=sync,fsync status=progress // param sudo dd if=/dev/zero of=/dev/sdb bs=1M seek=130 count=16 conv=sync,fsync status=progress // boot sudo dd if=boot.PARTITION of=/dev/sdb bs=1M seek=146 conv=sync,fsync status=progress // tee sudo dd if=/dev/zero of=/dev/sdb bs=1M seek=162 count=32 conv=sync,fsync status=progress// vendorsudo dd if=vendor.img of=/dev/sdb bs=1M seek=194 conv=sync,fsync status=progress // odmsudo dd if=odm.img of=/dev/sdb bs=1M seek=324 conv=sync,fsync status=progress // systemsudo dd if=system.img of=/dev/sdb bs=1M seek=452 conv=sync,fsync status=progress // productsudo dd if=product.img of=/dev/sdb bs=1M seek=1802 conv=sync,fsync status=progress

Те разделы, которые отсутствуют в прошивке, я просто заполнял нулями. Некоторые разделы, такие как system или vendor и некоторые другие, могут являться sparse-разделами. Их предварительно необходимо преобразовать в обычные разделы:

simg2img system.PARTITION system.img

С разделами cache и data нужно поступить немного по-другому. Смотрим нашу таблицу разделов, созданную утилитой amlptwrt, и с помощью программы fdisk создаем соответствующие разделы с нужными смещениями и размерами на SD-карте и форматируем их в файловую систему ext4:

sudo mkfs.ext4 /dev/sdb2 sudo mkfs.ext4 /dev/sdb3

После форматирования, с помощью той же утилиты fdisk, удаляем уже ненужные разделы /dev/sdb2 и /dev/sdb3.

Чтобы загрузчик u-boot распознал, что нужно загрузиться именно с SD-карты, размещаем в FAT-разделе файл aml_autoscript. Сам файл aml_autoscript может быть создан с помощью утилиты mkimage из простого текстового файла следующего содержания:

 if mmcinfo; then fatload mmc 0 ${loadaddr} boot.img; fatload mmc 0 ${dtb_mem_addr} dtb.img; bootm; fi;

Вот и все, что необходимо для переноса прошивки с Андроид на борту на SD-карту.

Несколько прошивок, которые были сделаны по данному методу, опубликованы в соответствующей теме на форуме 4PDA. Если что-то непонятно, задавайте вопросы в комментариях. Чем смогу помогу.

За сим позвольте откланяться и удачи всем в переносе прошивок!