Отечественный процессор от компании ЭЛВИС

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

В этой статье речь пойдёт об отечественных производителях процессоров (микроконтроллеров). Сейчас эта тема достаточно популярна: например, этому была посвящена конференция OSDay. В общем, в этот раз к нам попала плата от компании «Электронные вычислительно-информационные системы» ЭЛВИС. Мы затащили туда свой Embox и решили, что пользователям хабра было бы интересно узнать и об этой эпопее.

Итак, процессор, а точнее система на кристалле (SOC), а еще точнее “МИКРОСХЕМА ИНТЕГРАЛЬНАЯ 1892ВМ14Я”, как сказано в руководстве пользователя, имеет:

• два ядра Cortex-A9 или, как сказано в документации, стандартную многопроцессорную систему центрального процессора (MPU) в виде 2-ядерного когерентного кластера ARM Cortex-A9 MPCore c SIMD сопроцессорами Neon;
• два DSP-ядра Elcore-30M
• встроенное ядро аппаратно-программного графического акселератора ARM MALI-300;
• ядро аппаратно-программного видео акселератора “VELcore-01”;
• ...

Нас интересовали ядра Cortex-A9, остальное, к сожалению, так и не “пощупали”. У нас уже была некоторая поддержка Cortex-A9 для платформ i.MX6 и vexpress-a9 (qemu), поэтому мы надеялись, что у нас заработает всё и сразу. Забегая вперед скажу, что почти так и случилось.

Распаковка

Итак, к нам пришла плата Салют-ЭЛ24Д2, по внешнему виду достаточно прилично выполненная, и мы уже было радостно хотели подать питание, но тут обнаружили, что разъем питания есть, а вот разъема для консоли (UART-а) мы не наблюдаем.

Учитывая то, что в комплекте был USB-адаптер с выходами RX/TX/GND/3V3/5V, было логичнее всего было начать поиски порта с такими же именами. При беглом взгляде на плату ничего, каких-то подходящих надписей у пинов найдено не было.

Помимо RS-485 в мануале в списке разъёмов значится разъём XP3, являющийся совместимым с RaspberryPi, содержащий интерфейс RS-232. Оказалось, что именно его и использует u-boot. Как нам пояснили в техподдержке, “на Салют-ЭЛ24Д1 консоль по умолчанию выводится в порт на таком же Raspberry Pi-разъеме (UART0). На DB9 выведен UART3”. Ещё они уточнили, что RS232 – это 12-вольтовый интерфейс, а на XP3 выведен UART (трехвольтовый интерфейс)

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

Проблемы с U-boot

После явного успеха мы приступили к запуску Embox ведь, как уже сказано выше, поддержка Cortex-A9 у нас была, а значит, нам не хватало только правильной карты памяти (memory map) и драйвера того самого UART-а, чтобы увидеть нашу консоль.

Карту памяти и описание UART-а нашли в документации, написали какие-то драйвера, но обнаружили, что в установленном u-boot нет поддержки сети, то есть загружать можно с SD-карточки, как стартует Линукс, ну или через консоль по UART, то есть очень медленно.
На уточняющий вопрос служба поддержки нам подтвердила, что поддержка сети отсутствует, поскольку в u-boot не портированы драйвера.

Небольшое отступление на счет службы поддержки

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

Следующей существенной проблемой стал кэш и прочие настройки, которые остаются после u-boot, например, включенная трансляция адресов.

Проблема была следующая: ассемблерная программа просто записывающая что то в UART, работала, а даже маленький Embox (несколько десятков килобайт) с тем же драйвером ничего не выводил, и вообще вел себя ну очень странно. В результате оказалось, что после заливки образа в память необходимо сбрасывать кэш. Мы обратились в службу поддержки, после некоторой переписки, они воспроизвели у себя ситуацию, предложили пересобрать u-boot с дополнительным флагом, прошить его в spi-flash, ну и дополнительно использовать команду dcache flush.

С включённым MMU, тоже возникли проблемы. По сути, первое что мы делаем в своём загрузчике — выключение трансляции адресов. Включено, если я правильно понимаю, MMU было, как раз для включения кэширования, в больших ARMах если я правильно понимаю, кэширование определяется в дескрипторах страниц. Для чего в U-boot нужно включать кэш, если честно не знаю, но возможно для ускорения загрузки.

Драйвера

