Спецификация протокола обновления встроенного ПО компонента (CFU)
В этой спецификации описывается универсальный протокол HID для обновления встроенного ПО для компонентов, присутствующих на компьютере или аксессуарах. Спецификация позволяет компоненту принимать встроенное ПО без прерывания работы устройства во время загрузки. Спецификация поддерживает конфигурации, в которых компонент, принимаюющий встроенное ПО, может иметь подкомпоненты, для которых требуются отдельные образы встроенного ПО. Спецификация позволяет компоненту решать, принимать ли встроенное ПО. Он также выполняет функцию оптимизации, так как образ встроенного ПО отправляется компоненту только в том случае, если он может или готов принять его.
Примечание
CFU доступен в Windows 10 версии 2004 (обновление Windows 10 за май 2020 г.) и более поздних версиях.
Содержимое
- 1 Введение
- 2 Поддерживаемая аппаратная архитектура
- 3 Предварительные требования к протоколу
- 4 Общие сведения о протоколе CFU
- 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. Состояние: устройство занято
- 4.1. Последовательность команд для обновления встроенного ПО
- 5 Формат пакетов протокола CFU
- 6 Приложение 1. Пример последовательности команд для обновления встроенного ПО
Tables
Таблица 5.1–1 GET_FIRMWARE_VERSION макет ответа
Ответ GET_FIRMWARE_VERSION таблицы 5.1-2 — макет заголовка
Ответ GET_FIRMWARE_VERSION таблицы 5.1–3. Биты заголовков
Ответ GET_FIRMWARE_VERSION таблицы 5.1-4. Версия компонента и макет свойств
Таблица 5.1-5 GET_FIRMWARE_VERSION Ответ . Версии компонентов и свойства укусов
Таблица 5.2–1 FIRMWARE_UPDATE_OFFER макет команд
Таблица 5.2-2 FIRMWARE_UPDATE_OFFER команда — макет сведений о компоненте
Таблица 5.2-3 FIRMWARE_UPDATE_OFFER Команда — биты сведений о компонентах
Команда FIRMWARE_UPDATE_OFFER таблицы 5.2-4 — макет версии встроенного ПО
Команда FIRMWARE_UPDATE_OFFER в таблице 5.2–5 — разряды версий встроенного ПО
Таблица 5.2–6 FIRMWARE_UPDATE_OFFER команда — макет для конкретного поставщика
Таблица 5.2-7 FIRMWARE_UPDATE_OFFER Команда — прочее и версия протокола
Таблица 5.2–8 FIRMWARE_UPDATE_OFFER макет маркера ответа
Ответ FIRMWARE_UPDATE_OFFER таблицы 5.2–9. Макет маркера
Таблица 5.2–10 FIRMWARE_UPDATE_OFFER ответ — биты маркеров
Таблица 5.2-11 FIRMWARE_UPDATE_OFFER ответ . Отклонение макета причины
Таблица 5.2–12 FIRMWARE_UPDATE_OFFER ответ. Отклонение битов причины
Таблица 5.2–13 FIRMWARE_UPDATE_OFFER значения кода RR ответа
Таблица 5.2-14 FIRMWARE_UPDATE_OFFER макет состояния ответа
Ответ FIRMWARE_UPDATE_OFFER таблицы 5.2–15 — биты состояния
Таблица 5.2-16 FIRMWARE_UPDATE_OFFER значения состояния ответа
Таблица 5.3-1 FIRMWARE_UPDATE_OFFER — макет команд для сведений
Таблица 5.3-2 FIRMWARE_UPDATE_OFFER . Команда information — Макет компонента
Таблица 5.3-3 FIRMWARE_UPDATE_OFFER . Команда information — Биты компонентов
Таблица 5.3-4 FIRMWARE_UPDATE_OFFER . Команда Information — Значения кода информации
Таблица 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. Макет состояния ответа на пакет предложения
Таблица 5.4-12 FIRMWARE_UPDATE_OFFER. Код запроса ответа на пакет предложения
Макет команды FIRMWARE_UPDATE_CONTENT таблицы 5.5-1
Макет заголовка команды в таблице 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 и I2C. Поэтому для обновления встроенного ПО для всех компонентов можно использовать одно и то же программное решение (драйвер).
Примечание
Так как спецификация основана на пакетах, ее легко адаптировать к сценариям, не зависящим от HID.
Спецификация позволяет компоненту принимать встроенное ПО без прерывания работы устройства во время скачивания. Это позволяет улучшить взаимодействие с пользователями, так как им не нужно ждать завершения процесса обновления встроенного ПО, прежде чем они смогут возобновить другие задачи. Новое встроенное ПО можно вызывать в рамках одной атомарной операции за один раз, которая оказывает минимальное влияние на пользователя.
Спецификация поддерживает конфигурации, в которых компонент, принимаюющий встроенное ПО, может иметь подкомпоненты, для которых требуются отдельные образы встроенного ПО.
Примечание
Процесс передачи встроенного ПО компоненту компоненту выходит за рамки область данной спецификации.
Спецификация поддерживает концепцию предложения и полагается на компонент, который отвечает за принятие встроенного ПО. Решение о принятии нового встроенного ПО не является тривиальным. Между типом встроенного ПО и (или) версией и базовым типом или версией оборудования, к которому применяется новое встроенное ПО, могут существовать зависимости. Предложение также выступает в качестве механизма оптимизации, так как образ встроенного ПО отправляется компоненту только в том случае, если он может /ready принять его.
1.1. Глоссарий
| Термин | Описание |
|---|---|
| Идентификатор компонента | На устройстве с несколькими компонентами идентификатор компонента однозначно идентифицирует каждый компонент. |
| CRC | Циклическая проверка избыточности Алгоритм хэширования без шифрования, используемый для создания дайджеста или отпечатка блока данных. CRC используется в качестве проверка, чтобы гарантировать, что блок данных не изменился с момента вычисления CRC. CRC не является непогрешимым, но обеспечивает уверенность в том, что данные были получены правильно. |
| Устройство | Коллекция компонентов (один основной компонент и ноль или несколько подкомпонентов). Устройство отображается операционной системе как единое целое. Узел взаимодействует с устройством, которое обычно является основным компонентом. На компьютере может быть несколько устройств. Что касается этой спецификации, то связь с 2 различными устройствами полностью независима. |
| Драйвер | Драйвер, написанный с помощью платформы Windows Driver Foundation (WDF). |
| Firmware (Встроенное ПО) | Код, выполняемый на физическом оборудовании. Встроенное ПО является обновляемым и обычно находится в программируемой памяти, связанной с оборудованием. |
| Оборудование | Физический кусок кремния на компьютере. |
| Основной компонент | Часть оборудования на компьютере и встроенное ПО для него. В контексте этой спецификации компонент — это сущность, которая требует и принимает обновление встроенного ПО. |
| Segment | Образ встроенного ПО для компонента может быть разделен на более мелкие сегменты. Каждый сегмент представляет собой небольшой образ встроенного ПО. |
| Идентификатор сегмента | Если встроенное ПО компонента сегментировано на более мелкие сегменты, идентификатор сегмента является уникальным идентификатором сегмента. |
| Сигнатура | Криптографическое средство для определения того, был ли изменен образ встроенного ПО несанкционированным способом. Подписи являются необязательными, но рекомендуется и выходят за область этой спецификации. |
| Компонент | В зависимости от архитектуры оборудования не все компоненты могут быть видны операционной системе, так как они могут быть подключены ниже компонента, видимого системе. В этой спецификации эти компоненты называются подкомпонентами. |
| TLC | Коллекция верхнего уровня HID. |
| Токен | Идентификатор сеанса узла. Узел создает маркер и отправляет его в командах, а устройство возвращает его в ответе. Маркеры могут использоваться для сериализации определенных транзакций или для выявления потери сеанса и запуска другого сеанса. |
1.2 Область действия
1.2.1 Goals
Чтобы избежать нового протокола для каждого типа шины, требуется решение, не зависят от шин. HID является повсеместным и отвечает этим требованиям.
Возможность поддержки обновления встроенного ПО для многокомпонентного устройства, где один компонент выступает в качестве основного компонента, а другие являются подкомпонентами, подключенными к основному компоненту. Для каждого компонента требуется собственное встроенное ПО с нетривиальными зависимостями между собой.
Общая модель драйвера для скачивания образа встроенного ПО в компонент. Затем компонент имеет подкомпонентные алгоритмы для переадресации в подкомпоненты. Подкомпоненты также могут выполнять проверки допустимости встроенного ПО и передавать результаты обратно в основной компонент.
Возможность поддерживать обновление встроенного ПО во время работы устройства.
Возможность обновления или отката встроенного ПО на рабочих устройствах с помощью авторизованных средств и обновления устройств на рынке с помощью клиентский компонент Центра обновления Windows.
Гибкость для поддержки встроенного ПО в разработке или встроенного ПО на рынке.
Возможность сегментировать большой образ встроенного ПО на более мелкие сегменты, чтобы упростить прием образа встроенного ПО компонентом.
1.2.2. Не Goals
Определите внутренний формат образа встроенного ПО. Для узла образ встроенного ПО представляет собой набор записей адреса и полезных данных.
Подписывайте, шифруйте и проверяйте принятое встроенное ПО. В этой спецификации не описывается, как подписывать и шифровать образы встроенного ПО. Требуется, чтобы ожидаемое текущее встроенное ПО, работающее в компоненте, проверялось скачиваемое встроенное ПО.
Определите механизм взаимодействия компонента с подкомпонентами. Узел взаимодействует с устройством как единое целое, обычно это основной компонент. Компонент должен выступать в качестве моста для обмена данными, связанными с подкомпонентом встроенного ПО.
2 Поддерживаемая аппаратная архитектура
Для поддержки гибкой конструкции оборудования протокол поддерживает многокомпонентное устройство, где каждому компоненту требуется собственный образ встроенного ПО. В проекте один компонент является основным компонентом, а зависимые подкомпоненты подключены к основному компоненту. Каждый компонент уникально описывается идентификатором компонента.
Многокомпонентное устройство отображается для операционной системы как единое устройство. Узел взаимодействует только с устройством, как правило, основным компонентом, использующим этот протокол CFU. Взаимодействие между компонентом и его подкомпонентами выходит за рамки область этой спецификации.
На компьютере может быть много различных устройств (где устройство может содержать один или несколько компонентов). В контексте этого протокола взаимодействие с каждым устройством является независимым. Каждое устройство имеет соответствующий экземпляр узла.
3 Предварительные требования к протоколу
В этом разделе перечислены требования и рекомендации, которые необходимо реализовать для использования этого протокола:
Использование атомарных образов
Образ встроенного ПО для компонента не используется, пока не будет успешно скачан весь образ встроенного ПО. Если встроенное ПО разделено на несколько сегментов, изображение не должно использоваться до получения окончательного сегмента от отправителя. Проверки целостности должны выполняться на окончательном изображении. Рекомендуется, чтобы транспорт, используемый для доставки образа встроенного ПО, использовал механизмы исправления ошибок и повторных попыток, чтобы избежать повторной загрузки в случае ошибок транспорта.
Обновление встроенного ПО не должно прерывать работу устройства
Устройство, принимающее образ встроенного ПО, должно работать во время обновления. Устройство должно иметь дополнительную память для хранения и проверки входящего встроенного ПО, в то время как текущее встроенное ПО не перезаписывается.
Проверка подлинности и целостность
Разработчик решает, что факторы, составляющие подлинный образ встроенного ПО. Рекомендуется, чтобы текущее встроенное ПО компонента должно по крайней мере проверять CRC входящего образа встроенного ПО. Текущее встроенное ПО также должно использовать цифровую подпись или другие алгоритмы обнаружения ошибок. Если проверка завершается сбоем, встроенное ПО отклоняет обновление. Сбой восстановления
Если образ встроенного ПО скачан и неудачно, устройство не должно вызывать новое встроенное ПО и продолжать работать с существующим встроенным ПО. Узел может повторить обновление. Частота повторных попыток зависит от реализации.
Конфиденциальность
Необязательный элемент. Сегмент встроенного ПО может быть зашифрован. Методы шифрования и расшифровки выходят за рамки область этой спецификации. Эта спецификация рассматривает полезные данные встроенного ПО как поток данных, независимо от того, зашифрованы ли они.
Защита от отката
Политики отката применяются основным компонентом и зависят от реализации. Текущее встроенное ПО компонента проверяет входящие образы встроенного ПО на соответствие внутренним политикам, таким как номер версии должен быть новее или тип выпуска нельзя переключить с выпуска на отладку и т. д. Протокол позволяет обмену сообщениями указывать, что обновление принимается, даже если оно нарушает политики отката.
4 Общие сведения о протоколе CFU
Протокол 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 состоянием, предоставляющим соответствующую причину отклонения. Это состояние не означает, что узел не сможет повторно отправить это предложение в будущем. Как правило, узел отправляет каждое предложение каждый раз при инициализации или повторной отправке списка предложений на устройство (см. раздел State: OFFER_INFO_START_OFFER_LIST Notification).
4.1.4 Состояние: отправка встроенного ПО
В этом состоянии узел начинает отправлять образ встроенного ПО основному компоненту, для которого компонент ранее принял предложение.
Так как содержимое образа встроенного ПО, скорее всего, выходит за пределы полезных данных одной команды, узел разбивает образы встроенного ПО на пакеты. Узел отправляет каждый пакет последовательно в отдельной команде FIRMWARE_UPDATE CONTENT. Основной компонент должен создавать пакет ответа для каждой команды.
Каждая команда FIRMWARE_UPDATE CONTENT описывает адрес смещения, который содержит частичные полезные данные встроенного ПО. Компонент использует смещение для определения адреса, по которому должны храниться частичные полезные данные встроенного ПО. Устройство записывает содержимое в соответствующее расположение и подтверждает команду, отправляя ответ.
Для первого пакета, отправляемого узлом, он устанавливает флаг FIRMWARE_UPDATE_FLAG_FIRST_BLOCK, указывающий устройству, что это первый пакет образа встроенного ПО. Если устройство еще не подготовилось к получению встроенного ПО, оно может сделать это в настоящее время.
Для последнего пакета, отправляемого узлом, он устанавливает флаг FIRMWARE_UPDATE_FLAG_LAST_BLOCK.
После того как текущее встроенное ПО на устройстве записало часть полезных данных встроенного ПО, включенных в эту команду, оно должно выполнить проверку и проверку подлинности для входящего образа встроенного ПО перед отправкой ответа. К ним относятся:
CRC проверка для проверки целостности всего образа встроенного ПО.
Если проверка CRC успешно, необязательная проверка подписи входящего изображения.
После проверка необязательной сигнатуры проверка версию, чтобы убедиться, что новая версия встроенного ПО совпадает с существующей версией встроенного ПО.
Если входящий образ встроенного ПО был разделен на более мелкие сегменты, текущее встроенное ПО определяет, является ли это последним сегментом образа встроенного ПО, а затем включает все сегменты в рамках проверки.
Если предыдущие проверки пройдены, текущее встроенное ПО может настроить устройство для переключения на новый образ при следующем сбросе и сообщит об успешном выполнении на узел. Как правило, компонент не инициирует самостоятельный сброс. Это необходимо для предотвращения сбоев в работе любого программного обеспечения, встроенного ПО, аппаратных сущностей, с которыми взаимодействует компонент. Однако это не является обязательным требованием и может отличаться в зависимости от реализации.
Если шаги проверки завершаются сбоем, встроенное ПО не должно настраивать переключение при следующем сбросе и должно указывать на ответ узла о сбое.
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, на которую устройство не отвечает с принятием, пока устройство не освободит его.
5 Формат пакетов протокола CFU
Протокол CFU реализуется как набор команд и ответов. Протокол имеет последовательный характер. Для каждой команды, которую узел отправляет компоненту, компонент должен отвечать (если в этой спецификации явно не указано иное). Узел не отправляет следующую команду, пока не будет получен допустимый ответ для предыдущей отправляемой команды.
Если компонент не отвечает в течение определенного периода или отправляет недопустимый ответ, узел может перезапустить процесс с самого начала. Этот протокол не определяет определенное значение времени ожидания.
Существуют команды для получения сведений о версии текущего встроенного ПО компонента; для отправки предложения и для отправки образа встроенного ПО.
Однако узлу не нужно удерживать предложение на основе ответа, полученного от основного компонента о запрашиваемой версии. Сведения можно обнаружить для ведения журнала или для других целей.
5.1 GET_FIRMWARE_VERSION
Возвращает текущие версии встроенного ПО основного компонента (и его подкомпоненты). У команды нет аргументов.
Команда 5.1.1
Эта команда отправляется узлом для запроса версий текущего встроенного ПО основного компонента (и его подкомпонентов). Узел может использовать его для подтверждения успешного обновления встроенного ПО. При получении этой команды основной компонент отвечает версией встроенного ПО для себя и всех подкомпонентов.
5.1.2. Ответ
Компонент отвечает версией встроенного ПО основного компонента и подкомпонентов. Размер ответа составляет 60 байт, что позволяет получить сведения о версии до семи компонентов (один основной и до шести подкомпонентов).
Таблица 5.1-1 GET_FIRMWARE_VERSION макет ответа
5.1.2.1 Заголовок
Ответ GET_FIRMWARE_VERSION таблицы 5.1-2. Макет заголовка
Заголовок ответа содержит следующие сведения.
Ответ GET_FIRMWARE_VERSION таблицы 5.1-3. Биты заголовков
| Битовое смещение | Поле | Size | Описание |
|---|---|---|---|
| 0 | Количество компонентов | 8 | Количество загружаемых компонентов, управляемых с помощью этого механизма для этого компонента. Максимальный размер таблицы определяется параметром Количество компонентов. В настоящее время поддерживается до 7 компонентов, чтобы гарантировать, что ответ может поместиться в пределах допустимых 60 байт. |
| 8 | Rsvd | 16 | Зарезервированные поля. Отправитель должен установить для них значение 0. Получатель должен игнорировать это значение. |
| 24 | Версия протокола | 4 | Биты редакции обновления встроенного ПО представляют редакцию протокола обновления FW, которая в настоящее время используется в транспорте. Для интерфейса, определенного здесь, версия обновления FW должна иметь значение 0010b. |
| 28 | Rsvd | 3 | Зарезервированные поля. Отправитель должен установить для них значение 0. Получатель должен игнорировать это значение. |
| 31 | E | 1 | Флаг расширения — это будущий перехватчик протокола для включения отчетов о дополнительных компонентах. |
5.1.2.2. Версия и свойства компонента
Для каждого компонента используются два DWORD для описания свойств компонента до 7 компонентов. Если число компонентов в заголовке меньше 7, то неиспользуемые DWORDS в конце ответа должны иметь значение 0.
Таблица 5.1-4 GET_FIRMWARE_VERSION Ответ — версия компонента и макет свойств
Сведения о каждом компоненте описаны в двух DWORD следующим образом:
Таблица 5.1-5 GET_FIRMWARE_VERSION Ответ . Укусы версий компонентов и свойств
| Битовое смещение | Поле | Size | Описание |
|---|---|---|---|
| 0 | Версия встроенного ПО | 32 | Возвращает версию текущего встроенного ПО для этого компонента. Эта спецификация не требует какого-либо конкретного формата для версии встроенного ПО. Рекомендации см. в разделе Версия встроенного ПО. |
| 32 | Bank | 2 | Необязательный элемент. В зависимости от архитектуры оборудование компонента может иметь несколько банков, в которых может храниться встроенное ПО. В зависимости от реализации отправитель может указать банк, в котором сейчас существует встроенное ПО. Это поле является условным обязательным. Поддержка необязательна, но не должна использоваться для каких-либо других целей. |
| 34 | Зарезервировано | 2 | Зарезервированные поля. Отправитель должен задать для них значение 0. Получатель должен игнорировать это значение. |
| 36 | Конкретный поставщик | 4 | Поле для конкретного поставщика, которое может использоваться в определенной реализации способом. Поставщик может использовать эти биты для кодирования таких сведений, как: — Тип встроенного ПО: предварительная версия, самостоятельное размещение или рабочая среда; отладка и розничная торговля — Этап разработки — Идентификатор продукта, чтобы компоненты не получали встроенное ПО для других продуктов, использующих тот же протокол обновления. |
| 40 | Идентификатор компонента | 8 | Уникальный идентификатор компонента. |
| 48 | Конкретный поставщик | 16 | Поле для конкретного поставщика, которое может использоваться в определенной реализации способом. |
5.1.3. Сопоставление с HID
Он реализуется как запрос hid Get Feature с размером ответа 60 байтов в дополнение к идентификатору отчета. Длина отчета о функциях вмещает весь ответ GET_FIRMWARE_VERSION. Нет данных, связанных с запросом get feature от узла.
5.2 FIRMWARE_UPDATE_OFFER
Определяет, принимает ли основной компонент встроенное ПО или отклоняет его.
5.2.1. Команда
Узел отправляет эту команду компоненту, чтобы определить, принимает ли он встроенное ПО или отклоняет его. Узел должен отправить предложение, а компонент должен принять предложение, прежде чем узел сможет отправить встроенное ПО.
Пакет FIRMWARE_UPDATE_OFFER Command определяется следующим образом.
Таблица 5.2–1 FIRMWARE_UPDATE_OFFER макет команд
5.2.1.1. Сведения о компоненте
Таблица 5.2-2 FIRMWARE_UPDATE_OFFER команда — макет сведений о компоненте
Биты байта сведений о компонентах описаны в этой таблице.
Таблица 5.2-3 FIRMWARE_UPDATE_OFFER Команда — биты сведений о компонентах
| Битовое смещение | Поле | Size | Описание |
|---|---|---|---|
| 0 | Номер сегмента | 8 | Это поле используется в случае, если встроенное ПО компонента сегментировано на более мелкие сегменты. При использовании это значение указывает сегмент, содержащийся в последующем пакете полезных данных. Например, если образ встроенного ПО для компонента очень велик, а основной компонент может одновременно принимать только небольшие части изображения, это поле может использоваться для указания того, что это предложение предназначено для i-го сегмента полного образа. Отдельное предложение может быть отправлено в основной компонент, содержащий i+1-й сегмент изображения и т. д. |
| 8 | Зарезервировано | 6 | Зарезервированные поля. Отправитель должен задать для них значение 0. Получатель должен игнорировать это значение. |
| 14 | I | 1 | Принудительный немедленный сброс (I) — Это битовое значение используется для указания компоненту на немедленный сброс после завершения загрузки встроенного ПО и проверки на его немедленное вызов. — Этот флаг предназначен для этапа разработки. |
| 15 | V | 1 | Принудительное игнорирование версии (V) — Этот флаг предназначен для предварительной версии или отладочного образа встроенного ПО. Он указывает компоненту не отклонять встроенное ПО на основе версии встроенного ПО. — Этот флаг предназначен для этапа разработки. Его можно использовать для намеренного отката к предыдущей версии встроенного ПО. — этот флаг следует игнорировать в рабочей среде встроенного ПО. |
| 16 | Идентификатор компонента | 8 | Этот байт используется для сценариев с несколькими компонентами. Это поле может использоваться для определения подкомпонента, для которого предназначено предложение. Если значение не используется, значение должно быть равно 0. Возможные значения идентификаторов компонентов: 1 - 0xDF: допустимо 0xE0 — 0xFD: зарезервировано. Не используйте. 0xFF: предложение представляет собой специальный пакет сведений о предложении. Дополнительные сведения см. в разделе сведения о FIRMWARE_UPDATE_OFFER. 0xFE: предложение представляет собой пакет команд специального предложения. Дополнительные сведения см. в разделе FIRMWARE_UPDATE_OFFER Расширенный. |
| 24 | Токен | 8 | Узел вставляет уникальный маркер в пакет предложения компоненту. Этот маркер должен быть возвращен компонентом в ответе предложения.< Это полезно, если компоненту необходимо различать разные узлы или типы узлов. Точные значения, которые необходимо использовать, зависят от реализации. Например, одно значение можно использовать для драйвера, а другое — для приложения. Это позволяет текущему встроенному ПО устройства учитывать несколько потенциальных отправителей команд CFU. Одной из возможных реализаций может быть принятие первой команды CFU и отклонение всех остальных команд с разными маркерами до завершения первых транзакций CFU. |
Версия встроенного ПО 5.2.1.2
Эти четыре байта представляют 32-разрядную версию встроенного ПО. Формат версии встроенного ПО не требуется этой спецификацией. Рекомендуется следующее.
Команда FIRMWARE_UPDATE_OFFER таблицы 5.2-4 — макет версии встроенного ПО
Формат для версии встроенного ПО не является обязательным в этой спецификации, однако рекомендуется использовать следующее руководство.
Команда FIRMWARE_UPDATE_OFFER в таблице 5.2–5 — разряды версий встроенного ПО
| Битовое смещение | Поле | Size | Описание |
|---|---|---|---|
| 0 | Variant | 8 | Это поле можно описать, чтобы различать предварительное и рабочее встроенное ПО. Он может указывать тип подписи, используемой для подписывания встроенного ПО. |
| 8 | Вспомогательная версия | 16 | Это значение поля должно обновляться для каждой сборки встроенного ПО. Это значение поля должно обновляться для каждой сборки встроенного ПО. |
| 24 | Основная версия | 8 | Это поле является основной версией образа встроенного ПО. Это поле должно обновляться при доставке новой линейки продуктов, крупных новых обновлений встроенного ПО и т. д. |
5.2.1.3. Конкретные поставщики
Эти четыре байта можно использовать для кодирования любых пользовательских сведений в предложении, относящихся к реализации поставщика.
5.2.1.4 Разное и версия протокола
Эти четыре байта можно использовать для кодирования любых пользовательских сведений в предложении, относящихся к реализации поставщика.
Таблица 5.2–6 FIRMWARE_UPDATE_OFFER команда — макет для конкретного поставщика
Биты байта конкретного поставщика описаны в этой таблице.
Таблица 5.2-7 FIRMWARE_UPDATE_OFFER Команда — прочее и версия протокола
| Битовое смещение | Поле | Size | Описание |
|---|---|---|---|
| 0 | Версия протокола | 4 | Для этого поля должно быть задано значение 0010b, указывающее, что узел или предложение соответствует версии 2 протокола CFU. |
| 4 | Зарезервировано | 4 | Зарезервировано. Не используйте. |
| 8 | Зарезервировано | 8 | Зарезервировано. Не используйте. |
| 16 | Конкретный поставщик | 16 | Это поле может использоваться для кодирования любых пользовательских сведений в предложении, относящихся к реализации поставщика. |
5.2.2 Ответ
Пакет ответа FIRMWARE_UPDATE_OFFER определяется следующим образом.
Таблица 5.2–8 FIRMWARE_UPDATE_OFFER макет маркера ответа
Токен 5.2.2.1
Ответ FIRMWARE_UPDATE_OFFER таблицы 5.2–9. Макет маркера
Биты байта токена описаны в этой таблице.
Таблица 5.2–10 FIRMWARE_UPDATE_OFFER ответ — биты маркеров
| Битовое смещение | Поле | Size | Описание |
|---|---|---|---|
| 0 | Зарезервировано | 8 | Зарезервировано. Не используйте. |
| 8 | Зарезервировано | 8 | Зарезервировано. Не используйте. |
| 16 | Зарезервировано | 8 | Зарезервировано. Не используйте. |
| 24 | Токен | 8 | Маркер для идентификации узла. |
5.2.2.2 Зарезервировано (B7 – B4)
Зарезервировано. Не используйте.
5.2.2.3 Отклонение причины (RR)
Таблица 5.2-11 FIRMWARE_UPDATE_OFFER Ответ . Макет причины отклонения
Ответ FIRMWARE_UPDATE_OFFER таблицы 5.2-12. Отклонить биты причины
Биты байта отклонить причину описаны в этой таблице.
| Битовое смещение | Поле | Size | Описание |
|---|---|---|---|
| 0 | Код RR | 8 | Код причины отклонения, указывающий причину, предоставленную компонентом для отклонения предложения. Это значение зависит от поля Состояние. Сопоставление состояния с кодом RR см. в таблице 5.2-13. |
| 8 | Зарезервировано | 24 | Зарезервировано. Не используйте. |
Таблица 5.2-13 FIRMWARE_UPDATE_OFFER значения кода RR ответа
Возможные значения байта кода RR описаны в этой таблице.
| Код RR | Имя | Описание |
|---|---|---|
| 0x00 | FIRMWARE_OFFER_REJECT_OLD_FW | Предложение было отклонено, так как версия предлагаемого встроенного ПО старше или совпадает с текущей версией встроенного ПО. |
| 0x01 | FIRMWARE_OFFER_REJECT_INV_COMPONENT | Предложение было отклонено, так как предлагаемое встроенное ПО неприменимо к платформе продукта. Это может быть связано с не поддерживаемым идентификатором компонента или из-за несовместимого образа с оборудованием системы. |
| 0x02 | FIRMWARE_UPDATE_OFFER SWAP_PENDING | Встроенное ПО компонента обновлено, однако ожидается переход на новое встроенное ПО. Дальнейшая обработка обновления встроенного ПО не может выполняться до завершения переключения, обычно путем сброса. |
| 0x03 — 0x08 | (Зарезервировано) | Зарезервировано. Не используйте. |
| 0x09 — 0xDF | (Зарезервировано) | Зарезервировано. Не используйте. |
| 0xE0 — 0xFF | (Зависит от поставщика) | Эти значения используются конструкторами протокола, и значение зависит от поставщика. |
5.2.2.4 Состояние
Таблица 5.2-14 FIRMWARE_UPDATE_OFFER макет состояния ответа
Биты байта состояния описаны в этой таблице.
Ответ FIRMWARE_UPDATE_OFFER таблицы 5.2–15 — биты состояния
| Битовое смещение | Поле | Size | Описание |
|---|---|---|---|
| 0 | Состояние | 8 | Это значение указывает на решение компонента принять, отправить, пропустить или отклонить предложение. Компонент предоставляет причину в значении поля Код RR. Сопоставление состояния с кодом RR см. в таблице 5.2-16. |
| 8 | Зарезервировано | 24 | Зарезервировано. Не используйте. |
Возможные значения байта состояния описаны в этой таблице.
Таблица 5.2-16 FIRMWARE_UPDATE_OFFER значения состояния ответа
| Состояние | Имя | Описание |
|---|---|---|
| 0x00 | FIRMWARE_UPDATE_OFFER_SKIP | Компонент решил пропустить предложение. Узел должен предложить его снова позже. |
| 0x01 | FIRMWARE_UPDATE_OFFER_ACCEPT | Компонент решил принять предложение. |
| 0x02 | FIRMWARE_UPDATE_OFFER_REJECT | Компонент решил отклонить предложение. |
| 0x03 | FIRMWARE_UPDATE_OFFER_BUSY | Устройство занято, и узел должен подождать, пока устройство будет готово. |
| 0x04 | FIRMWARE_UPDATE_OFFER_COMMAND | Используется, если идентификатор компонента в байтах сведений о компоненте (см. раздел 5.1.2.1.1 Сведения о компоненте) имеет значение 0xFE. Если для командного кода задано значение OFFER_NOTIFY_ON_READY запрос, означает, что аксессуар готов принять дополнительные предложения. |
| 0xFF | FIRMWARE_UPDATE_CMD_NOT_SUPPORTED | Запрос предложения не распознает. |
5.2.3. Сопоставление с протоколом HID
Сообщение выдается компоненту с помощью механизма вывода отчета HID с использованием выделенного идентификатора отчета программы HID для обновления встроенного ПО. Служебная программа HID для использования, описанная в приложении.
5.3 FIRMWARE_UPDATE_OFFER — информация
Если для идентификатора компонента в байтах сведений о компоненте (см. сведения о компоненте) задано значение 0xFF, то биты (15 байт) переопределяются, чтобы указать только сведения о предложении от узла к компоненту. Этот механизм обеспечивает расширяемость и способ предоставления узлу определенных сведений устройству, таких как "Начальный список предложений", "Завершить список предложений", "Начать всю транзакцию". Пакеты сведений о предложении всегда сразу же принимаются компонентом.
5.3.1. Команда
Пакет FIRMWARE_UPDATE_OFFER -Information Command определяется следующим образом:
Таблица 5.3-1 FIRMWARE_UPDATE_OFFER — макет команды information
Компонент 5.3.1.1
Таблица 5.3-2 FIRMWARE_UPDATE_OFFER — команда information — макет компонента
Биты байта компонента описаны в этой таблице.
Таблица 5.3-3 FIRMWARE_UPDATE_OFFER — команда information — биты компонентов
| Битовое смещение | Поле | Size | Описание |
|---|---|---|---|
| 0 | Код сведений | 8 | Это значение указывает тип сведений. Это значение не является битовой маской и может быть только одним из возможных значений, описанных в таблице 5.3–4. |
| 8 | Зарезервировано. | 8 | Зарезервировано. Не используйте. |
| 16 | Идентификатор компонента | 8 | Задайте значение 0xFF. |
| 24 | Токен | Узел вставляет уникальный маркер в пакет предложения компоненту. Этот маркер должен быть возвращен компонентом в ответе предложения. |
Таблица 5.3-4 FIRMWARE_UPDATE_OFFER . Information Command — Information Code Values
| Состояние | Имя | Описание |
|---|---|---|
| 0x00 | OFFER_INFO_START_ENTIRE_TRANSACTION | Указывает, что узел является новым или был перезагружен, а вся обработка предложения (повторно) начинается. |
| 0x01 | OFFER_INFO_START_OFFER_LIST | Указывает начало списка предложений с узла на случай, если в аксессуаре есть правила скачивания, связанные с обеспечением обновления одного подкомпонента перед другим подкомпонентом в системе. |
| 0x02 | OFFER_INFO_END_OFFER_LIST | Указывает конец списка предложений от узла. |
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 — информационный ответ — биты маркеров
| Битовое смещение | Поле | Size | Описание |
|---|---|---|---|
| 0 | Зарезервировано | 8 | Зарезервировано. Не используйте. |
| 8 | Зарезервировано | 8 | Зарезервировано. Не используйте. |
| 16 | Зарезервировано | 8 | Зарезервировано. Не используйте. |
| 24 | Токен | 8 | Маркер для идентификации узла |
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
| Битовое смещение | Поле | Size | Описание |
|---|---|---|---|
| 0 | Код RR | 8 | Код причины отклонения, указывающий причину, предоставленную компонентом для отклонения предложения. Возможные значения описаны в таблице 5.3–10. Это значение зависит от поля Состояние. |
| 8 | Зарезервировано | 24 | Зарезервировано. Не используйте. |
Возможные значения для байта кода RR описаны в этой таблице.
Таблица 5.3-10 FIRMWARE_UPDATE_OFFER— информационный ответ — значения кода RR
| Код RR | Имя | Описание |
|---|---|---|
| 0x00 | FIRMWARE_OFFER_REJECT_OLD_FW | Предложение было отклонено, так как версия предлагаемого встроенного ПО старше или та же, что и текущая версия встроенного ПО. |
| 0x01 | FIRMWARE_OFFER_REJECT_INV_COMPONENT | Предложение было отклонено, так как предлагаемое встроенное ПО неприменимо к платформе продукта. Это может быть вызвано тем, что не поддерживается идентификатор компонента или предлагаемый образ несовместим с системным оборудованием. |
| 0x02 | FIRMWARE_UPDATE_OFFER SWAP_PENDING | Встроенное ПО компонента обновлено, однако ожидается переход на новое встроенное ПО. Дальнейшая обработка обновления встроенного ПО не может выполняться до тех пор, пока переключение не завершится, как правило, в результате сброса. |
| 0x03 — 0x08 | (Зарезервировано) | Зарезервировано. Не используйте. |
| 0x09 — 0xDF | (Зарезервировано) | Зарезервировано. Не используйте. |
| 0xE0 — 0xFF | (Зависит от поставщика) | Эти значения используются конструкторами протокола, а их значение зависит от поставщика. |
5.3.2.4 Состояние
Таблица 5.3-11 FIRMWARE_UPDATE_OFFER . Макет состояния ответа на сведения о предложении
Биты байта Состояния описаны в этой таблице.
Таблица 5.3–12 FIRMWARE_UPDATE_OFFER . Сведения о предложении — биты состояния ответа
| Битовое смещение | Поле | Size | Описание |
|---|---|---|---|
| 0 | Состояние | 8 | Для этого поля необходимо задать значение FIRMWARE_UPDATE_OFFER_ACCEPT. Это означает, что компонент решил принять предложение. |
| 8 | Зарезервировано. | 24 | Зарезервировано. Не используйте. |
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 — расширенная команда — биты компонентов
| Битовое смещение | Поле | Size | Описание |
|---|---|---|---|
| 0 | Код команды | 8 | Это значение указывает тип команды. Это значение не является битовой маской и может быть только одним из возможных значений, описанных в таблице 5.4–4. |
| 8 | Зарезервировано. | 8 | Зарезервировано. Не используйте. |
| 16 | Идентификатор компонента | 8 | Задайте значение 0xFE. |
| 24 | Токен | Узел вставляет уникальный маркер в пакет предложения компоненту. Этот маркер должен быть возвращен компонентом в ответе предложения. |
Таблица 5.4-4 FIRMWARE_UPDATE_OFFER — расширенная команда — значения кода команд
| Состояние | Имя | Описание |
|---|---|---|
| 0x01 | OFFER_NOTIFY_ON_READY | Отправляется узлом, если предложение ранее было отклонено компонентом. |
| 0x02 — 0xFF | Зарезервировано | Зарезервировано |
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. Ответ команды предложения — биты токенов
| Битовое смещение | Поле | Size | Описание |
|---|---|---|---|
| 0 | Зарезервировано | 8 | Зарезервировано. Не используйте. |
| 8 | Зарезервировано | 8 | Зарезервировано. Не используйте. |
| 16 | Зарезервировано | 8 | Зарезервировано. Не используйте. |
| 24 | Токен | 8 | Маркер для идентификации узла. |
5.4.2.2 Зарезервировано B7 — B4
Зарезервировано. Не используйте.
5.4.2.3 Отклонение причины
Таблица 5.4-8 FIRMWARE_UPDATE_OFFER. Макет запроса ответа на информационный пакет предложения
Биты байта отклонить причину описаны в этой таблице.
Таблица 5.4-9 FIRMWARE_UPDATE_OFFER. Ответ команды предложения — код RR
| Битовое смещение | Поле | Size | Описание |
|---|---|---|---|
| 0 | Код RR | 8 | Это значение зависит от поля Состояние. Возможные значения кода RR см. в таблице 5.4–10. |
| 8 | Зарезервировано | 24 | Зарезервировано. Не используйте. |
Возможные значения байта кода RR описаны в этой таблице.
Таблица 5.4-10 FIRMWARE_UPDATE_OFFER. Пакет команд предложения — значения кода RR
| Код RR | Имя | Описание |
|---|---|---|
| 0x00 | FIRMWARE_OFFER_REJECT_OLD_FW | Предложение было отклонено, так как версия предлагаемого встроенного ПО старше или совпадает с текущей версией встроенного ПО. |
| 0x01 | FIRMWARE_OFFER_REJECT_INV_COMPONENT | Предложение было отклонено, так как предлагаемое встроенное ПО неприменимо к платформе продукта. Это может быть связано с не поддерживаемым идентификатором компонента или из-за несовместимого образа с оборудованием системы. |
| 0x02 | FIRMWARE_UPDATE_OFFER SWAP_PENDING | Встроенное ПО компонента обновлено, однако ожидается переход на новое встроенное ПО. Дальнейшая обработка обновления встроенного ПО не может выполняться до завершения переключения, обычно путем сброса. |
| 0x03 — 0x08 | (Зарезервировано) | Зарезервировано. Не используйте. |
| 0x09 — 0xDF | (Зарезервировано) | Зарезервировано. Не используйте. |
| 0xE0 — 0xFF | (Зависит от поставщика) | Эти значения используются конструкторами протокола, и значение зависит от поставщика. |
5.4.2.4 Состояние
Таблица 5.4-11 FIRMWARE_UPDATE_OFFER. Макет состояния ответа на пакет предложения
Биты байта состояния описаны в этой таблице.
Таблица 5.4-12 FIRMWARE_UPDATE_OFFER. Код запроса ответа на пакет предложения
| Битовое смещение | Поле | Size | Описание |
|---|---|---|---|
| 0 | Состояние | 8 | Для этого поля необходимо задать значение FIRMWARE_UPDATE_OFFER_ACCEPT. Это означает, что компонент решил принять предложение. |
| 8 | Зарезервировано. | 24 | Зарезервировано. Не используйте. |
5.5 FIRMWARE_UPDATE_CONTENT
Узел отправляет эту команду встроенному ПО устройства, чтобы предоставить содержимое встроенного ПО (то есть образ встроенного ПО). Ожидается, что весь файл образа не помещается в одну команду. Узел должен разбить образ на более мелкие блоки, и каждая команда отправляет по одному блоку образа за раз.
При выполнении каждой команды узел указывает дополнительные сведения: первый, последний блок и т. д. встроенного ПО. Основной компонент встроенного ПО устройства принимает каждый блок входящего образа встроенного ПО, сохраняет его в памяти и должен реагировать на каждую команду по отдельности.
Когда основной компонент получает последний блок, компонент проверяет весь образ встроенного ПО (проверка CRC, проверка подписи). На основе результатов этих проверок возвращается соответствующий ответ (сбой или успех) для последнего блока.
Команда 5.5.1
Макет команды FIRMWARE_UPDATE_CONTENT таблицы 5.5-1
5.5.1.1 Заголовок (B7 – B0)
Макет заголовка команды в таблице 5.5-2 FIRMWARE_UPDATE_CONTENT
Биты заголовка FIRMWARE_UPDATE_CONTENT описаны в этой таблице.
Биты заголовка таблицы 5.5-3 FIRMWARE_UPDATE_CONTENT
| Битовое смещение | Поле | Size | Описание |
|---|---|---|---|
| 0 | Флаги | 8 | Это поле содержит дополнительные сведения о команде. Это значение представляет собой маску флагов, используемых для передачи данных. Возможные значения описаны в таблице 5.5-4. |
| 8 | Длина данных | 8 | Длина соответствующего поля Данных, указывающая количество записываемых байтов. Учитывая размер этой команды, максимально допустимое значение длины составляет 52 байта. |
| 16 | Порядковый номер | 16 | Это значение создается узлом и является уникальным для каждого выданного пакета содержимого. Компонент должен вернуть порядковый номер в ответе на этот запрос. |
| 32 | Адрес встроенного ПО | 32 | Адрес little Endian (LSB First) для записи данных. Адрес основан на 0. Встроенное ПО использует его в качестве смещения для определения адреса при необходимости при размещении образа в памяти. |
Возможные значения байта Flags описаны в этой таблице.
Таблица 5.5-4 FIRMWARE_UPDATE_OFFER. Пакет команд предложения — значения флагов
| Flag | Имя | Описание |
|---|---|---|
| 0x80 | FIRMWARE_UPDATE_FLAG_FIRST_BLOCK | Этот флаг указывает, что это первый блок образа встроенного ПО. |
| 0x40 | FIRMWARE_UPDATE_FLAG_LAST_BLOCK | Этот флаг указывает, что это последний блок образа встроенного ПО и что образ готов к проверке. Важно, чтобы текущее встроенное ПО компонента выполняло проверку всего загруженного образа встроенного ПО после записи этого блока в энергонезависимую память. |
5.5.1.2 Данные
Таблица 5.5-5 FIRMWARE_UPDATE_CONTENT макет данных команд
Биты FIRMWARE_UPDATE_CONTENT Data описаны в этой таблице.
Таблица 5.5–6 FIRMWARE_UPDATE_CONTENT Биты данных команд
| Битовое смещение | Поле | Size | Описание |
|---|---|---|---|
| 64 | Данные | Максимум 52. | Байтовый массив для записи. Узел обычно отправляет блоки по 4 байта на основе архитектуры продукта. Все неиспользуемые байты в конце должны быть заполнены 0. |
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 — команда — биты ответа
| Битовое смещение | Поле | Size | Описание |
|---|---|---|---|
| 0 | Порядковый номер | 16 | Это поле представляет собой порядковый номер, отправленный узлом в запросе. |
| 16 | Зарезервировано | 16 | Зарезервировано. Не используйте. |
5.5.2.2 Состояние
Таблица 5.5-10 FIRMWARE_UPDATE_CONTENT макет состояния ответа
Биты ответа FIRMWARE_UPDATE_CONTENT (7–4) описаны в этой таблице.
Таблица 5.5–11 FIRMWARE_UPDATE_OFFER — ответ — биты состояния
| Битовое смещение | Поле | Size | Описание |
|---|---|---|---|
| 0 | Состояние | 8 | Это значение указывает код состояния, возвращаемый компонентом устройства. Это не битовое значение и может быть одним из значений, описанных в таблице 5.5–12. |
| 8 | Зарезервировано | 24 | Зарезервировано. Не используйте. |
Возможные значения для байта Status описаны в этой таблице.
Таблица 5.5-12 FIRMWARE_UPDATE_OFFER— ответ — значения кода состояния
| Flag | Имя | Описание |
|---|---|---|
| 0x00 | FIRMWARE_UPDATE_SUCCESS | Запрос успешно выполнен. |
| 0x01 | FIRMWARE_UPDATE_ERROR_PREPARE | Компонент не был подготовлен для получения содержимого встроенного ПО. При использовании этот код обычно используется в ответе на первый блок. Например, стереть ошибку во время флэш-памяти. |
| 0x02 | FIRMWARE_UPDATE_ERROR_WRITE | Запросу не удалось записать байты. |
| 0x03 | FIRMWARE_UPDATE_ERROR_COMPLETE | Запросу не удалось настроить переключение в ответ на FIRMWARE_UPDATE_FLAG_LAST_BLOCK. |
| 0x04 | FIRMWARE_UPDATE_ERROR_VERIFY | Сбой проверки DWORD в ответ на FIRMWARE_UPDATE_FLAG_VERIFY. |
| 0x05 | FIRMWARE_UPDATE_ERROR_CRC | Сбой CRC образа встроенного ПО в ответ на FIRMWARE_UPDATE_FLAG_LAST_BLOCK. |
| 0x06 | FIRMWARE_UPDATE_ERROR_SIGNATURE | Сбой проверки подписи встроенного ПО в ответ на FIRMWARE_UPDATE_FLAG_LAST_BLOCK. |
| 0x07 | FIRMWARE_UPDATE_ERROR_VERSION | Не удалось проверить версию встроенного ПО в ответ на FIRMWARE_UPDATE_FLAG_LAST_BLOCK. |
| 0x08 | FIRMWARE_UPDATE_SWAP_PENDING | Встроенное ПО уже обновлено, и подкачки ожидается. Дальнейшие команды обновления встроенного ПО не могут приниматься до сброса аксессуара. |
| 0x09 | FIRMWARE_UPDATE_ERROR_INVALID_ADDR | Встроенное ПО обнаружило недопустимый адрес назначения в содержимом данных сообщения. |
| 0x0A | FIRMWARE_UPDATE_ERROR_NO_OFFER | Команда FIRMWARE_UPDATE_OFFER была получена без получения действительного и принятого предложения по обновлению встроенного ПО. |
| 0x0B | FIRMWARE_UPDATE_ERROR_INVALID | Общая ошибка для команды 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 — встроенное ПО версии 7.1.3
Основной компонент принимает предложение
Узел отправляет образ встроенного ПО
Основной компонент принимает встроенное ПО и проверяет его
Предложения узла: Идентификатор компонента 2 — встроенное ПО версии 12.4.54
Основной компонент отклоняет предложение
Предложения узла: Идентификатор компонента 3 — встроенное ПО версии 4.5.0
Основной компонент принимает предложение
Узел отправляет образ встроенного ПО
Основной компонент принимает встроенное ПО и проверяет его
Так как все предложения не были отклонены, узел воспроизводит все предложения:
Предложения узла: Идентификатор компонента 1 — встроенное ПО версии 7.1.3
Отклонение компонентов
Предложения узла: Идентификатор компонента 2 — встроенное ПО версии 12.4.54
Отклонение компонентов
Предложения узла: Идентификатор компонента 3 — встроенное ПО версии 4.5.0
Отклонение компонентов
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
Кроме того, реализация требует, чтобы версия встроенного ПО подкомпонентов не была меньше версии встроенного ПО, работающей в основном компоненте. Узел не знает об этом требовании, и он использует основной компонент, чтобы обеспечить это правило.
Последовательность будет:
Предложения узла: идентификатор компонента 1 — версия встроенного ПО 8.0.0
Основной компонент отклоняет (так как идентификатор компонента 3 еще не обновлен)
Предложения узла: Идентификатор компонента 2 — встроенное ПО версии 12.4.54
Отклонение основного компонента
Предложения узла: Идентификатор компонента 3 — встроенное ПО версии 9.0.0
Основной компонент принимает предложение
Узел отправляет образ встроенного ПО
Основной компонент принимает встроенное ПО и проверяет его
Так как все предложения не были отклонены, хозяин воспроизводит все предложения.
Предложения узла: идентификатор компонента 1 — версия встроенного ПО 8.0.0
Основной компонент принимает предложение
Узел отправляет образ встроенного ПО
Основной компонент принимает встроенное ПО и проверяет его
Предложения узла: Идентификатор компонента 2 — встроенное ПО версии 12.4.54
Отклонение основного компонента
Предложения узла: Идентификатор компонента 3 — встроенное ПО версии 9.0.0
Отклонение основного компонента