Недавно компания OrangePi обновила линейку одноплатных компьютеров Orange Pi 5/5B/5+, распаяв на платах 32GB LDDR4 RAM. Однако данные платы вполне прилично работают и с меньшим объемом памяти на борту, а наличие SPI Nor Flash и возможность подключения NVMe диска делают эти платы достойными конкурентами среди одноплатных устройств для разаработки.

Нас заинтересовал первый образец серии 5/5B/5+, а именно Orange Pi 5, на предмет того, как на данном устройстве поведет себя EDK II и можно ли его использовать так, как мы привыкли работать с обычными ПК.

В предыдущей статье мы рассмотрели процесс сборки загрузчика. Теперь мы рассмотрим ядро Linux, исходные коды которого поддерживает компания StarFive в репозитории https://github.com/starfive-tech/linux. Кроме того, мы рассмотрим создание скриптов загрузки ядра (boot.scr) для U-Boot.

Компания StarFive одновременно ведет две версии ядра: 5.15.x и 6.1.x. Нас интересует стабильная ветка 6.1.x, поэтому мы возьмем snapshoot тега VF2_6.1_v3.8.2:

Не так давно, а именно в феврале 2023 года, в продажу поступили платы VisionFive2 , имеющие на борту 8GB LPDDR4 памяти, от компании StarFive. По сути VisionFive2 - это первый в мире высокопроизводительный RISC-V одноплатный компьютер (SBC) со встроенным графическим процессором (GPU). И естественно, мы не могли не заинтересоваться этим устройством, которое имеет весьма впечатляющие характеристики.

Большинство современных CPU позволяют производить начальную загрузку с разных источников (media booting), одним из которых может быть SPI NOR Flash. Микросхемы энергонезависимой памяти NOR Flash с последовательным интерфейсом SPI используются на материнских платах для хранения образов BIOS, BMC, а так же данных различного назначения. Если же речь идет о популярных платах, постороенных на различных SoCs, таких как Raspberry Pi, Orange Pi и так далее, то на них SPI-интерфейс может быть выведен на контактные площадки для того, чтобы пользователь мог самостоятельно подключить ту или иную микросхему в качестве внешнего носителя.

NGINX — это HTTP-сервер и обратный прокси-сервер, почтовый прокси-сервер, а также TCP/UDP прокси-сервер общего назначения, изначально написанный Игорем Сысоевым. Уже длительное время он обслуживает серверы многих высоконагруженных сайтов.

Однако кросс-компиляция NGINX практически невозможна, поскольку разработанные Игорем Сысоевым скрипты конфигурирования исходного кода в большинстве случаев используют так называемую процедуру «Try Run».

Те кто знаком с утилитами Autoconf, Automake знают, что проверки необходимых параметров системы и кросс-компилятора осуществляются различными процедурами, которые, в свою очередь, могут применять попытки сборки исходного кода (Try compile), линковки объектных файлов (Try link) и, наконец, попытки запуска тестовых программ (Try Run).

Естественно, если речь идет о кросс-сборке, операции «Try Run» недопустимы, ведь мы не можем запустить программу, собранную под целевую архитектуру отличающуюся от архитектуры машины сборки на самой машине сборки.

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

Скрипты Игоря Сысоева не предусматривают такого переопределения машинно-зависимых величин. Однако величин, которые необходимо задать во время конфигурирования исходных кодов NGINX достаточно много. К ним, в первую очередь, относятся размеры типов данных. Именно с них мы и начнем.

cGit-ui — это web-интерфейс для Git-репозиториев, основу которого предстваляет CGI-скрипт написанный на языке С.

cGit-ui поддерживает Markdown-файлы, которые обрабатываются на стороне сервера с помощью библиотеки md4c, зарекомендовавшей себя в проекте KDE Plasma. cGit-ui предоставляет возможность размещения кодов верификации сайта, а также скриптов от таких систем как Google Analytics и Yandex.Metrika для анализа трафика.

Пользователи cGit-ui получают широкие возможности для настройки как внешнего вида, так и функциональности собственного сайта, на котором они представляют свои репозитории. Кроме того, cGit-ui позволяет создавать и размещать на сайте, так называемые Donation-диалоги для приема пожертвований в пользу тех или иных проектов.

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

С момента выхода интерфейса к Subversion-репозиториям произошел ряд изменений в структуре пакетов, необходимых для установки. Так, например, cScm-демон, который служит для разбора конфигурационных файлов, выделен в отдельный пакет.

Поэтому в данной статье дается более развернутое описание cGit-ui.

