Начало работы с Yocto Linux BSP на комплекте разработчика Polarfire SoC FPGA Icicle

В прошлом месяце мы получили комплект разработчика Microchip PolarFire SoC FPGA Icicle, оснащенный PolarFire SoC FPGA, состоящим из подсистемы RISC-V CPU с пятью 64-битными ядрами и FPGA с 254K LE, и загрузили предустановленный образ операционной системы Linux на основе OpenEmbedded.

Сегодня мы покажем, как начать работу с Yocto BSP и запустить тест EEMBC CoreMark, а через пару недель мы проверим FPGA с Libero SoC Design Suite.

Операционные системы, поддерживаемые PolarFire SoC FPGA

Первоначально, идея заключалась в том, чтобы сосредоточить эту часть обзора на Linux, проверке некоторой системной информации, запуске некоторых тестов (например, SBC-Bench), компиляции ядра Linux и установке таких сервисов, как стек LEMP (Linux, Nginx (произносится как Engine-X), MySQL, PHP), который может использоваться, например, для хостинга WordPress. Но затем мы посмотрели на операционные системы, поддерживаемые Microchip PolarFire SoC FPGA.

Есть Yocto Linux BSP и Buidlroot Linux BSP, поддерживаемые Microchip, а также дистрибутивы Embedded Linux от третьих сторон, таких как Siemens Embedded и WindRiver. Говорят, что скоро появится FreeBSD, и несколько операционных систем реального времени.

Это означает, что нет менеджера пакетов и корневой файловой системы на основе Debian, за исключением некоторых инструментов, которые мы планировали использовать. Чтобы достичь того, что мы намеревались сделать, понадобится более 100 часов работы, которых у нас нет… Поэтому мы уменьшили свой пыл и вместо этого поделимся с вами нашим опытом создания образа Yocto, кросс-компиляция hello world, а также встроенной компиляции и запуске теста EEMBC. Мы не в первый раз работаем с Yocto Project, но мы все же узнали кое-что новое в процессе, и мы надеемся, что и вы тоже.

Демонстрация веб-сервера и аналитика напряжения/тока

Перед тем, как приступить к работе над Yocto BSP, мы подключили плату к Ethernet, чтобы выполнить руководство по началу работы от Microchip, и запустили веб-сервер.

Мы можем получить доступ к веб-странице, на которой будут отображаться напряжение и ток для VDDA (XCVR Tx/Rx Lanes Supply), VDD25 (PLL и PNVM Supply), VDDA25 (XCVR PLL Supply) и VDD (Core Supply), перейдя по адресу http://<board_ip_address>

Будет интересно вернуться на эту страницу после того, как мы запустим тест EEMBC CoreMark.

Yocto Linux BSP

Давайте соберем Linux с помощью Yocto BSP, как описано на Github. Для справки, мы используем ноутбук под управлением Ubuntu 20.04, и нам пришлось изменить некоторые команды.

Для начала установим утилиту repo:

затем несколько зависимостей:

Время инициализировать repo:

Теперь мы можем настроить сборку:

Чтобы начать сборку, выполните следующую команду:

Система сборки Yocto может занять много времени. Около 10 лет назад мы потратили более 24 часов на создание образа на недорогом ноутбуке с настройками по умолчанию. Наш ноутбук работает на 8-ядерном процессоре AMD Ryzen 7 2700U и оснащен 16 ГБ оперативной памяти, быстро становится очень медленным и почти непригодным для использования при загрузке процессора 50+:

Мы не стали торопить события. Но мы не проверили требования к хранилищу, и сборка остановилась примерно через два часа из-за того, что на нашем жестком диске заканчивается место. Как мы увидим, когда сборка будет завершена, потребуется около 100 ГБ бесплатного хранилища.

Пока мы говорим о системных требованиях, для пакета проектирования Libero SoC потребуется около 35 ГБ дополнительного места, а для разработки PolarFire SoC не менее 16 ГБ ОЗУ. Поэтому вам понадобится мощная рабочая станция для разработки приложений на комплекте разработки PolarFire SoC FPGA Icicle с большим объемом оперативной памяти и достаточным объемом памяти.

Вернемся к нашей сборке Yocto. Идеально было бы иметь выделенный сервер сборки, но если вы собираетесь использовать свой компьютер одновременно со сборкой, вы можете отредактировать [your_yocto_build_dir] /conf/local.conf

тогда

Перед началом сборки…

Альтернативой является приостановка сборки с помощью Ctrl-Z, который работает аналогично Ctrl-C, но использует SIGTSTP вместо SIGINT, чтобы приостановить процесс, а не завершить его.

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

Мы приостановили процесс примерно на 3 часа, а потом его можно возобновить командой «fg». Это похоже на режим гибернации для терминальных программ, и он существует всегда, но мы никогда не использовали его. Полная сборка на нашем устройстве заняла от 7 до 8 часов.

