Новости

02.10.2017

RU.efi, утилита Джеймса Ванга, сотрудника тайваньского ...

  • Все новости (38)
  • Разделы новостей

    Публикации

    Майнеру на заметку

    Утилиты

    Реклама

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

        Яндекс.Метрика
    Главная » Статьи » Беседы про BIOS и UEFI » 3. Про ACPI и EBC (беседа третья)

    3. Про ACPI и EBC (беседа третья)

    Скептик: Анализируя историю развития персональных платформ, прихожу к выводу, что UEFI — это шаг назад. В 16-битные времена, сервис Legacy BIOS был реализован в виде процедур в машинных кодах x86, вызываемых посредством программных прерываний. Затем появилась спецификация ACPI, основная идея которой состоит в том, что firmware декларирует архитектуру платформы и методы выполнения ряда операций на специальном машинно-независимом языке и предоставляет эту информацию операционной системе в виде таблиц ACPI. Было бы логичным дальнейшее движение по этому пути и полный перевод процесса взаимодействия firmware и ОС от процедурной модели к декларативной. Но вместо этого, в спецификации UEFI мы видим многочисленные функции Boot Services, Runtime Services, реализованные как подпрограммы в машинных кодах.

    Граф состояний машины ACPI

    Энтузиаст: Полный переход на декларативную модель является недостижимым идеалом. Подумай о производительности: код x86 аппаратно выполняется процессором, код AML (ACPI Machine Language) программно интерпретируется виртуальной машиной ACPI. Вторая причина — трудоемкость такого перехода. Если у нас есть некий драйвер, написанный в системе команд процессора, то приведение его к виду UEFI обычно является тривиальной операцией. А реализовать тот же драйвер в виде AML означает написать его повторно.

    Скептик: Из такого пояснения следует, что UEFI это компромисс, несовершенный по опре­де­ле­нию, а идея машинно-независимых программно-интерпретируемых языков не прижилась в ми­ре firmware?

    ACPI-драйвер и его роль в управлении платформой

    Энтузиаст: Это не так. ACPI продолжает существование в составе UEFI и используется там, где это оптимально: декларирование конфигурации платформы, устройств и системных ресурсов и конечно, управление энергопотреблением. Да, большинство драйверов UEFI написано в машинных кодах, от этого не уйти, если важна производительность. А идея машинно-независимого firmware успешно продолжила свое существование в виде EBC (EFI Byte Code).

    Скептик: Чем EBC отличается от AML?

    Энтузиаст: Таблицы ACPI, содержащие AML, генерирует BIOS и размещает в оперативной па­мя­ти. Интерпретирует их ОС. Так от firmware к операционной системе передается информация о конфигурации платформы, системных ресурсах и методах выполнения заданных операций. А язык EBC может быть использован для написания модулей UEFI (драйверов, приложений, Adaptor ROM), которые будут совместимы с любой платформой, независимо от типа цент­раль­но­го процессора, если в составе firmware данной платформы есть интерпретатор EBC. Этот подход уже реализован на практике в контроллерах систем хранения данных компании LSI. Результат — универсальное firmware контроллера, которое может использоваться для плат­форм x64 и Itanium.

    Скептик: Хорошо, EBC успешно решает проблему совместимости на уровне системы команд процессора. А периферия? Простой пример - программа, обращается к клавиатуре для ввода символов, а подключена только мышь. Польза от EBC сведется к обеспечению выполнения вечного цикла ожидания ввода с несуществующей клавиатуры?

    Энтузиаст: Разработчики UEFI предусмотрели ряд решений, обеспечивающих единые про­то­ко­лы взаимодействия с различной периферией. Например, технология HII (Human Interface Infrastructure или Human Interface Interconnect) определяет унификацию человеко-машинного интерфейса. Вернемся к твоему примеру — программа, использующая HII, не будет привязана к конкретному устройству - клавиатуре или мыши, так как использует универсальный протокол получения информации о вводе. Здесь снова можно привести в пример контроллеры LSI, firmware которых поддерживает HII.



    17.11.2017