Спецификация протокола обновления встроенного ПО компонента (CFU)

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

Содержимое

• 1 Введение
  • 1.1 Глоссарий
  • Область 1.2
    • 1.2.1 Цели
    • 1.2.2 Цели, не входящие в задачу
• 2 Поддерживаемая архитектура оборудования
• Предварительные требования для протокола 3
• Обзор протокола CFU 4
  • 4.1. Последовательность команд программирования обновлений встроенного ПО
    • 4.1.1. Состояние: уведомление о инициализации узла
    • 4.1.2 Состояние: уведомление OFFER_INFO_START_OFFER_LIST
    • 4.1.3 Состояние: отправка команды FIRMWARE_UPDATE_OFFER
    • 4.1.4 Состояние: отправка встроенного ПО
    • 4.1.5 Состояние принятия решений: Есть больше предложений
    • 4.1.6 Состояние: уведомление о окончании списка предложений OFFER_INFO_END_OFFER_LIST
    • 4.1.7 Состояние принятия решений: список предложений воспроизведения
    • 4.1.8 Состояние: устройство занято
• Формат пакета протокола CFU 5
  • 5.1 GET_FIRMWARE_VERSION
    • Команда 5.1.1
    • Ответ 5.1.2
      • 5.1.2.1 Заголовок
      • Версия и свойства компонента 5.1.2.2
    • Сопоставление 5.1.3 с HID
  • 5.2 FIRMWARE_UPDATE_OFFER
    • 5.2.1 Команда
      • Сведения о компоненте 5.2.1.1
      • Версия встроенного ПО 5.2.1.2
      • 5.2.1.3 Специфично для поставщика
      • Версия 5.2.1.4 Misc и Protocol
    • Ответ 5.2.2
      • Токен 5.2.2.1
      • 5.2.2.2 Зарезервирован (B7 - B4)
      • 5.2.2.3 Причина отклонения (RR)
      • Состояние 5.2.2.4
    • Сопоставление 5.2.3 с протоколом HID
  • 5.3 FIRMWARE_UPDATE_OFFER — Информация
    • 5.3.1 Команда
      • Компонент 5.3.1.1
      • 5.3.1.2 Зарезервировано B7 — B4
      • 5.3.1.3 Зарезервировано B11 — B8
      • 5.3.1.4 Резерв B15–B12
    • Ответ 5.3.2
      • Токен 5.3.2.1
      • 5.3.2.2 Зарезервировано B7 — B4
      • 5.3.2.3 Причина отказа (RR)
      • Состояние 5.3.2.4
  • 5.4 FIRMWARE_UPDATE_OFFER — расширено
    • 5.4.1 Команда
      • Компонент 5.4.1.1
      • 5.4.1.2 Зарезервировано B7 — B4
      • 5.4.1.3 Зарезервировано B11 — B8
      • 5.4.1.4 Зарезервировано B15 — B12
    • Ответ 5.4.2
      • Токен 5.4.2.1
      • 5.4.2.2 Зарезервировано B7 — B4
      • 5.4.2.3 Причина отказа
      • Состояние 5.4.2.4
  • 5.5 FIRMWARE_UPDATE_CONTENT
    • Команда 5.5.1
      • 5.5.1.1 Заголовок (B7 - B0)
      • Данные 5.5.1.2
    • Ответ 5.5.2
      • 5.5.2.1 Порядковый номер
      • Состояние 5.5.2.2
      • 5.5.2.3 Зарезервировано B8 — B11
      • 5.5.2.4 Зарезервировано B12 — B15
• 6 приложение 1. Пример последовательности команд программирования обновлений встроенного ПО
  • 6.1 Пример 1
  • 6.2 Пример 2

Таблицы

Таблица 5.1-1 GET_FIRMWARE_VERSION структура ответа

Таблица 5.1-2 Ответ GET_FIRMWARE_VERSION — макет заголовка

Таблица 5.1-3 ответ GET_FIRMWARE_VERSION — биты заголовка

Таблица 5.1-4 Ответ GET_FIRMWARE_VERSION — структура версий компонентов и свойств

Таблица 5.1-5 GET_FIRMWARE_VERSION Ответ — версия компонентов и биты свойств

Таблица 5.2-1 FIRMWARE_UPDATE_OFFER — структура команды

Таблица 5.2-2 — Команда FIRMWARE_UPDATE_OFFER - структура информации о компоненте

