Intel® Whitley UEFI/EDK2: Firmware Porting and Board Bring-Up (Practical Guide, 2026)

Платформа Intel® Whitley – одна из последних серверных платформ Xeon, где ещё можно было осмысленно работать с firmware через EDK2. Здесь сформировалась зрелая архитектура UEFI (PEI/DXE, UBA), понятная и пригодная для реального портирования плат. Для многих инженеров Whitley стала точкой входа в серверный BIOS – балансом между доступностью кода и зависимостью от закрытых компонентов вроде FSP.

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

В результате этого процесса код, связанный с Whitley, начал постепенно исчезать из основного дерева edk2-platforms. Это отражает общую тенденцию: смещение фокуса в сторону более новых платформ и одновременное сокращение поддержки решений, зависящих от устаревших или закрытых бинарных компонентов. Несмотря на это, накопленный опыт и архитектурные подходы Whitley остаются крайне ценными для понимания серверного firmware.

[matrix] Element Call

В предыдущей статье мы рассмотрели установку домашнего сервера Matrix Synapse, а также сервисов, которые обеспечивают текстовые сообщения, голосовые сообщения и управление пользователями. Однако этого не достаточно для организации полноценного home‑сервера.

Для обеспечения видео и аудио звонков необходимо инсталлировать еще два сервера:

• MatrixRTC Authorization Service
• Matrix LiveKit Server

[matrix] на собственном сервере

В данной статье рассматривается процесс установки [matrix] на собственном сервере так, чтобы имелась возможность обмениваться текстовыми и голосовыми сообщениями. Организации аудио и видео звонков будет посвящена отдельная статья.

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

Мы прошли этот путь и по горячим следам составили полную инструкцию для тех, кто хочет установить [matrix] на собственном сервере.

UEFI PXE Boot в виртуальном окружении

Установка PXE‑сервера для тестирования edk2/OvmfPkg в виртуальном окружении может оказаться не совсем тривиальной задачей. Например мы столкнулись с тем что TFTP‑сервер, работающий на одной виртуальной машине, оказался недоступным для других виртуальных машин. Решение данной проблемы находится в конфигурации брандмауэра. В Linux netfilter есть вспомогательные модули nf_conntrack_tftp и nf_nat_tftp, которые после загрузки позволяют отслеживать обратные TFTP‑соединения. Однако и здесь настройка может потребовать дополнительных затрат времени.

Допустим мы работаем на персональной машине в сети с адресом 192.168.9.0/24, где установлены Qemu, Libvirt, Virtual Machine Manager и нам необходимо создать виртуальную сеть 192.168.49.0/24, в которой настроен PXE‑сервер для загрузки виртуальных машин подключаемых к этой сети.

REG.RU и Let's Encrypt

Множество людей покупают доменные имена у регистраторов и создают собственные сайты. Разумеется, им необходимы SSL‑сертификаты. Однако покупать доверенные сертификаты могут не все и, зачастую, используют бесплатные Let's Encrypt SSL‑сертификаты, время жизни которых составляет 90 суток.

Для автоматического обновления SSL‑сертификатов Let's Encrypt обычно используется API управления DNS‑зоной, который предоставляет регистратор доменных имен.

Рассмотрим один из возможных способов автоматического обновления сертификатов на примере регистратора REG.RU и его API управления DNS‑зонами.