В ходе исследования ноутбука Asus ROG Strix GL702ZC с помощью информационно-диагностической утилиты Read Universal можно обнаружить наличие таблицы EFI System Resource Table в списке системных объектов UEFI. Отметим, что данная таблица была определена в спецификации расширяемого интерфейса еще два года назад и ее появление в ноутбуке GL702ZC можно считать сюрпризом с большой натяжкой, так как ESRT предназначена для описания всех устройств, содержащих firmware. Событие от ASUS (а если учесть, что платформа оснащена Aptio V, то правильнее говорить о заслуге American Megatrends) состоит в низкоуровневой поддержке NVMe-накопителей программным продуктом, каковым и является UEFI. Что ожидать от этой новинки и какие преимущества сулит она пользователям?
Рис 1. Таблица ESRT в списке системных объектов UEFI ноутбука Asus ROG Strix GL702ZC
(скрин-шот утилиты Read Universal)
AMI унифицирует обновление микрокодов NVMe-устройств
Разобраться в ситуации помог пресс-релиз компании American Megatrends, в котором прозвучало заявление о новых подходах в методе обновления микрокодов NVMe-накопителей. Инициатива основана на использовании упомянутой выше таблицы EFI System Resource Table, ранее документированной в спецификации UEFI. Ее содержимое теперь дополняется записями, декларирующими программные особенности установленных NVMe-устройств и процедур Firmware Management Protocol. Последние нужны для обслуживания доступа к физическим носителям встроенного программного обеспечения. Не забыта и эргономика: обновление может быть выполнено в графической оболочке Aptio V UEFI BIOS setup либо при очередной перезагрузке.
Рис 2. Головной экран страницы UEFI-установок ноутбука Asus ROG Strix GL702ZC
Фактор унификации
Если характеризовать инициативу AMI одним словом, то это будет слово «унификация». В силу исторических причин (и mass storage устройства не исключение) процесс обновления UEFI платформы или ее компонентов ASUS, как и многие другие, выполняет проприетарными утилитами, взаимодействующими с проприетарными аппаратными ресурсами. Стоимость такой разработки и ее последующего сопровождения не соответствуют современным требованиям. Сегодня в цене стандартный интерфейс, определенный в UEFI Specification. Рассмотрим два системных объекта, его реализующих: EFI System Resource Table (ESRT) и Firmware Management Protocol (FMP).
EFI System Resource Table
Таблица EFI System Resource Table декларирует список системных ресурсов, каждый из которых располагает встроенным программным обеспечением и допускает его обновление. Проще говоря, это список компонентов, потенциальных кандидатов на «перешивку». Под компонентом здесь может подразумеваться как физически обособленный объект (UEFI BIOS системной платы или PCI ROM периферийного устройства), так и логическая единица (UEFI-драйвер).
Рис 3. Определение ESRT согласно UEFI Specification 2.7
Заголовок таблицы ESRT определяет текущее и максимальное количество записей, а также номер версии.
Рис 4. Формат таблицы ESRT согласно UEFI Specification 2.7
Далее, располагается последовательность записей, каждая из которых декларирует компонент, допускающий обновление.
Рис 5. Формат одной записи в таблице ESRT согласно UEFI Specification 2.7
Рассмотрим свойства обновляемого компонента:
- FwClass содержит идентификатор компонента в виде 128-битного числа EFI_GUID.
- FwType определяет тип компонента: firmware системной платы, firmware периферийного устройства, UEFI-драйвер. Нестандартные компоненты могут использовать вариант Type Unknown.
- FwVersion идентифицирует версию установленного компонента.
- LowestSupportedFwVersion ограничивает минимально допустимый номер версии. Ограничение может быть использовано в целях предотвращения «отката» на устаревшие версии, не обеспечивающие заданный уровень безопасности.
- CapsuleFlags содержит набор флагов, управляющих интерпретацией файлов обновления firmware.
- LastAttemptVersion идентифицирует версию ранее загруженного обновления. Заметим, что версия обновления может не совпадать с версией установленного компонента если имела место ошибка либо процесс перезаписи Flash ROM не завершен.
- LastAttemptStatus отражает результат обновления а также позволяет идентифицировать ошибки, причинами которых могут быть аппаратный сбой, несоответствие версии или формата, ограниченный ресурс аккумуляторной батареи мобильного устройства и т. п.
Firmware Management Protocol
Сервисные подпрограммы, реализованные в составе Firmware Management Protocol обеспечивают получение системной информации, включая атрибуты установленных компонентов встроенного ПО и загруженных обновлений, чтение и перезапись компонентов а также управление версиями. В соответствии с номенклатурой установленных устройств, в системе может присутствовать более одного экземпляра FMP.
Рис 6. Определение FMP согласно UEFI Specification 2.7
Управляющий блок Firmware Management Protocol содержит указатели на точки входа в процедуры, реализующие функциональность протокола.
Рис 7. Формат управляющего блока FMP согласно UEFI Specification 2.7
Рассмотрим некоторые API-функции, доступные приложениям:
- GetImageInfo возвращает информацию о текущем установленном firmware, функция может быть полезной не только для утилит обновления firmware, но и для получения данных о платформе и периферийных устройствах.
- GetImage позволяет прочитать двоичный образ установленного firmware, может применяться для создания резервной копии перед обновлением.
- SetImage обновляет firmware, эта функция осуществляет физическую перезапись содержимого Flash ROM, после ряда предварительных проверок.
- CheckImage позволяет проверить соответствие заданного двоичного файла обновления заданному устройству без выполнения перезаписи.
Выводы
Периферийное устройство, снабженное встроенным ПО, определяет низкоуровневые методы его обновления. Такие методы всегда специфичны для данного класса устройств, а в большинстве случаев, имеют особенности реализации, характерные для конкретного производителя и даже модели. Не является исключением команда Firmware Image Download, определенная в архитектуре NVMe, стандартные параметры которой управляют только адресацией и длиной загружаемого блока, оставляя детали реализации в статусе Implementation-Specific.
Рис 8. Описание параметров команды Firmware Image Download согласно NVMe Specification 1.3
При наличии в устройстве Option ROM, в нем могут быть размещены подпрограммы, реализующие поддержку нестандартных особенностей архитектуры, либо новых классов оборудования, не обслуживаемых UEFI платформы, но при этом обеспечивающие унифицированный интерфейс согласно Firmware Management Protocol. При старте платформы, UEFI детектирует такие устройства и составляет их список, каковым является таблица EFI System Resource Table.
В идеале, приложение, управляющее обновлением встроенного ПО, может реализовать свою функциональность, взаимодействуя исключительно с унифицированными объектами ESRT и FMP и не обращаясь к Implementation-Specific аппаратным ресурсам. Действует классический принцип инкапсуляции.
Вместо послесловия
Словосочетание «обновление прошивки» сегодня на слуху не только технических специалистов, но и рядовых пользователей. Законы рынка заставляют производителей сокращать сроки разработки и верификации, в результате, приобретая очередную новинку, потребитель нередко получает инженерный релиз продукта. Тестирование, устранение ошибок и расширение функциональности происходит уже во время эксплуатации. Впрочем, это обстоятельство никогда не смущало энтузиастов: редактирование встроенного программного обеспечения системных плат и периферийных устройств давно стало объектом «спортивного интереса», а значит, упрощение обновления firmware NVMe-накопителей позитивно как с технической, так и с маркетинговой точек зрения.
- Войдите или зарегистрируйтесь, чтобы оставлять комментарии