Таблица 5.2-3 Команда FIRMWARE_UPDATE_OFFER — биты информации о компонентах

Таблица 5.2-4 Команда FIRMWARE_UPDATE_OFFER — Структура версии встроенного ПО

Таблица 5.2-5 Команда FIRMWARE_UPDATE_OFFER — биты версии прошивки

Таблица 5.2-6 FIRMWARE_UPDATE_OFFER — макет, специфичный для поставщика

Таблица 5.2-7 FIRMWARE_UPDATE_OFFER команда — Разное и Версия протокола

Таблица 5.2-8 FIRMWARE_UPDATE_OFFER Структура токена ответа

Таблица 5.2-9 FIRMWARE_UPDATE_OFFER Ответ — структура токена

Таблица 5.2-10 FIRMWARE_UPDATE_OFFER Ответ — бит токенов

Таблица 5.2-11 FIRMWARE_UPDATE_OFFER — структура ответа для причины отказа

Таблица 5.2-12 Ответ FIRMWARE_UPDATE_OFFER — Биты Причины Отклонения

Таблица 5.2-13 Значения кода ответа RR для FIRMWARE_UPDATE_OFFER

Таблица 5.2-14 Статус ответа на FIRMWARE_UPDATE_OFFER

Таблица 5.2-15 — Биты состояния ответа на FIRMWARE_UPDATE_OFFER

Таблица 5.2-16 FIRMWARE_UPDATE_OFFER значения состояния ответа

Таблица 5.3-1 FIRMWARE_UPDATE_OFFER — структура информационной команды

Таблица 5.3-2 FIRMWARE_UPDATE_OFFER — информационная команда — структура компонента

Таблица 5.3-3 FIRMWARE_UPDATE_OFFER — информационная команда — компонентные биты

Таблица 5.3-4 FIRMWARE_UPDATE_OFFER — Информационная команда — значения информационного кода

Таблица 5.3-5 FIRMWARE_UPDATE_OFFER — формат информационного ответа

Таблица 5.3-6 FIRMWARE_UPDATE_OFFER — макет маркера ответа на информационный пакет

Таблица 5.3-7 FIRMWARE_UPDATE_OFFER — информационный ответ — биты токенов

Таблица 5.3-8 FIRMWARE_UPDATE_OFFER — информационный ответ — макет кода RR

Таблица 5.3-9 FIRMWARE_UPDATE_OFFER — Ответ на информационное предложение — биты кода RR

Таблица 5.3-10 FIRMWARE_UPDATE_OFFER - Информационный ответ - значения кода RR

Таблица 5.3-11 FIRMWARE_UPDATE_OFFER - структура статуса ответа на предложение информации

Таблица 5.3-12 FIRMWARE_UPDATE_OFFER — сведения о предложении — биты состояния ответа

Таблица 5.4-1 FIRMWARE_UPDATE_OFFER — расширенный макет команд

Таблица 5.4-2 FIRMWARE_UPDATE_OFFER — расширенный пакет команд — команда — макет компонента

Таблица 5.4-3 FIRMWARE_UPDATE_OFFER — расширенная команда — биты компонентов

Таблица 5.4-4 FIRMWARE_UPDATE_OFFER — расширенная команда — значения кода команд

Таблица 5.4-5 FIRMWARE_UPDATE_OFFER — структура расширенного ответа пакета команд

Таблица 5.4-6 FIRMWARE_UPDATE_OFFER. Ответ на пакет команды предложения — макет токена

Таблица 5.4-7 FIRMWARE_UPDATE_OFFER - Ответ на команду предложения — биты токенов

Таблица 5.4-8 FIRMWARE_UPDATE_OFFER - Структура ответа на пакет информации о предложении

Таблица 5.4-9 FIRMWARE_UPDATE_OFFER - Ответ на команду предложения - код RR

Таблица 5.4-10 FIRMWARE_UPDATE_OFFER. Пакет команд предложения — значения кода RR

Таблица 5.4-11 FIRMWARE_UPDATE_OFFER — макет состояния ответа пакета команды Offer

Таблица 5.4-12 FIRMWARE_UPDATE_OFFER - Код ответа на пакет команды предложения RR

Таблица 5.5-1 Командный макет FIRMWARE_UPDATE_CONTENT

Таблица 5.5-2 FIRMWARE_UPDATE_CONTENT формат заголовка команды

