USB Debug Port: новые возможности диагностики

13 Мар 2013

USB Debug Port: новые возможности диагностики

Процедура старта компьютера называется POST (Power-On Self Test), в ходе ее происходит последовательная подготовка различных подсистем аппаратной платформы к запуску операционной системы. Простая идея, благополучно пережившая более десятка поколений процессоров, что применяется до сих пор, — перед выполнением каждого этапа, ге­не­ри­ро­вать диагностический POST-код. В случае не­стар­та платформы его сле­дует считать кодом ошибки, а по спис­ку расшифровки POST-кодов сер­вис­ный инженер определит предполагаемую причину аварии.

 

POST-коды стали контрольными точками состояния компьютера, и благодаря этому используются в индустрии пер­сональных платформ уже более 30 лет. За ними был закреплен диагностический порт с адресом 0080h, ко­то­рый оставаясь неизменным пережил даже BIOS и на законных правах теперь существует в UEFI.

Казалось, что POST-диагностика останется неизменной еще много лет, однако концепция Legacy-free требует пе­ре­хода к другим технологиям.

POST-диагностика в контексте эволюции шин

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

  • адресного дешифратора, детектирующего вывод в порт 0080h;
  • регистра-защелки, фиксирующего выведенный байт;
  • дисплея, отображающего POST-код на индикаторе.

Первые POST-карты использовали ISA в качестве шины расширения. Начиная с 1999 года, ведущие разработчики системной логики стали предлагать решения, использующие наиболее продуктивную на тот момент PCI-шину. Про­двинутые PCI POST-карты не ограничились формальным «переездом» порта 0080h на новую шину. Они ис­поль­зо­ва­ли все архитектурные особенности PCI для реализации пошагового режима, расширенной разрядности самих диагностических кодов и т.п.

POST-карта для PCI-шины
Рис. 1. POST-карта для PCI-шины

Дешевый ценовой сегмент заполнили устройства, преимущественно китайского производства, большинство из которых практически непригодны к эксплуатации, так как являются примером проектирования PCI-устройства с использованием идеологии ISA-шины.

Когда на основе программной модели PCI появилась шина PCI Express, казалось, что эволюция диагностических устройств обязательно последует в том же направлении. Но так не произошло. Почему? Во-первых, поменялась ситуация на рынке: мобильные решения агрессивно вытесняют настольные компьютеры. А для компактных систем слоты PCI Express даже в мини-формате — непозволительная конструктивная роскошь. Во-вторых, вспомним, что топология PCI Express обеспечивает соединение «точка-точка», которое затрудняет трансляцию циклов вывода в порт 0080h на каждый слот.

В сложившейся ситуации достойным кандидатом для организации диагностического порта оказалась шина USB. Дополнительным бонусом ее использования является мониторинг состояния платформы снаружи (без доступа к системной плате).

Bus Master как препятствие для POST-диагностики

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

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

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

  1. Вывод POST-кодов невозможен до момента инициализации подсистемы оперативной памяти;
  2. Вывод POST-кодов невозможен при неисправной или отсутствующей оперативной памяти;
  3. Процедура вывода POST-кодов, использующая режим Bus Master, имеет меньше шансов на безошибочное выполнение в случае неисправной платформы. Значит, сервисный инженер имеет меньше шансов увидеть диагностический код на экране POST-карты.

Архитектура USB Debug-порта в составе EHCI-контроллера

