Новости

30.08.2017

Российская компания Positive Technologies анонсировала ...

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

    Публикации

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

    Утилиты

    Реклама

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

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

    4. Про UEFI Setup (беседа четвертая)

    Скептик: Мне кажется, что UEFI Setup отличается исключительно оформлением пользовательского интерфейса, а смысл остается неизменным — редактируем состояние опций, выходим с записью, и информация о состоянии опций сохраняется энергонезависимой CMOS памяти с батарейным питанием.

    Энтузиаст: UEFI, как протокол взаимодействия firmware и ОС существенно расширен по сравнению с BIOS. Памяти CMOS уже недостаточно для хранения параметров конфигурации. UEFI позволяет выделять для этой цели специальные области Flash памяти. Это не только увеличивает объем хранимых параметров, но и обеспечивает их сохранность при сбоях батарейного питания.

    Скептик: Выделение в микросхеме BIOS специальных областей для хранения параметров конфигурации начало практиковаться задолго до появления UEFI, еще с середины 1990-х годов. Вспомни сообщения BIOS: Update ESCD, Update DMI Pool. Для этого даже реализована аппаратная поддержка, пример — микросхема Intel 28F001BX. Она разделена на блоки: аппаратно-защищенный Boot блок 8KB, два блока параметров по 4KB и основной блок 112KB.

     

    Реализация протоколов Desktop Management Interface (DMI) и Extended System Configuration Data (ESCD) в традиционном BIOS

     

    Энтузиаст: Протоколы Desktop Management Interface (DMI) и Extended System Configuration Data (ESCD), на сегодня безнадежно устарели. В свое время они были разработаны, для закрывания дыр в несовершенном стандарте Plug and Play, затем, стандарт ACPI поставил все на свои места. Я не видел ни одной платформы, на которой информация DMI полностью соответствовала действительности, но и это не все. Для доступа к заданной DMI структуре, программа должна просканировать все структуры, расположенные в списке перед искомой структурой. На ряде платформ, попытка выполнить такую процедуру вызывала зависание и только утилита, написанная под данную конкретную плату, могла получить и визуализировать DMI параметры.

    UEFI использует сервисные функции Get Variable, Set Variable, реализующие открытый и регулярный протокол для хранения конфигурационных переменных платформы и обмена информацией между firmware и ОС. Вместо условных номеров переменных, различающихся в зависимости от версии BIOS, используются их имена в виде ASCII строк.

    Скептик: Реализовать открытый протокол для хранения конфигурационной информации в Flash ROM можно было и без перехода на новую идеологию. В свое время, при переходе от платформы PC/XT к PC/AT, само появление энергонезависимой памяти CMOS и утилиты CMOS Setup в составе BIOS прошло сравнительно плавно. С чем же связан такой радикализм при переходе от BIOS к UEFI?

    Энтузиаст: Дело не только и не столько в хранении параметров. Одна из целей UEFI — объединение firmware платформы, firmware адаптеров и операционной системы в единую инфраструктуру. Применительно к UEFI Setup, это выглядит как объединение Setup платформы и периферийных адаптеров в единую оболочку. А использование открытых протоколов доступа к параметрам, позволяет расширять возможности редактирования конфигурационной информации с помощью различных утилит запускаемых в сеансе ОС. Вспомни процесс создания RAID-массива, для выполнения которого оператору требуется выйти из Setup платформы и войти в Setup дискового контроллера. Согласись, что удобнее было бы выполнять все операции в единой оболочке.

    Скептик: Но UEFI платформы, в отличие от firmware RAID-контроллера, не содержит процедур поддержки данного контроллера. Как же UEFI Setup платформы будет с ним работать? Или ты предлагаешь превратить UEFI платформы в операционную систему, которая должна содержать все драйвера для всех контроллеров?

    Энтузиаст: Конечно, нет. Это противоречие изящно разрешается с помощью технологии HII (Human Interface Infrastructure или Human Interface Interconnect). Как и раньше, не только низкоуровневые процедуры поддержки дискового контроллера, но и данные, определяющие сценарий пользовательского интерфейса входят в состав firmware контроллера (Option ROM). Сценарий пользовательского интерфейса представляется в виде структур четырех видов: fonts, strings, images, forms. Для передачи сценария от firmware контроллера к firmware платформы используется база данных HII Database. Задача firmware контроллера — внести сценарий своего Setup в эту базу данных. Задача UEFI платформы — сделать этот сценарий частью утилиты UEFI Setup — единой для платформы и всех контроллеров.

    Скептик: Звучит красиво, но думаю, что возможность решения такой задачи под сомнением, так как требует огромных и скоординированных усилий разработчиков платформ, периферийных адаптеров и операционных систем. Это напоминает басню Крылова о лебеде, раке и щуке. vЭнтузиаст: Видимо, перечисленным персонажам все же удалось договориться. Технология Human Interface Infrastructure реализована LSI в системах хранения данных.



    24.09.2017