Таблица 5.5-3 биты заголовка FIRMWARE_UPDATE_CONTENT

Таблица 5.5-4 FIRMWARE_UPDATE_OFFER — Пакет команды предложения — значения флагов

Таблица 5.5-5 FIRMWARE_UPDATE_CONTENT структура данных команды

Таблица 5.5-6 FIRMWARE_UPDATE_CONTENT Биты данных команд

Таблица 5.5-7 FIRMWARE_UPDATE_CONTENT макет ответа команд

Таблица 5.5-8 FIRMWARE_UPDATE_CONTENT ответ — порядковый номер

Таблица 5.5-9 FIRMWARE_UPDATE_CONTENT — команда — биты ответа

Таблица 5.5-10 Структура состояния ответа FIRMWARE_UPDATE_CONTENT

Таблица 5.5-11 FIRMWARE_UPDATE_OFFER — ответ — биты состояния

Таблица 5.5-12 FIRMWARE_UPDATE_OFFER- Ответ — значения кода состояния

1 Введение

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

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

Ниже приведены некоторые функции протокола.

• Протокол основан на HID, который является вездесущим и имеет встроенную поддержку в Windows через различные шины соединения, такие как USB и I²C. Таким образом, одно и то же решение программного обеспечения (драйвера) можно использовать для обновления встроенного ПО для всех компонентов.

  Замечание

  Так как спецификация основана на пакетах, просто адаптировать ее к сценариям, отличным от HID.

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

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

  Замечание

  Процесс передачи встроенного ПО подкомпоненту находится вне области этой спецификации.

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

1.1. Глоссарий

Область 1.2

1.2.1 Цели

• Решение, не зависящее от шины, необходимо для избежания создания новых протоколов для каждого типа шины. HID используется повсеместно и удовлетворяет эту потребность.

• Возможность поддерживать обновление встроенного ПО для устройства с несколькими компонентами, где один компонент выступает в качестве основного компонента, а другие — подкомпонентами, подключенными к основному компоненту. Для каждого компонента требуется собственное встроенное ПО с нетривиальными зависимостями между собой.

• Общая модель драйвера для скачивания образа встроенного ПО в компонент. Затем компонент имеет подкомпонентные определенные алгоритмы для переадресации в подкомпоненты. Вложенные элементы также могут выполнять проверки допустимости встроенного ПО и передавать результаты обратно в основной компонент.

• Возможность поддерживать обновление встроенного ПО во время выполнения операции устройства.

• Возможность обновления и отката встроенного ПО в устройствах на этапе эксплуатации с помощью авторизованных средств и обновления находящихся на рынке устройств с помощью Windows Update.

• Гибкость поддерживать встроенное ПО на стадии разработки или при выпуске на рынок.

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

1.2.2 Предметы, не являющиеся целями

• Определите внутренний формат образа встроенного ПО: для хоста образ встроенного ПО является набором записей адресов и данных.

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

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

2 Поддерживаемая архитектура оборудования

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

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

На компьютере может быть много разных устройств (где устройство может содержать один или несколько компонентов). В контексте этого протокола обмен данными с каждым устройством является независимым. Каждое устройство имеет соответствующий экземпляр хоста.

Предварительные требования для протокола 3

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

• Использование атомарного образа

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

• Обновление встроенного ПО не должно прерывать операцию устройства

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

• Проверка подлинности и целостность

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

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

• Конфиденциальность

  Необязательно. Сегмент встроенного ПО может быть зашифрован. Методы шифрования и расшифровки выходят за рамки этой спецификации. Эта спецификация обрабатывает полезные данные встроенного ПО как поток данных независимо от того, зашифрован ли он.

• Защита отката

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

Обзор протокола CFU 4

Протокол CFU — это набор команд и ответов, необходимых для отправки новых образов встроенного ПО с узла на устройство, для которого предназначено встроенное ПО.

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

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

4.1. Последовательность команд программирования обновлений встроенного ПО

Ниже приведена последовательность команд CFU для обновления образа встроенного ПО.

4.1.1. Состояние: уведомление о инициализации хоста

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

4.1.2 Состояние: OFFER_INFO_START_OFFER_LIST уведомление

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

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

4.1.3 Состояние: отправка команды FIRMWARE_UPDATE_OFFER

Хост отправляет предложение основному компоненту (или его подкомпоненту), чтобы проверить, хочет ли компонент принять или отклонить прошивку. Предложение содержит все необходимые метаданные об образе встроенного ПО, чтобы текущее встроенное ПО на компоненте могло решить, принять предложение, отложить, пропустить или отклонить его.

