Сначала было слово. И слово было размером в два байта. Именно их следовало бы вывести в диагностический порт для отладки первой компьютерной программы. Ведь еще процессор i8086 поддерживал флаг трассировки или Trap Flag (TF), при установке которого в «1» генерируется прерывание после выполнения каждой инструкции. Точки останова можно было реализовать и с применением однобайтовой инструкции INT3. Вспомним и «прадедушку» современных средств виртуализации — Turbo Debugger 386 фирмы Borland, в основе работы которого был режим Virtual 8086 mode.
Появление 32-битного процессора Intel 80386 принесло новые средства для трассировки кода — регистры отладки или Debug Registers (DR0…DR7). Оглядываясь назад, следует признать, что их использование не стало массовым. Навскидку, можно указать только утилиты PhDebug и Phoenix Debugger, активно использующие отладочные регистры.
Именно дебаггер от Phoenix Technologies стал идеальным отладчиком. Все до него существовавшие инструменты имели один общий и существенный недостаток — отладчик запускался на том же компьютере, что и отлаживаемая программа. Он использовал те же ресурсы и неизбежно влиял на системный контекст. А, как известно, идеальный отладчик — это такой отладчик, наличие которого отлаживаемая программа даже не замечает.
Функциональность трассировщиков от Phoenix построена на передаче информации по последовательному (вариант — параллельному) порту на удаленный инструментальный компьютер. Где дебаггер, собственно, и выполняется, обрабатывая поток данных с отлаживаемой платформы, что особенно важно при разработке низкоуровневого программного обеспечения, например, процедур BIOS POST или UEFI Platform Initialization. Там разработчик сталкивается с особой проблемой, когда на ранних этапах старта еще не готова к работе оперативная память, видеоадаптер и другие ресурсы, доступные в сеансе операционной системы.
Ответом на данные требования и явился перенос выполнения отладчика с отлаживаемой на инструментальную платформу. А для того чтобы такая конструкция заработала, два указанных компьютера должны быть связаны неким интерфейсом. Сегодня, выбор разработчиков останавливается на универсальной последовательной шине. Основные причины для этого следующие:
- Порт USB доступен без вскрытия компьютера, что особенно актуально для мобильных устройств;
- С помощью USB Debug Port становится возможной отладка BIOS и UEFI;
- Разработан механизм для подключения к USB-шине диагностических устройств;
- Не требуется специальных шин и интерфейсов — используется USB-порт, являющийся на сегодня повсеместно распространенным стандартом.
Не последним аргументом служит и тот факт, что для реализации указанного подхода IT-индустрия предлагает несколько интересных в архитектурном плане решений. Одно из них — USB2.0 Host-to-Host Networking Controller производства ALI Corp. — в связи со сложностями, постигшими производителя, так и не нашло применения. Рассмотрим подробнее элементную базу, используемую для дизайна других отладчиков программного обеспечения.
Insyde H2O DDT
Итак, к замене традиционных средств диагностики одной из первых приступила компания Insyde Software, находящаяся под благотворным влиянием идей и финансирования Intel. В презентации «Debugging under Unified Extensible Firmware Interface (UEFI): Addressing DXE Driver Challenges» один из инсайдеров разработки Джефф Бобзин (Jeff Bobzin), к слову, состоящий в управленческом штате с момента оборазования компании, рассказал о причинах бренднига отладочного устройства.
Комплекс для трассирования кода UEFI BIOS получил инсектицидное название, потому что этимология слова bug в вычислительной технике восходит к проблеме контактов реле, нарушенных тараканами. Как бы там ни было, диагностический комплекс Insyde H2O DDT появился в другое время, и в качестве интерфейса использует USB-шину.
Рис 1. Джефф Бобзин (Jeff Bobzin) — в центре (фото с сайта IC Book Labs).
В описании устройства Insyde Software акцентирует внимание на возможности установки breakpoints — точек останова в отлаживаемой программе. Очевидно, такая функциональность требует двунаправленного трафика через мост USB-USB, и это явно следует из презентации. Еще одна полезная подробность презентации — использование встроенных в низкоуровневый код драйверов H2O DDT.
Пожалуй, на этом все откровения от Insyde заканчиваются, а наше исследование продолжается, но уже в другом направлении: добытый из исходного кода GUID диагностического устройства содержит шестнадцатеричную константу 0x11d4, которая указывает направление поиска.
Поиск дает два результата. Первый из них тот, что GUID с кодом 0x11d4 используется в программном обеспечении USB-контроллера Cypress CY7C68013A (давно уже снят с производства, ему на смену пришел аналогичный контроллер CY7C68014A). Второй — самодельная POST-карта для USB-шины, информация о которой опубликована на сайте CoreBoot. Этот DIY USB Dongle, как и положено прототипу, собран своими руками и позиционируется под девизом Do It Yourself, хорошо известному в переводе на русский, как «Сделай сам!».
Вкратце идея трассировщика такова: для организации моста между инструментальным компьютером и Target-платформой, используется устройство на основе двух модулей USB-интерфейса. Каждый из модулей, как уже было сказано выше, построен на основе контроллера Cypress CY7C68013A. Модули с помощью специального линка создают соединение двух платформ, обеспечивающее визуализацию диагностической и отладочной информации на мастер-компьютере. Тем, кто захочет изготовить самодельный дебаггер с функциями USB POST-карты, пригодятся рекомендации производителя чипов.
Полезной может оказаться и фирменная утилита от Insyde Software под названием DebugEngineSetup, скриншот которой приводится просто для привлечения внимания :)
AMIDebug™ Rx
Пожалуй, самое мощное средство POST-диагностики вывела на рынок компания American Megatrends. Дебаггер с несколько странным названием AMIDebug Rx, в отличие от аналогичного устройства Insyde H2O DDT, разработан для обслуживания как своих собственных программных продуктов (AMIBIOS8, Aptio), так и платформ сторонних разработчиков. Естественно, что функции трассировщика доступны в этом девайсе только для проприетарных UEFI BIOS.
Устройство AMIDebug Rx, в терминах обозначенного в предисловии подхода, позволяет реализовать три сценария отладки, описанных в «Руководстве пользователя» (стр. 8):
- Устройство подключается к USB порту отлаживаемого компьютера, работая в качестве небольшого инструментального компьютера, и позволяет визуализировать на собственном LCD дисплее диагностическую информацию: BIOS Checkpoints или UEFI Debug Strings. Эта информация может быть сохранена в памяти устройства в виде отладочной сессии.
- Устройство, в памяти которого находится ранее сохраненная отладочная сессия, подключается к инструментальному компьютеру для ее просмотра и анализа. В этом режиме также может быть выполнено конфигурирование устройства AMIDebug Rx и обновление его Firmware.
- AMIDebug Rx выполняет функцию моста между инструментальным и отлаживаемым компьютерами. Это наиболее комфортный режим, позволяющий выполнять отладку в режиме on-line, причем с просмотром исходного текста программы (используется программное обеспечение AMIDebug for UEFI и AMIDebug for AMIBIOS8 в режиме source-level debugging).
Рис 2. Соединение инструментального компьютера (Remote Machine) и отлаживаемого компьютера
(Target Machine) по мостовой схеме согласно Debug Device Specification.
Подробности реализации AMIDebug Rx
Дебаггер от American Megatrends оборудован двумя USB-разъемами, совершенно неравноценными и в функциональном и в архитектурном планах, что следует из документации. Если с одним разъемом все просто, то второй представляет из себя полную загадку.
Начнем с очевидного: хотя в качестве интерфейса конфигурирования и доступа к NVRAM используется USB, совершенно ясно, что для работы с AMIDebug Rx потребуется терминал. В связи с тем, что начиная с Windows Vista ничего подобного в поставке микрософтовских операционных систем нет, терминальным клиентом придется запастись заранее. Это может быть Гипертерминал, использовавшийся в ранних версиях Windows, либо рекомендуемый AMI продукт под названием Ayera TeraTerm.
Такая особенность отладчика объясняется тем, что у контроллера AMIDebug Rx есть только последовательный порт, но нет USB-интерфейса. Задачу преобразования решает USB-to-UART мост CP2102, производства Silicon Labs. Этот чип уже знаком потребителям по продукции IC Book Labs и зарекоментовал себя, как надежное решение для организации COM-портов, подключаемых к USB-шине.
Что используется в качестве автономного процессора в USB POST-карте AMI, до недавнего времени было скрыто от посторонних глаз. Но последние исследования показали — это чип производства NetChip Technology, идентифицируемый параметрами USB Vendor ID = 0525h, USB Device ID = 127Ah. Именно он реализует подключение к EHCI-порту исследуемой платформы, представляясь ей как USB 2.0 Debug Connection Device. Документация на этот контроллер недоступна не сайте компании NetChip, которая с недавних пор вошла в состав PLX Technology.
Еще одно устройство на NetChip
Обзор диагностических контроллеров был бы неполным, если бы мы не упомянули дебаггер NET20DC, производства мало кому известной компании Ajays Technology. Мы бы об этом устройстве так никогда бы и не узнали, если бы не информация, полученная от тех, кто сумел его купить, протестировать и выложить в интернет идентифицирующие его даные.
Парадокс ситуации в том, что NET20DC оснащен тем же чипом от NetChip, что и AMIDebug Rx. Это документально следует из приведенной выше ссылки на дескрипторы USB-контроллера. Ничего лучше детективной версии в объяснение этого совпадения на ум не приходит. Попытка купить онлайн отладчик NET20DC упирается в формулировку, что в данный момент устройств на продажу нет по причине их редизайна.
Что в итоге?
Наблюдательный читатель заметит, что ни одно из описанных в обзоре диагностических устройств не представлено в свободной продаже. Почему? — Об этом читайте в следующих публикациях «Компостера».