Это пространство, используемое Yocto BSP:

Мы можем найти образ в папке tmp-glibc/deploy/images/icicle-kit-es/:

Несжатый образ имеет размер 5,5 ГБ, поэтому его можно разместить на SD-карте 8 ГБ, но рекомендуются карты 16 ГБ или 32 ГБ. Это команда Microchip для прошивки на SD-карту:

Но если вам нужна проверка образа, предпочтительнее использовать такие утилиты, как USBImager. Это то, что мы использовали для прошивки образа на SD-карту емкостью 32 ГБ, которую затем вставили в слот для SD-карты.

Прервем загрузку, чтобы проверить, обнаружена ли SD-карта:

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

Размер rootfs не был изменен автоматически, и, похоже, возникла проблема с таблицей GPT… Мы не совсем понимаем, что произошло. Но поскольку наш самодельный образ работает, и у нас есть флеш-память eMMC, давайте сохраним его во внутреннее хранилище.

Выключите плату, извлеките SD-карту и подключитесь к ttyUSB0 с помощью Bootterm, чтобы получить доступ к терминалу HSS:

Перед перезапуском платы, прервав загрузку, введите «usbdmsc», чтобы открыть флэш-память eMMC в качестве USB-накопителя для ноутбука с Ubuntu.

Нам понадобится еще один кабель Micro USB, подключенный к порту Micro USB J16, чтобы увидеть флешку в Ubuntu.

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

После завершения мы можем отсоединить кабель micro USB, подключенный к J16, и получить доступ к нашему образу Linux …

Кросс-компиляция “Hello World”

Попробуем кросс-скомпилировать программу “Hello World”

для RISC-V с помощью набора инструментов Yocto, который мы сначала добавим к нашему пути:

и используем инструмент RISCV GCC для его создания:

К сожалению, это не работает должным образом. Похоже, что набор инструментов установлен неправильно, или мы использовали не тот инструмент. Мы пытались поработать с CFLAGS, но не повезло … Может, он должен работать только в рамках Yocto/Bitbake … У нас есть опыт работы с buildroot, и обычно инструментальная цепочка кросс-компиляции работает из коробки.

Тест EEMBC CoreMark

Построим EEMBC CoreMark прямо на плате. Созданный нами образ поставляется с git и набором инструментов GNU GCC, поэтому он должен быть простым.

Это и создает, и запускает CoreMark с двумя сгенерированными файлами.

• run1.log
  

• run2.log

Плата набрала 1339,136257 баллов, или около 2,23 CoreMark/МГц, поскольку ядра RISC-V работают на частоте 600 МГц. Но Microchip сообщает на плате 3,25 CoreMark/МГц. Давайте попробуем еще раз с теми же флагами, которые использует компания:

Это содержимое run1.log:

Почему-то результат CoreMark нигде нельзя найти, но у нас все еще есть количество итераций в секунду, которое увеличилось с 1341,651573 до 1666. Так что оно улучшилось. Взглянув на код, легко понять, почему рейтинг не отображается:

Давайте повторим это с -DHAS_FLOAT = 1…

На этот раз все выглядит правильно:

Но это всего лишь 2,59 CoreMark/МГц, все еще не до 3,125 CoreMark/МГц. Фактически, он соответствует результатам Microchip с использованием беззнакового индекса. Кто-то пытался сделать то же самое, и ему посоветовали изменить код в posix/core_portme.h, чтобы использовать индекс со знаком:

После повторного запуска теста результат стал еще выше:

1789,159376 CoreMark соответствует примерно 2,98 CoreMark МГц. Мы можем окончательно взломать устройство, определив HAS_FLOAT = 0 в командной строке make. Результат будет следующим:

Если использовать результат Iterations/Sec: 1875 в качестве значения CoreMark 1.0, и в этом случае мы действительно можем достичь точно 3,125 CoreMark/MHz, как это сделал Microchip для использования индекса со знаком. У нас нет уверенности в том, почему signed намного быстрее, чем unsigned … и нам нужно будет посмотреть на сборку и проверить количество циклов для каждой инструкции, чтобы узнать.

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

На сегодня это все, а через несколько недель мы, надеемся, опубликуем что-нибудь о FPGA. Кто-то попросил нас оценить стандартизированный интерфейс virt-io по шине PCI-e, но из-за нехватки времени мы не смогли этого сделать. Мы задали это вопрос представителям компании Microchip и нам ответили, что все должно работать, но они не тестировали его …

Если вас интересует плата, ее можно приобрести у различных дистрибьюторов, таких как Mouser, по цене менее 500 долларов.

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

Оригинал статьи вы можете прочитать здесь.