Разделы

Новое

Беседы про BIOS и UEFI

Утилиты

Реклама

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

Новости

23.11.2016

Инициативы компании Apple по отказу от классических ...

  • Все новости (32)
  • Спонсоры



        Яндекс.Метрика
    Главная » Статьи » Графика и EFI Byte Code

    Графика и EFI Byte Code

    Драйверы оборудования и другое программное обеспечение, написанное на языке виртуальной машины EFI Byte Code, могут выполняться на совершенно различных с точки зрения архитектуры аппаратных платформах. Этот факт важен для совместимости не только программного, но и аппаратного обеспечения, ведь драйвер может находиться в постоянном запоминающем устройстве, расположенном на плате расширения, подключенной к PCI Express или PCI-шине.

    Так что же такое EFI Byte Code? Очередное частное решение очередной частной проблемы или технология создания кросс-платформенных приложений, применение которой может выйти далеко за рамки исходного позиционирования? Наши исследования только усилили данную интригу, ведь полученные результаты свидетельствуют о том, что EBC-ассемблер полнофункционален и пригоден для написания самых различных программ.

    Постановка задачи

    Чтобы проиллюстрировать сказанное, рассмотрим EBC-приложение, выводящее графический объект посредством функций Graphics Output Protocol (GOP). В предлагаемом примере весь экран заполняется белым цветом, яркость которого зависит от координат X и Y. Поверх данного объекта выполняется вывод текстовых строк. Напомним, что работоспособность процедур вывода текста Simple Text Output Protocol не гарантируется после установки произвольного видео режима с использованием Graphics Output Protocol, поэтому алфавитно-цифровые символы визуализируются по такому же принципу, как графические объекты.

    GOP и кросс-платформенность

    Вспомним функциональный состав Graphics Output Protocol.

    Формат интерфейсного блока Graphics Output Protocol
    Рис 1. Формат интерфейсного блока Graphics Output Protocol (GOP)

    Функция Query Mode позволяет получить информацию о возможностях и текущем установленном состоянии видео подсистемы.

    Функция Set Mode используется для установки заданного видео режима.

    Функция BLT (Block Transfer) предоставляет сервис для вывода графических объектов, в частности монотонных прямоугольников или прямоугольных окон, содержимое которых передается данной функции от приложения через буфер в оперативной памяти.

    Элемент Mode адресует таблицу, содержащую параметры видео подсистемы и текущего установленного видео режима.

    О двух моделях GOP-графики

    В рамках протокола GOP существуют две модели программирования графики.

    Первая модель подразумевает, что процедуры GOP используются только для установки заданного видео режима и определения его параметров. Построение графических объектов на экране выполняется путем записи данных непосредственно в видео память, минуя процедуры firmware. Информацию о базовом адресе, размере и форматировании области доступа к видео памяти, приложение получает из таблиц, предоставляемых GOP, одна из таких таблиц — элемент Mode в структуре, показанной на рис.1.

    Вторая модель подразумевает использование процедур firmware без непосредственного доступа к видео памяти. Для этого предусмотрена процедура BLT (Block Transfer), при вызове которой приложение передает координаты вершин, размеры и данные для заполнения прямоугольной области экрана. В этом случае операции с видео адаптером выполняет firmware, а не приложение.

    Для создания кросс-платформенной программы настоятельно рекомендуется использовать вторую модель. Причина очевидна — в устройствах не-PC архитектуры окно доступа к видео памяти может отсутствовать. Для обозначения этой ситуации в таблице параметров видео режима предусмотрен атрибут Blt Only.

    Исходные тексты GOP-тестов

    Программа GOPTest предлагается к свободному распространению без ограничений и пред­ва­ри­тель­ных условий. ZIP-архив с исходным кодом доступен здесь.

    1. Сохранение параметров, передаваемых родительской задачей при запуске приложения: базовый адрес корневой таблицы (EFI System Table) и номер, присвоенный данному приложению (Handle).
    2. Резервирование оперативной памяти для транзитного буфера графического образа экрана. В целях упрощения демонстрационного примера запрашивается фиксированный избыточный размер буфера – 32 мегабайта.
    3. Детектирование протокола GOP с использованием идентификатора GUID посредством функции Locate Protocol.
    4. Определение номера текущего видео режима с использованием GOP и его сохранение для восстановления режима при завершении приложения.
    5. Установка заданного видео режима с использованием GOP, получение его параметров и их сохранение для последующего использования. В целях упрощения демонстрационного примера устанавливается видео режим 0 без возможности выбора. Задать другой режим можно, изменив константу, загружаемую в регистр R3 (строка 207 файла GopTest.asm) и выполнив повторную трансляцию программы.

    Примечание.
    Файлы GOPTEST0.EFIGOPTEST4.EFI, находящиеся в рабочем каталоге являются результатом трансляции программы с заданием номера режима 0-4.

    1. Построение графического объекта в транзитном буфере. Генерируется прямоугольник, размер которого равен размеру растра, а яркость каждой точки определяется ее координатами X и Y.
    2. Построение в транзитном буфере текстовых строк информации о программе.
    3. Подготовка текстовых строк информации о текущем видео режиме: номер режима, разрешение по X и Y. Заметим, что соответствие между номерами режимов и геометрическими параметрами растра не фиксировано и зависит от реализации UEFI firmware. Количество бит на пиксель во всех режимах равно 32, в соответствии с архитектурой Graphics Output Protocol.
    4. Построение в транзитном буфере текстовых строк информации о текущем видео режиме с использованием результатов пункта 8.
    5. Копирование содержимого транзитного буфера в видео память. Используется функция GOP.BLT.Copy. Принципиальный момент: приложение не обращается к видео памяти непосредственно. Функция GOP.BLT.Copy в качестве входных параметров получает координаты базовой (верхней левой) точки отображаемой прямоугольной области, размеры области и указатель на транзитный буфер в оперативной памяти, содержащий данные для визуализации. В нашем примере визуализируемая область – весь экран.
    6. Ожидание нажатия клавиши. Для опроса клавиатуры используется Simple Text Input Protocol.
    7. Восстановление исходного видео режима, номер которого был сохранен при выполнении пункта 4.
    8. Освобождение блока памяти, занятого при выполнении пункта 2.
    9. Возврат в родительскую задачу, в качестве которой может выступать UEFI Shell или UEFI firmware.

    Трансляция и запуск

    Ассемблирование программы и генерация EBC-приложения выполняется с помощью FASM 1.69.50. В исходных текстах используются длинные имена файлов, поэтому, трансляция в среде DOS не предусмотрена. Для ассемблирования инструкций виртуальной машины EBC потребовалось создать набор макросов. Решение об использовании длинных имен было продиктовано желанием обеспечить соответствие имен файлов макроопределений для каждой EBC-инструкции мнемонике данной инструкции.

    После трансляции, в заголовке файла UEFI-приложения, необходимо выполнить патч. А именно, заменить значение поля Machine Type, исходно содержащее 8664h (x86-64 machine) на 0EBCh (EBC machine). Эту операцию автоматически выполняет утилита EBCPATCH.EXE.

    Для последовательного запуска программ FASM.EXE и EBCPATCH.EXE предусмотрен файл ASM.BAT. Утилита EBCPATCH.EXE находится в рабочем каталоге. Путь для запуска FASM.EXE потребуется отредактировать в соответствии с конфигурацией.

    Результат работы программы GOPTest в среде эмуляции UEFI
    Рис 2. Результат работы программы в среде эмуляции UEFI
    с использованием видео режима 800x600

    Резюме

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

    Приложение проверено в средах IA32 EFI и x64 UEFI, оно написано исключительно в системе команд виртуальной машины EBC, не содержит процедур в машинных кодах x86 и обращений к ресурсам платформы PC. Для вывода графики используются функции Block Transfer (BLT), входящие в состав firmware, без применения непосредственного доступа к видео памяти из приложения. Использование такого подхода дает основания предполагать, что пример будет работоспособен на платформах с процессорами Itanium и ARM, поддержка которых оговаривается в спецификации UEFI, но из-за недоступности таких платформ убедиться в этом пока не удалось.



    28.07.2017