После танцев с кэшем Embox “взлетел”, вывел командную строку в которой можно было выполнять команды, ведь как уже говорилось у нас была поддержка cortex-a9, а в стандарт Cortex-A9 включает в себя и контроллер прерывания и таймеры, ну а стандарт ARMv7 содержит работу с MMU и кэшами. В общем, захотелось сделать сетевуху, чтобы хоть какой то интересный функционал попробовать.

В мануале было описание сетевой карты, но конечно хотелось код максимально заимствовать, или иметь хотя бы в качестве примера. Указаний, что это за IP-ядро, не было, в документации карточка называлась “GEMAC”. На просторах интернета упорно не находилось исходников для данной сетевухи. В службе поддержке нам сообщили, что на самом деле это сетевуха от компании Arasan, а драйвера предложили посмотреть в Линуксе, исходники которого доступны (ссылка), поскольку сейчас в ванильном ядре такая сетевуха не поддерживается.

Ради интереса мы посмотрели, что ещё в данном Линуксе доработано. Выполнив команду grep, мы получили следующий вывод:

Вывод

~/elvees/mcom02-buildroot-v2.1-2016-08-30/linux $ grep -rn ELVEES
arch/arm/plat-mcom/platsmp.c:2: * Copyright 2015 ELVEES NeoTek CJSC
arch/arm/mach-vip1/vip1.c:2: * Copyright 2015 ELVEES NeoTek CJSC
arch/arm/mach-vip1/vip1.c:99:DT_MACHINE_START(VIP1, "ELVEES VIP-1 (Flattened Device Tree)")
arch/arm/mach-mcom02/mcom02.c:2: * Copyright 2015 ELVEES NeoTek CJSC
arch/arm/mach-mcom02/mcom02.c:99:DT_MACHINE_START(MCOM02, "ELVEES MCom-02 (Flattened Device Tree)")
drivers/uio/uio_delcore30m.c:4: * Copyright 2016 ELVEES NeoTek JSC
drivers/mtd/nand/arasan_nfc.c:4: * Copyright (C) 2015 ELVEES NeoTek CJSC
drivers/media/i2c/soc_camera/ov2715.c:2: * Copyright 2015 ELVEES NeoTek CJSC
drivers/media/platform/soc_camera/vinc/math/math.h:2: * Copyright 2016 ELVEES NeoTek JSC
drivers/media/platform/soc_camera/vinc/vinc-neon.h:2: * Copyright 2016 ELVEES NeoTek JSC
drivers/media/platform/soc_camera/vinc/vinc-neon.c:2: * Copyright 2016 ELVEES NeoTek JSC
drivers/media/platform/soc_camera/vinc/vinc-driver.c:2: * Copyright 2015 ELVEES NeoTek CJSC
drivers/net/ethernet/arasan/arasan_gemac.c:2: * Copyright 2015 ELVEES NeoTek CJSC
drivers/net/ethernet/arasan/arasan_gemac.h:2: * Copyright 2015 ELVEES NeoTek CJSC
include/uapi/linux/vinc.h:2: * Copyright 2015 ELVEES NeoTek CJSC
include/uapi/linux/vpoutfb.h:2: * Copyright 2016 ELVEES NeoTek JSC

Как видно, ЭЛВИС использует сторонние IP-ядра для многих своих блоков, и блоки порой настолько новые, что приходиться самостоятельно дорабатывать драйвера.

Начав разработку драйвера, мы долго не могли понять, почему же у нас ничего не видится в ее регистрах, проверяли базовый адрес, тупили, пока в тех поддержке нам не подсказали, что необходимо подать частоту на данный модуль. Модуль управления энергосбережением или, как он описан в мануале, контроллер PMCTR позволяет управлять не только подачей питания, но и тактовой частотой устройства. В итоге заработали чтение и запись регистров, но на PHY-е не загорались лампочки, то есть не было линка, да и сам PHY не отвечал ни на одном MII интерфейсе.

В службе поддержке нам предложили сделать так же как в Линуксе, но было совсем непонятно, что же мы такого забыли. То есть, было подозрение на функцию ресета, точнее что нужно установить соответствующий GPIO в единицу, но вот определить какой контроллер GPIO используется какая нога, нам программистам, не любящим читать документацию полностью, было не легко. К счастью, номер порта и контакта нам подсказали в поддержке (PORTB1). Поиск по конфигурации нам подсказал, что используется dwapb_gpio драйвер. После корректной реализации GPIO интерфейса и подачи единицы на этот порт, линк загорелся, PHY обнаружился на седьмом порту MII. Дальше существенных проблем не было, конечно были обычные проблемы с ошибками в реализации, но никаких особенных не было, в результате сетевуха заработала.