Задача, поставленная перед разработчиками USB Debug-порта очевидна из выше сказанного – реализовать некий специальный протокол работы контроллера USB, при котором режим Bus Master не используется, а данные для вы­во­да в диагностический порт передаются контроллеру USB центральным процессором. И такой протокол был разработан. С его особенностями можно ознакомиться в презентации «USB 2.0 Debug Port» Джона Кейза , ин­же­не­ра компании Intel.

  1. Для работы в качестве Debug Port используется один из портов контроллера USB 2.0 EHCI. Функция опци­о­наль­на, ее наличие декларируется структурой Debug Port Capability, расположенной в блоке конфи­гу­ра­ци­он­ных регистров EHCI-контроллера. Указанная структура также содержит информацию, необходимую для локализации memory-mapped регистров контроллера Debug Port.
  2. Debug Port не использует режим Bus Master, поэтому для него не требуется оперативная память. Расписание транзакций и его дочерние структуры не используются.
  3. В регистрах memory-mapped I/O контроллера Debug Port реализован буфер, размером 8 байт. При отправке данных на Debug Device процессор заполняет буфер и дает команду на запуск операции. При чтении данных из Debug Device процессор ожидает завершения операции, после чего читает данные из буфера. Управление USB-операциями осуществляется программно, посредством регистра Debug Port Control / Status Register.
  4. Подключаемое устройство – Debug Port Device, должно соответствовать спецификации на такого рода пери­фе­рию и поддерживать режим USB 2.0 High Speed (480 Mbit/s).
  5. Как следует из размера буфера, для работы Debug Port Device не должны использоваться передачи данных длиной более 8 байт. Базовая функциональность при взаимодействии устройства с хостом включает опе­ра­ции чтения структуры Debug Descriptor, описывающей конфигурацию Debug Device, которую обеспечивают каналы ввода (Bulk-In endpoint) и вывода (Bulk-Out endpoint) данных .

Особенности реализации

В модельном ряду чипсетов Intel возможность использовать Debug Port впервые появилась в 82801DB (ICH4) — южном мосте, входящем в ряд модификаций набора системной логики Intel 845. Так как архитектура Debug Port унифицирована и определяется спецификацией EHCI, используя программные инструменты для работы с кон­фи­гу­ра­ци­он­ными регистрами, исследователь может определить наличие данной функциональности, даже не рас­по­ла­гая документацией на чипсет.

Встречаются платформы, где южный мост поддерживает Debug Port, но в сеансе ОС мы не обнаруживаем стру­к­ту­ру Debug Port Capability. Это связано с тем, что в ряде чипсетов, декларированием данной функциональности мож­но дополнительно управлять, посредством «теневых» конфигурационных регистров, которые инициализирует BIOS при старте платформы. В этом случае, без документации на чипсет уже не обойтись, иначе, мы зависим от того, в каком состоянии оставил BIOS ресурсы платформы при старте ОС.

С помощью программного обеспечения можно увидеть EHCI Debug Port в сеансе ОС, а заодно и определить, какой из USB-портов используется в данном качестве:

Структура Debug Port Capability для декларации отладочного порта
Рис 2. Структура Debug Port Capability для декларации отладочного порта

Debug Port в составе USB-контроллера
Рис. 3Debug Port в составе USB-контроллера

Новые профессии отладочных портов

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

  1. Вывод отладочных кодов может происходить уже после завершения процедуры POST. При этом отладка распространяется на модули firmware, функционирующие в сеансе ОС. Контрольные точки могут быть реализованы в составе процедур UEFI Runtime Services, вызываемых в рабочем сеансе, а также в коде AML (ACPI Machine Language), находящимся в состав firmware и интерпретируемом ACPI-машиной операционной системы.
  2. Инициатором вывода контрольных точек может быть сама операционная система или приложения. Такая технология отладки особенно актуальна при написании драйверов уровня ядра (Kernel Mode Drivers), поскольку контекст, в котором они выполняются (Ring 0), как правило не допускает вывода на экран штатными средствами.

Для систематизации номенклатуры отладочных устройств и методов их применения, в рамках интерфейса ACPI определена таблица DBGP (Debug Port) на смену которой, пришла таблица DBG2.

Расшифровка полей Port Type и Port Subtype таблицы Microsoft Debug Port Table 2 (DBG2)
Рис.4 Расшифровка полей Port Type и Port Subtype таблицы Microsoft Debug Port Table 2 (DBG2)

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

Резюме

Диагностические коды будут доступны на USB-порте только в том случае, если разработчики BIOS обеспечили их вывод. К сожалению, большинство существующих на сегодня реализаций BIOS для персональных платформ не обладают такой функциональностью. Но Debug Port присутствует во всех чипсетах Intel, от ICH4 до современных PCH, в этом можно убедиться как по документации, так и путем просмотра конфигурационных регистров чипсета в сеансе операционной системы. Очевидна аналогия с «ружьем, висящим на стене», которое, как известно, обя­за­тель­но должно выстрелить.