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

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-шины

Дешевый ценовой сегмент заполнили устройства, преимущественно китайского производства, большинство из ко­то­рых практически непригодны к эксплуатации, так как являются примером проектирования 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. Так как ар­хи­тек­ту­ра De­bug Port уни­фи­ци­ро­ва­на и определяется спецификацией EHCI, используя программные ин­с­тру­мен­ты для работы с кон­фи­гу­ра­ци­он­ными ре­гист­ра­ми, ис­сле­до­ва­тель может определить наличие данной фун­к­ци­о­наль­но­с­ти, даже не рас­по­ла­гая до­ку­мен­та­ци­ей на чипсет.

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

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

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

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

 

Debug Port в составе USB-контроллера

Debug 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)

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

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

Резюме

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