Для проверки работоспособности запустили телнет:



Собственно, всё вполне вменяемо работает.

Выводы

Конечно, процессор от ЭЛВИСа невозможно сравнивать с Мультиклетом, слишком уж неравные весовые категории у компаний. Но стоит отметить, что законченность решения тоже совершенно разная. Конечно, можно сослаться на уже готовый софт, для Cortex-A9, но даже его доработка является существенной и ресурсоёмкой проблемой, которую Элвис решает пусть и не идеально, но вполне вменяемо. Или взять службу поддержки: она тоже далека от идеала и мировых компаний, но всё же от нее можно добиться результата в приемлемые сроки.

Поэтому при всех плюсах, сосредоточусь на минусах.

Главный минус, на мой взгляд, это как раз то, что используются покупные блоки. Это является безусловным плюсом для выхода на рынок, но Cortex-A9 вряд ли можно назвать отечественным процессором. Я прекрасно понимаю, что есть ещё два DSP-ядра, но всё-таки основой являются сторонние блоки с очень низкой добавленной стоимостью, как у нас любят говорить в последнее время. То есть, на деньги от данной микросхемы развиваются в основном инженеры компаний, у которых куплены эти ядра (ARM, ARASAN и другие), и которые развивают соответствующее ПО.
Если сравнивать с тем же i.MX 6, потребление существенно больше, хотя в компании ЭЛВИС сказали, что нужно отключить ненужные блоки, и тогда потребление будет сравнимым. Наверное, так и есть, ведь процессорные ядра одинаковые.

Цена, мягко говоря, высока. В ЭЛВИСе, конечно, заявляют, что суммарная производительность микросхемы тоже очень высокая, но что-то я сомневаюсь, что наличие нескольких ядер DSP, может увеличить ее настолько, чтобы сделать ее привлекательной по сравнению с тем же i.MX 6. То есть, я допускаю, что есть некоторое количество задач, для которых не важна цена, например, авионика, но не понятно, зачем там DSP-ядра.

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

На этом разрешите закончить. В целом, лично мне нравится, что, хоть и с трудностями, но развивается отечественная микроэлектроника.

Традиционно, все что написано в статье можно воспроизвести из исходников.

P.S. В минусах высказывалось личное мнение, думаю на мои претензии у компании ЭЛВИС найдутся достойные ответы:)

Как и в случае с предыдущим испытуемым (Мультиклетом), мы связались с компанией и получили следующие комментарии, приводим дословно:

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

На любом Cortex-A9 после выполнения команды 'go' в U-Boot кэш и MMU остаются включенными. Это корректное и правильное поведение. Команда 'go' не предназначена для запуска ОС. На iMX6, с которой Вы работали, видимо, была включена опция CONFIG_SYS_DCACHE_OFF в файле конфигурации. При этом U-Boot не инициализирует MMU и не включает кэш данных.

Загрузка ОС через U-Boot выполняется с помощью команды 'bootm'. Эта команда загружает образ ОС из памяти. В памяти должен находится образ в формате U-Boot. Такой образ содержит поле OS_TYPE, c помощью которого U-Boot определяет необходимую процедуру подготовки к загрузка конкретной ОС. Чтобы Ваша ОС корректно загружалась, U-Boot должен _знать_ про процедуру подготовки к загрузке вашей ОС. Смотрите, например, do_bootm_linux() и cleanup_before_linux().

Дошли руки включить плату, которая была у вас на тестировании и проверить её на предмет потребления процессора.

При работе под Linux Buildroot 2.2 без нагрузки в комнатной температуре процессор без радиатора разогревается приблизительно до 43 градусов (крышка теплая, палец не обжигается). Отключение DSP и VPU немного снижает потребление процессора, и температуру на его корпусе.

Под нагрузочными тестами процессор удалось разогреть до 55-57 градусов (пальцу от крышки горячо, но для процессора это вполне нормальная температура).

Рабочая температура процессора 1892ВМ14Я до 85 градусов. То есть для отладочного модуля Салют-ЭЛ24Д2 при температуре воздуха ниже 50 градусов дополнительное охлаждение процессора не обязательно.

По поводу температуры, допускаю, что температура 50 градусов вполне могла показаться нам некомфортной для такого сверточного измерительного инструмента как палец :)

Кроме того, в тех поддержке нам сообщили, что “по состоянию на сегодня эта поддержка уже интегрирована в U-Boot, будет в следующем релизе Buildroot”