Предложение может касаться основного компонента или подкомпонента. Если компонент может принять предложение, он готовится к получению встроенного ПО. Это может включать подготовку банка памяти для получения входящего образа встроенного ПО. Компонент может не принять предложение, так как, например, у него может уже быть более новая (или та же) версия встроенного ПО, которую основной контроллер намерен отправить. Дополнительные причины см. в примерах, описанных в приложении 1. Пример последовательности команд программирования обновления встроенного ПО.

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

Хост посылает команду FIRMWARE_UPDATE_OFFER, чтобы уведомить главный компонент о образе встроенного ПО, который хост намерен отправить.

Если компонент принимает предложение, он тем самым принимает его и переходит в состояние FIRMWARE_UPDATE_OFFER_ACCEPT.

Если встроенное ПО устройства занято, и основной компонент не может принять это или следующее предложение в настоящее время, он отправляет занятую реакцию с состоянием FIRMWARE_UPDATE_OFFER_BUSY.

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

Если текущее встроенное ПО не заинтересовано в предложении (например, если это старая версия), то оно отвечает со статусом FIRMWARE_UPDATE_OFFER_REJECT, указывая причину отказа. Этот статус не указывает, что хост не может повторно отправить это предложение в будущем. Хост обычно отправляет следующее предложение каждый раз, когда он инициализирует или повторно отправляет список предложений на устройство (см. состояние: OFFER_INFO_START_OFFER_LIST уведомления).

4.1.4 Состояние: отправка ПО

В этом состоянии хост начинает отправлять образ встроенного ПО в основной компонент, который ранее принял предложение.

Поскольку содержимое образа встроенного ПО скорее всего превышает ограничения полезных данных одной команды, хост разбивает образы встроенного ПО на пакеты. Хост отправляет каждый пакет последовательно в отдельной команде FIRMWARE_UPDATE CONTENT. Основной компонент должен создать пакет ответа для каждой команды.

Каждая команда FIRMWARE_UPDATE CONTENT описывает адрес смещения, включающий частичное содержимое прошивки. Компонент использует смещение для определения адреса, по которому должен храниться частичный полезный нагруз встроенного ПО. Устройство записывает содержимое в подходящее место и подтверждает выполнение команды, отправляя ответ.

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

Для последнего пакета хост устанавливает флаг обновления прошивки FIRMWARE_UPDATE_FLAG_LAST_BLOCK.

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

• Проверка CRC для подтверждения целостности всего образа встроенного ПО.

• Если проверка CRC выполнена успешно, необязательная проверка подписи входящего изображения.

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

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

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

Если шаги проверки завершаются сбоем, встроенное ПО не должно настраивать swap на следующий сброс и должно указать ответ о сбое ведущему компьютеру.

4.1.5 Состояние принятия решений: Есть ли еще предложения

В этом состоянии хост определяет, есть ли больше предложений для отправки на устройство.

4.1.6 Состояние: OFFER_INFO_END_OFFER_LIST Уведомление

Это состояние достигается, когда хост отправил все предложения основному компоненту текущего встроенного ПО устройства. Хост отправляет команду OFFER_INFO_END_OFFER_LIST, чтобы означать, что он отправил все предложения компоненту.

Устройство должно завершить эту команду успешно.

4.1.7 Состояние принятия решений: список предложений воспроизведения

Хост определяет, нужно ли повторно отправлять все предложения. Это может произойти, если ранее основной компонент пропустил некоторые предложения и принял некоторые предложения. Хост должен повторно воспроизвести список предложений.

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

4.1.8 Состояние: устройство занято

Это состояние означает, что устройство вернуло занятую реакцию на предложение.

Узел отправляет команду OFFER_NOTIFY_ON_READY, на которую устройство не отвечает с подтверждением, пока оно не будет свободно.

Формат пакета протокола CFU 5

Протокол CFU реализуется как набор команд и ответов. Протокол является последовательным в природе. Для каждой команды, отправляемой узлом компоненту, компонент должен реагировать (если в этом спецификации явно не указано в противном случае). Хост не отправляет следующую команду, пока не будет получен корректный ответ для предыдущей команды.

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

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

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

5.1 GET_FIRMWARE_VERSION

