Разработка BIOS и микропрограммного обеспечения

Оборудование загружается, а продукт — нет

Разработка прошивки начинается после того, как плата сможет включиться

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

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

Разработка индивидуальной платы формата Mini-ITX → Технические характеристики платформы →

Область применения прошивки на уровне продукта

Что можно настроить в BIOS и микропрограмме UEFI

Настройки по умолчанию

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

Настройка доступа

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

Политика загрузки

NVMe, SATA, USB, PXE или поддерживаемые параметры приоритета загрузки по HTTP, порядок резервной загрузки, задержка загрузки и условия восстановления записи.

Энергетическая политика

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

Идентичность платформы

Производитель, название продукта, серийные данные, идентификатор платы, поля SMBIOS, данные об активах и утвержденные изменения логотипа при загрузке.

Безопасность и обновления

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

Требования к режимам питания

Точно определите, что происходит при загрузке, выключении и переходе на питание от сети

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

Платформы для ввода данных →

Контроль на уровне совета директоров

Прошивка может управлять только теми функциями, которые доступны на плате

Встроенные системы формата Mini-ITX часто включают элементы управления, которые отсутствуют в BIOS настольных компьютеров. Их поведение зависит от установленного модуля Super I/O, встроенного контроллера, расширителя GPIO, приемопередатчика, сторожевого таймера, контроллера вентилятора или чипсета.

Несколько последовательных портов → Платформа GPIO и CAN →

Данные, передаваемые из прошивки в ОС

ACPI и SMBIOS должны содержать информацию об установленном оборудовании

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

Дозагрузочное доверие

Для безопасной загрузки необходимо указать владельца ключа и путь обновления

Функция «Secure Boot» в производственной среде — это не просто настройка, которую можно включить или отключить. В рамках проекта необходимо определить, кто контролирует ключ платформы, какие ключи обмена ключами считаются доверенными, какие данные попадают в базу данных допустимых подписей, как отозванные образы попадают в dbx, и как обеспечить возможность восстановления авторизованных обновлений полей.

Согласно действующим требованиям UEFI, формат ключа платформы Secure Boot должен быть не ниже RSA-2048, а для хэшей образов UEFI, хранящихся в dbx, требуется использование как минимум алгоритма SHA-256. Это минимальные криптографические требования, а не полная политика безопасности продукта.

Права собственности PK

Определите, кто — производитель оригинального оборудования (OEM), заказчик или другой уполномоченный владелец — контролирует ключ платформы, используемый для установления права собственности на Secure Boot.

KEK, db и dbx

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

TPM 2.0

Обеспечить доступ к платформе TPM и настроить её, если это поддерживается, с учетом политики ответственности и развертывания, определённой конечной системой.

Восстановление

Обеспечить наличие разрешённого пути восстановления на случай сбоев при обновлении или изменениях ключей, не нарушая при этом предусмотренную политику доверия.

Системы сетевой безопасности →

Управление производственной прошивкой

Опубликовать бинарный файл вместе с его спецификацией, настройками по умолчанию и журналом изменений

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

1. Бинарная идентичность Запишите версию прошивки, точную версию платы, размер файла, хеш SHA-256 и дату выпуска.
2. Стандартные настройки производства Зафиксируйте значения настроек, переданные при отгрузке, отдельно от инженерных настроек отладки и изменений, внесённых местными техническими специалистами.
3. Изменить запись Определите измененные функции, затронутое оборудование или версии ОС, известные ограничения и необходимые регрессионные тесты.
4. Обновление и восстановление Определите утвержденный метод переключения, политику версий, меры предосторожности на случай потери питания, правила отката и маршрут восстановления.

Эталонные технические характеристики

Интерфейсы прошивки и справочные спецификации

UEFI 2.11

Текущая спецификация UEFI, касающаяся стандартизированной среды микропрограммы, предшествующей запуску ОС, служб загрузки, служб выполнения, переменных и протоколов.

ACPI 6.6

Текущая спецификация ACPI, касающаяся настройки устройств под управлением ОС, описания платформы, управления питанием и системных событий.

SMBIOS 3.9.0

Спецификация DMTF для стандартизированной управленческой информации, предоставляемой системной микропрограммой о платформе и установленном оборудовании.

TCG TPM 2.0 версии 185

Март 2026 г. Спецификация библиотеки TPM 2.0, определяющая архитектуру, структуры и команды, используемые в реализациях TPM 2.0.

Сертификаты и стандарты качества →

Контроль выпуска прошивки

Убедитесь, что вы используете именно ту версию прошивки, которую планируете поставлять

Разработка прошивки завершается созданием готового двоичного файла и определением производственной конфигурации. Затем в ходе инженерной валидации этот конкретный релиз запускается на целевой плате с заданным образом ОС, периферийными устройствами, сценариями перехода в различные режимы энергопотребления, настройками безопасности, методом обновления и алгоритмом восстановления.

Инженерная валидация → Все инженерные услуги →

ЧАСТО ЗАДАВАЕМЫЕ ВОПРОСЫ

Вопросы по разработке BIOS и прошивки