cGit-UI — is a web interface for Git repositories. cGit-UI is based on CGI script written in С.

This article covers installing and configuring cGit-UI to work using Nginx + uWsgi. Setting up server components is quite simple and practically does not differ from setting up cGit.

cGit-UI supports Markdown files that are processed on the server side using the md4c library, which has proven itself in the KDE Plasma project. cGit-UI provides the ability to add site verification codes and scripts from systems such as Google Analytics and Yandex.Metrika for trafic analysis. Users who wonder to receive donations for his projects can create and import custom donation modal dialogs.

Instead of looking at screenshots, it is better to look at the working site to decide on installing cGit-UI on your own server.

cSvn — is a web interface for Subversion repositories. cSvn is based on CGI script written in С.

This article covers installing and configuring cSvn to work using Nginx + uWsgi. Setting up server components is quite simple and practically does not differ from setting up cGit.

cSvn supports Markdown files that are processed on the server side using the md4c library, which has proven itself in the KDE Plasma project. cSvn provides the ability to add site verification codes and scripts from systems such as Google Analytics and Yandex.Metrika for trafic analysis. Users who wonder to receive donations for his projects can create and import custom donation modal dialogs.

Instead of looking at screenshots, it is better to look at the working site to decide on installing cSvn on your own server.

It should be noted that you can browse not only your own repositories, but also configure viewing of third-party resources via HTTPS and SVN protocols.

cSvn — это web-интерфейс к Subversion-репозиториям. Основу cSvn представляет CGI-скрипт написанный на языке С.

В мае 2020 года был опубликован релиз очередной версии Apache Subversion 1.14.0. В свете этого события, был создан новый, современный web-интерфейс для просмотра Subversion-репозиториев на любых устройствах. Это весьма позитивная новость для тех, кто использует централизованные системы версионного контроля по тому, что до вчерашнего дня существовал лишь один достойный web-UI (WebSVN), написанный на PHP и, к сожалению, отстающий от современных требований.

В данной статье рассматривается установка и настройка cSvn для работы с использованием Nginx + uWsgi. Настройка серверных компонентов достаточно проста и практически не отличается от настройки cGit.

На стороне клиента работает элементарный JavaScript составляющий не более 350 строк и таблица стилей размером 24K в распакованном виде. Markdown-тексты обрабатываются на стороне сервера с помощью библиотеки md4c, которая успешно зарекомендовала себя в проекте KDE Plasma.

Вместо screenshot-ов, лучше посмотреть на работающий cSvn-сервер.

Стоит заметить, что с помощью cSvn можно просматривать не только собственные репозитории, но и настроить просмотр сторонних ресурсов по протоколам HTTPS и SVN.

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

Целью настоящей работы является практическое изучение средства управления поддеревьями Git.

Начиная с ревизии 1.7.11 upstream-репозиторий Git, в каталоге contrib/subtree, содержит средство автоматизации работы с поддеревьями.

Сервис git-subtree(1) фактически является полезной надстройкой, использующей функции git-read-tree(1) и git-write-tree(1). Поэтому ссылки в командах git-subtree(1) add/pull/push:

  git subtree add --prefix=<subdir> <remote> <ref>

могут представлять собой, как имена веток, так и имена тегов удаленного репозитория.

Кроме того, если заранее добавить удаленный репозиторий в конфигурационный файл локального репозитория .git/config, с помошью команды:

bash-4.4$ git remote add build-system ../../remote/build-system.git

где build-system является именем удаленного репозитория ../../remote/build-system.git, то в дальнейшем, при использовании команд git-subtree(1) add/pull/push, мы сможем ссылаться на upstream-репозиторий remote/build-system.git по имени.

На данный момент git-subtree(1) практически не развивается, а лишь поддерживается в актуальном состоянии для текущей степени развития проекта Git.

Однако git-subtree(1) является наиболее популярным и мощным средством работы с поддеревьями.

Проект git-subrepo существует достаточно давно, однако упоминаний о нем незаслуженно мало. Автором git-subrepo является Ingy döt Net.

Если посмотреть на историю комитов master-ветки проекта, то может показаться, что проект остановился в развитии 2 года назад. Однако работы над проектом ведутся и хочется надеяться, что скоро будет выпущена версия 0.4.0.

Важным свойством данного средства является то, что на стороне пользователя нет необходимости устанавливать git-subrepo до тех пор, пока пользователь не решит делать комиты в upstream-репозитории подпроектов. Кроме того, пользователь получает полностью готовое и настроенное дерево исходного кода в момент копирования основного репозитория посредством стандартной команды git-clone(1).