Возвращает текущие версии встроенного ПО основного компонента (и его подкомпоненты). Команда не имеет аргументов.

Команда 5.1.1

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

Ответ 5.1.2

Компонент возвращает версию прошивки основного компонента и подкомпонентов. Размер ответа составляет 60 байт, позволяя получать сведения о версии до семи компонентов (один первичный и до шести вложенных компонентов).

Таблица 5.1-1 Структура ответа GET_FIRMWARE_VERSION

5.1.2.1 Заголовок

Таблица 5.1-2 Ответ GET_FIRMWARE_VERSION — Макет заголовка

Заголовок ответа содержит следующие сведения.

Таблица 5.1-3 — ответ GET_FIRMWARE_VERSION — биты заголовка

Версия и свойства компонента 5.1.2.2

Для каждого компонента используются два DWORD для описания свойств компонента до 7 компонентов. Если число компонентов в заголовке меньше 7, неиспользуемый DWORDS в конце ответа должен иметь значение 0.

Таблица 5.1-4 — ответ GET_FIRMWARE_VERSION: структура версий компонентов и свойств

Каждая информация о конкретном компоненте описана в двух DWORD, как показано ниже.

Таблица 5.1-5 GET_FIRMWARE_VERSION ответ — версия компонентов и биты свойств

Сопоставление с HID 5.1.3

Это реализуется в виде запроса функции HID Get с размером ответа 60 байт, а также идентификатором отчета. Длина отчета о функциях содержит весь ответ GET_FIRMWARE_VERSION. Нет данных, связанных с запросом на получение функции от хоста.

5.2 ПРЕДЛОЖЕНИЕ_ОБНОВЛЕНИЯ_FIRMWARE

Определяет, принимает ли первичный компонент микропрограмму или отклоняет ее.

Команда 5.2.1

Хост отправляет эту команду компоненту, чтобы определить, принимает он или отклоняет прошивку. Хост должен отправить предложение, а компонент должен принять его, прежде чем хост сможет отправить прошивку.

Пакет команд FIRMWARE_UPDATE_OFFER определяется следующим образом.

Таблица 5.2-1 Структура команды FIRMWARE_UPDATE_OFFER

Сведения о компоненте 5.2.1.1

Таблица 5.2-2 Команда FIRMWARE_UPDATE_OFFER — структура информации о компонентах

Биты байта сведений о компонентах описаны в этой таблице.

Таблица 5.2-3 Команда FIRMWARE_UPDATE_OFFER — биты информации о компонентах

Версия встроенного ПО 5.2.1.2

Эти четыре байта представляют 32-разрядную версию встроенного ПО. Формат версии встроенного ПО не является обязательным для данной спецификации. Рекомендуется выполнить следующие действия.

Команда 5.2-4 FIRMWARE_UPDATE_OFFER — формат версии встроенного ПО

Формат версии встроенного ПО не требуется в соответствии с этой спецификацией, однако ниже приведены рекомендации.

Таблица 5.2-5 Команда FIRMWARE_UPDATE_OFFER — биты версий встроенного ПО

5.2.1.3 Специфичный для поставщика

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

Версия 5.2.1.4 Misc и Protocol

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

Команда table 5.2-6 FIRMWARE_UPDATE_OFFER — конкретный макет поставщика

Биты байта, зависящего от поставщика, описаны в этой таблице.

Таблица 5.2-7 Команда FIRMWARE_UPDATE_OFFER — Misc. и Protocol version

Ответ 5.2.2

Пакет ответа FIRMWARE_UPDATE_OFFER определяется следующим образом.

Таблица 5.2-8 FIRMWARE_UPDATE_OFFER Структура токена ответа

Токен 5.2.2.1

Таблица 5.2-9 — ответ FIRMWARE_UPDATE_OFFER — макет токена

Ответ FIRMWARE_UPDATE_OFFER — структура токена.

Биты байта токена описаны в этой таблице.

Таблица 5.2-10 ответ FIRMWARE_UPDATE_OFFER — биты токенов

5.2.2.2 Зарезервирован (B7 - B4)

Зарезервировано. Не используйте.

5.2.2.3 Причина отказа (RR)

Таблица 5.2-11 FIRMWARE_UPDATE_OFFER — макет причины отказа

Таблица 5.2-12 Ответ на обновление прошивки — биты причин отказа

Биты байта "Отклонить причину" описаны в этой таблице.

Таблица 5.2-13 значения кода ответа RR для FIRMWARE_UPDATE_OFFER

Возможные значения байта кода RR описаны в этой таблице.

Состояние 5.2.2.4

Таблица 5.2-14 FIRMWARE_UPDATE_OFFER макет состояния ответа

Биты байта состояния описаны в этой таблице.

Таблица 5.2-15 Ответ на FIRMWARE_UPDATE_OFFER — биты состояния

Возможные значения байтов состояния описаны в этой таблице.

Таблица 5.2-16 FIRMWARE_UPDATE_OFFER значения состояния ответа

Сопоставление 5.2.3 с протоколом HID

Сообщение отправляется компоненту механизмом выходного отчета HID с использованием выделенного идентификатора отчета HID, предназначенного для обновления встроенного ПО. Утилита HID TLC для использования, как описано в приложении.

5.3 Обновление прошивки FIRMWARE_UPDATE_OFFER — информация

Если идентификатор компонента в байтах сведений о компонентах (см. сведения о компонентах) имеет значение 0xFF, то биты (15 байт) переопределяются, чтобы указать только сведения о предложении, от узла к компоненту. Этот механизм обеспечивает расширяемость и возможность для Хоста предоставить конкретную информацию устройству, такую как список начальных предложений, список конечных предложений, запуск всей транзакции. Пакеты сведений о предложении всегда принимаются компонентом.

Команда 5.3.1

Пакет команд FIRMWARE_UPDATE_OFFER -Information определяется следующим образом:

Таблица 5.3-1 FIRMWARE_UPDATE_OFFER — макет информационной команды

Компонент 5.3.1.1

Таблица 5.3-2 FIRMWARE_UPDATE_OFFER — информационная команда — структура компонента

Биты байта компонента описаны в этой таблице.

Таблица 5.3-3 FIRMWARE_UPDATE_OFFER — информационная команда — биты компонентов

Таблица 5.3-4 FIRMWARE_UPDATE_OFFER — Информационная команда — Значения кода информации

5.3.1.2 Зарезервировано B7 — B4

Зарезервировано. Не используйте.

5.3.1.3 Зарезервировано B11 — B8

Зарезервировано. Не используйте.

5.3.1.4 Зарезервировано B15 — B12

Зарезервировано. Не используйте.

Ответ 5.3.2

Пакет ответа FIRMWARE_UPDATE_OFFER - ответ со сведениями о предложении определяется следующим образом.

Таблица 5.3-5 FIRMWARE_UPDATE_OFFER — макет ответа информации

Токен 5.3.2.1

Таблица 5.3-6 FIRMWARE_UPDATE_OFFER— структура маркера ответа на информационные пакеты

Биты байта токена описаны в этой таблице.

Таблица 5.3-7 FIRMWARE_UPDATE_OFFER — информационный ответ — биты токенов

5.3.2.2 Зарезервировано B7 — B4

Зарезервировано. Не используйте.

5.3.2.3 Причина отклонения (RR)

Таблица 5.3-8 FIRMWARE_UPDATE_OFFER — информационный ответ — структура кода RR

Биты байта "Отклонить причину" описаны в этой таблице.

Таблица 5.3-9 FIRMWARE_UPDATE_OFFER - Ответ на информацию о предложении — биты кода RR

Возможные значения байта кода RR описаны в этой таблице.

Таблица 5.3-10 FIRMWARE_UPDATE_OFFER - Информационный отклик — значения кода RR

Состояние 5.3.2.4

Таблица 5.3-11 FIRMWARE_UPDATE_OFFER — структура статуса ответа на предложение

Биты байта состояния описаны в этой таблице.

Таблица 5.3-12 FIRMWARE_UPDATE_OFFER — информация о предложении — биты статуса ответа

5.4 FIRMWARE_UPDATE_OFFER — расширенный

Если идентификатор компонента в байтах сведений о компонентах имеет значение 0xFE, то биты (15 байт) переопределяются, чтобы указать команду предложения от узла до встроенного ПО устройства. Этот механизм позволяет расширять функциональность и предоставляет хосту способ передачи устройству определенной информации. Пакеты команд предложения возвращаются, когда компонент готов к реагированию.

Команда 5.4.1

Если для идентификатора компонента в байтах сведений о компонентах задано значение 0xFE, четыре идентификатора DWORD переопределяются следующим образом:

Таблица 5.4-1 FIRMWARE_UPDATE_OFFER — расширенный макет команд

Компонент 5.4.1.1

Таблица 5.4-2 FIRMWARE_UPDATE_OFFER — расширенный командный пакет — команда — структура компонента

Биты байта компонента описаны в этой таблице.

Таблица 5.4-3 FIRMWARE_UPDATE_OFFER — расширенная команда — биты компонентов

Таблица 5.4-4 FIRMWARE_UPDATE_OFFER — расширенная команда — значения кода команд

5.4.1.2 Зарезервировано B7 — B4

Зарезервировано. Не используйте.

5.4.1.3 Зарезервировано B11 — B8

Зарезервировано. Не используйте.

5.4.1.4 Зарезервировано B15 — B12

Зарезервировано. Не используйте.

Ответ 5.4.2

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

Таблица 5.4-5 FIRMWARE_UPDATE_OFFER — расширенный формат ответа на пакет команд

Токен 5.4.2.1

Таблица 5.4-6 FIRMWARE_UPDATE_OFFER. Ответ на пакет команды предложения — структура токена

Биты байта токена описаны в этой таблице.

Таблица 5.4-7 FIRMWARE_UPDATE_OFFER — Ответ на команду предложения — биты токенов

5.4.2.2 Зарезервировано B7 — B4

Зарезервировано. Не используйте.

5.4.2.3 Причина отклонения

Таблица 5.4-8 FIRMWARE_UPDATE_OFFER - Описание ответа на пакет предложения RR

Биты байта "Отклонить причину" описаны в этой таблице.

Таблица 5.4-9 FIRMWARE_UPDATE_OFFER. Ответ команды предложения — код RR

Возможные значения байта кода RR описаны в этой таблице.

Таблица 5.4-10 FIRMWARE_UPDATE_OFFER. Пакет команд предложения — значения кода RR

Состояние 5.4.2.4

Таблица 5.4-11 FIRMWARE_UPDATE_OFFER — структура статуса ответа на пакет команды предложения

Биты байта состояния описаны в этой таблице.

Таблица 5.4-12 FIRMWARE_UPDATE_OFFER - Код RR на ответ команды предложений на обновление прошивки

5.5 FIRMWARE_UPDATE_CONTENT

Хост отправляет эту команду прошивке устройства, чтобы передать содержимое прошивки (то есть образ прошивки). Не предполагается, что весь файл изображения поместится в одну команду. Хост должен разбить изображение на меньшие блоки, и каждая команда отправляет один блок изображения за раз.

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

Когда основной компонент получает последний блок, компонент проверяет весь образ встроенного ПО (проверка CRC, проверка подписи). На основании результатов этих проверок возвращается соответствующий ответ (сбой или успех) для последнего блока.

Команда 5.5.1

Таблица 5.5-1 FIRMWARE_UPDATE_CONTENT структура команды

5.5.1.1 Заголовок (B7 - B0)

Таблица 5.5-2 Макет заголовка команды FIRMWARE_UPDATE_CONTENT

Биты заголовка FIRMWARE_UPDATE_CONTENT описаны в этой таблице.

Таблица 5.5-3 Биты заголовка FIRMWARE_UPDATE_CONTENT

Возможные значения байтов флагов описаны в этой таблице.

Таблица 5.5-4 FIRMWARE_UPDATE_OFFER- Пакет команд предложения — значения флагов

Данные 5.5.1.2

Таблица 5.5-5 Структура данных команды FIRMWARE_UPDATE_CONTENT

Биты данных FIRMWARE_UPDATE_CONTENT описаны в этой таблице.

Таблица 5.5-6 FIRMWARE_UPDATE_CONTENT Биты данных команд

Ответ 5.5.2

Таблица 5.5-7 FIRMWARE_UPDATE_CONTENT Структура ответа команды

5.5.2.1 Порядковый номер

Таблица 5.5-8 FIRMWARE_UPDATE_CONTENT ответ — порядковый номер

Биты ответа FIRMWARE_UPDATE_CONTENT (3-0) описаны в этой таблице.

Таблица 5.5-9 FIRMWARE_UPDATE_CONTENT — команда — биты ответа

Состояние 5.5.2.2

Таблица 5.5-10 FIRMWARE_UPDATE_CONTENT структура состояния ответа

Биты ответа FIRMWARE_UPDATE_CONTENT (7–4) описаны в этой таблице.

Таблица 5.5-11 FIRMWARE_UPDATE_OFFER — ответ — биты состояния

Возможные значения байтов состояния описаны в этой таблице.

Таблица 5.5-12 FIRMWARE_UPDATE_OFFER — ответ — значения кода состояния

5.5.2.3 Зарезервировано B8 — B11

Зарезервировано. Не используйте.

5.5.2.4 Зарезервировано B12 — B15

Зарезервировано. Не используйте.

6 приложение 1. Пример последовательности команд программирования обновлений встроенного ПО

6.1 Пример 1

Рассмотрим следующее встроенное ПО устройства:

• Основной компонент — идентификатор компонента 1 — текущая версия встроенного ПО 7.0.1

• Подкомпонент — идентификатор компонента 2 — текущая версия встроенного ПО 12.4.54

• Подкомпонент — идентификатор компонента 3 — текущая версия встроенного ПО 4.4.2

• Подкомпонент — идентификатор компонента 4 — текущая версия встроенного ПО 23.32.9

На хосте есть три образа встроенного ПО:

• Идентификатор компонента 1 — встроенное ПО версии 7.1.3

• Идентификатор компонента 2 — прошивка версии 12.4.54

• Идентификатор компонента 3 — прошивка версии 4.5.0

Последовательность будет:

1. Хост предоставляет: ID компонента 1 — встроенное ПО версии 7.1.3

2. Основной компонент принимает предложение

3. Хост отправляет образ встроенного ПО

4. Основной компонент принимает встроенное ПО, проверяет его

5. Предложения узла: идентификатор компонента 2 — встроенное ПО версии 12.4.54

6. Основной компонент отклоняет предложение

7. Хост предоставляет: идентификатор компонента 3 — версия встроенного ПО 4.5.0

8. Основной компонент принимает предложение

9. Хост отправляет образ встроенного ПО

10. Основной компонент принимает встроенное ПО, проверяет его

Поскольку все предложения не были отклонены, хост повторно отправляет все предложения:

1. Предложения хоста: идентификатор компонента 1 — версия прошивки 7.1.3

2. Отбракованные компоненты

3. Предложения хоста: идентификатор компонента 2 — прошивка версии 12.4.54

4. Отклонение компонента

5. Предложение хоста: идентификатор компонента 3 — встроенное ПО версии 4.5.0

6. Отклонение компонента

6.2 Пример 2

Рассмотрим следующее встроенное ПО устройства:

• Основной компонент — идентификатор компонента 1 — текущая версия встроенного ПО 7.0.1

• Подкомпонент — идентификатор компонента 2 — текущая версия встроенного ПО 12.4.54

• Подкомпонент — идентификатор компонента 3 — текущая версия встроенного ПО 7.4.2

• Подкомпонент — идентификатор компонента 4 — текущая версия встроенного ПО 23.32.9

У хоста есть три образа встроенного ПО:

• Идентификатор компонента 1 . Встроенное ПО версии 8.0.0

• Идентификатор компонента 2 — прошивка версии 12.4.54

• Идентификатор компонента 3 — прошивка версии 9.0.0

Кроме того, реализация требует, чтобы версия встроенного ПО вложенных компонентов не должна быть меньше версии встроенного ПО, выполняемой на основном компоненте. Хост не знаком с этим требованием, и он является up-to основным компонентом для обеспечения этого правила.

Последовательность будет:

1. Хост предлагает: идентификатор компонента 1 — встроенное ПО версии 8.0.0

2. Основной компонент отклоняется (так как идентификатор компонента 3 еще не обновлен)

3. Предложения хоста: идентификатор компонента 2 — прошивка версии 12.4.54

4. Основной компонент отвергает

5. Предложение узла: идентификатор компонента 3 — встроенное ПО версии 9.0.0

6. Основной компонент принимает предложение

7. Хост отправляет образ встроенного ПО

8. Основной компонент принимает встроенное ПО, проверяет его

Поскольку все предложения не были отклонены, хост повторяет все предложения.

1. Предложения сервера: идентификатор компонента 1 — прошивка версии 8.0.0

2. Основной компонент принимает предложение

3. Хост отправляет образ встроенного ПО

4. Основной компонент принимает встроенное ПО, проверяет его

5. Предложения хоста: идентификатор компонента 2 — прошивка версии 12.4.54

6. Основной компонент отклоняет данные

7. Предложения узла: ID компонента 3 - версия встроенного ПО 9.0.0

8. Основной компонент отклоняет