Продолжаем знакомство с новыми возможностями недавно вышедших из под пера UEFI Forum стандартов, и если в предыдущей части речь шла о внутреннем стандарте PI, то на этот раз она пойдет об ACPI 6.0 и его отличиях от предыдущей версии 5.1.
Если вам интересно, что именно изменилось за 10 месяцев разработки стандарта, и какими новшествами нас порадуют или огорчат будущие системы с поддержкой ACPI 6.0 — добро пожаловать под кат.

Что вообще такое ACPI

ACPI или Advanced Configuration and Power Interface — это открытый стандарт на взаимодействие ОС и прошивки, разработанный совместно инженерами Hewlett-Packard, Intel, Microsoft, Phoenix и Toshiba. Первый релиз вышел в декабре 1996 года и включал в себя как улучшенные аналоги APM, MPS и PnPBIOS, так и собственные наработки для обнаружения подключенного оборудования, мониторинга, управления питанием и охлаждением.
Интерфейс ACPI практически независим от архитектуры целевой машины и состоит из множества таблиц, которые содержат либо данные (информацию SMBIOS и DMI, например, или лицензионный ключ для Windows 8), либо код на языке AML. Код этот выполняется специальным драйвером-интерпретатором, который обязан присутствовать в каждой ACPI-совместимой ОС. Первой такой ОС была Windows 98, но реализация ACPI в те времена хромала на обе ноги как со стороны разработчиков BIOS'ов, так и со стороны MS, и потому до Windows Vista (и ядра Linux 2.6.0, если взглянуть по другую сторону баррикад) интерфейс фактически не использовался.
Тем не менее, стандарт быстро стал популярным (не обошлось без давления со стороны Intel и Microsoft) и пережил уже 6 редакций. В версии 2.0 добавили поддержку 64-битных процессоров, в 3.0 — SATA, PCIe, управления температурой компонентов (т.е. не только CPU) и больших многопроцессорных систем, в 4.0 — USB3 и x2APIC, в 5.0 — GPIO, простых периферийных шин (I2C, SPI, UART) и управления питанием памяти.
На данный момент сильнее всего ACPI задействован в MacOS X, десктопные и серверные редакции Windows тоже требуют от BIOS'а наличия поддержки как минимум ACPI 2.0, а Linux и FreeBSD по прежнему могут без особых проблем работать без ACPI, но используют интерфейс, если его удалось обнаружить.

ACPI 6.0

С момента выпуска предыдущей версии 5.1. прошел почти год, но каких-то радикальных изменений в новом стандарте не случилось, что позволит производителям прошивок реализовать его поддержку в достаточно короткие сроки.
Для начала я перечислю все заметные изменения, а потом уже постараюсь дать развернутый комментарий по каждой группе. Поехали!

Поддержка NVDIMM
Support for Non-Volatile Memory Firmware Interfaces — добавление новой ACPI-таблицы NFIT, из которой ОС сможет узнать, на какие именно части адресного пространства CPU отображена NVDIMM и как именно ОС может ей воспользоваться. Для чего это нужно и почему это здорово — читайте ниже.
Extended Vendor Range for E820 Address Types and UEFI Memory Types — добавление новых типов памяти для старой (E820) и новой (UEFI MemMap) карт памяти, в дополнение к NFIT для тех ОС, который о ней еще пока слыхом не слыхивали.
Persistent memory S4 behavior — возможность использовать NVDIMM вместо S4 data storage, что избавит пользователей Windows от файла hiberfil.sys, да и вообще несколько размоет границу между S3 (он же Sleep) и S4 (он же Hibernate) для обычного пользователя.

Поддержка USB-C
Add USB-C Connection support to _UPC — теперь у каждого USB-порта можно узнать, является ли он портом USB Type C и если да, то какие именно новые режимы поддерживает.

Обновление для языка ASL
ASL: Printf and Fprintf Debug Macros — новые макросы для форматного вывода, сильно упрощающие написание отладочного кода на ASL (до этого приходилось городить километры вложенных Concatenate).
ASL: Helper Macro ToPLD() — еще один полезный макрос, позволяющий заполнять объекты типа _PLD, которые используются для описания физического положения устройств в системе (т.е. что-то вроде «порт USB3 — первый слева во втором ряду портов на задней панели»), и который до этого заполнялся серией вызовов Store (с возможностью забыть заполнить часть полей и переписать уже заполненные).
ASL: Extensions for Symbolic Operators and Expressions (ASL 2.0) — невероятно замечательное изменение, после которого код на ASL станет вдвое приятнее писать и вдесятеро приятнее читать, ведь теперь вместо Add(X, Y, Z) можно писать Z = X + Y, а вместо LGreaterEqual(X, Y) — X >= Y. Я джва года ждал такую игру, блин!

Температуры, питания и производительность
Standby Thermal Trip — возможность при сильном превышении температуры какой-либо части платы перейти в S3 вместо полного отключения, что позволит потерять меньше данных.
Adding Support for Faster Thermal Sampling — возможность для производителя платы указать период опроса датчиков температуры (минимальное значение — 0,1 с), которой не было ранее. Позволит улучшить скорость реакции драйвера OSPM на изменения температуры компонентов.
Adjust max p-states — поддержка более 16 промежуточных состояний питания (по простому — пар «множитель CPU — желаемое напряжение») для находящейся под нагрузкой (т.е в состоянии С0) системы. Позволит точнее сэкономить еще немного энергии на мобильных ПК.
ACPI Low Power Idle Table and _LPD proposalновые таблица и метод для перехода в энергосберегающие состояния LPI. Работают они пока только на Haswell и более новых процессорах Intel, только в Windows и только при наличии Intel Power Engine Plug-in, так что пока толку от этого новшества не много.
CPPC heterogeneous performance capabilities — поддержка технологии CPPC от Intel. Еще один способ управления нагрузкой, в добавок к десятку уже имеющихся. Тоже только для Haswell+, но на этот раз драйвером для Linux не обделили.

Поддержка архитектуры ARM
Reserve IORT and support for ARM GICv3/4 in MADT — название таблицы IORT зарезервировано для будущих версий стандарта, поддержка контролера прерываний ARM GIC добавлена в MADT. Шаг за шагом UEFI Forum добавляет поддержку ARM в свои стандарты, еще пара лет, и на ARM-системах с UEFI и ACPI начнет стартовать десктопная Windows…

Остальное
Reserve STAO and XENV table signatures — парочка таблиц зарезервирована для добавления в будущие версии стандарта. STAO позволит драйверу OSPM игнорировать некоторую часть кода ACPI (что может понадобиться, к примеру, на китайских планшетах, где в ACPI зачастую творится трэш, угар и содомия, а просто дропнуть все таблицы целиком во время загрузки ОС — слишком радикально), а XENV нужна гипервизору Xen для передачи данных в Dom0.
FADT Hypervisor Vendor Identification Support — новое 64-битное поле в таблице FADT, в котором гипервизор может сообщить ОС о своем присутствии и типе.
Support for Platform-specific device reset — поддержка нового типа ресетов, о которой я уже писал в первой части.
Generic Button(s) Abstraction — напоследок, еще одна приятность уровня ASL 2.0, которую я ждал те же джва года, поддержка кнопок для любых целей, а не только Power/Reset/Lid/Sleep. Никаких больше кривых драйверов, вызывающих SMI на каждый чих, никакой регулировки громкости через DMI, один раз кнопкам пишется ASL-код и они работают из коробки.

Совсем немного про NVDIMM

Обещал рассказать, чем поддержка NVDIMM чревата простому пользователю — и расскажу.
Даже без самой NVDIMM (о плюсах которой можно почитать, например, здесь) таблица NFIT позволит прошивке отобразить любой непрерывный файл в память и сообщить ОС, что он там и что с него можно загрузиться. Это, в свою очередь, позволит UEFI загружаться не только с физических носителей, но и из ISO-образов, с виртуальных дисков, с любых блочных устройств (даже без ФС) и т.п. Фишку, скорее всего, подсмотрели у GRUB'а, который так умеет уже лет десять, но она от этого не становится менее полезной.

Заключение

В отличие от PI 1.4, в котором почти ничего интересного и не было, в новой версии ACPI добавилось несколько приятных как пользователю (NFIT, кнопки, USB-C), так и разработчику (ASL 2.0, новые макросы, больше возможностей для контроля температуры) вещей. Ну и самих себя UEFI Forum не обделили, добавив скопом все недавние энергосберегающие технологии Intel и оставив задел на будущую версию для ARM и Linaro.
Ждем теперь, когда производители UEFI-платформ (т.е AMI, Phoenix и Insyde) объявят и поддержке ACPI 6.0 в своих продуктах.

P.S.
Извиняюсь за обилие аббревиатур, но иначе тут никак.
Спасибо за внимание, удачных вам прошивок.

Комментарии (5)


  1. Adnako
    17.06.2015 08:15
    +7

    а Linux и FreeBSD по прежнему могут без особых проблем работать без ACPI

    Немного не так, линуксы не используют ACPI потому, что вынуждены работать в реальных условиях т.к. производители материнок по большей части заполняют таблицы на «отвяжись» — все привыкли к тому, что Windows сама их железо из драйверов определит и настроит и поэтому в таблицах — зияющая пустота и куски блобов.
    Более того — существует как минимум две версии компилятора описания этих таблиц. И версия от микрософт, следуя всем канонам, «немножечко» другая! Т.е. код успешно компилируемый микрософтным компилятором зачастую невозможно скомпилировать интеловым, который честно старается придерживаться стандартов. Соответствующим получается и биос/уефи, попробуй определи, что за железо тебе дали и почему это оно не реагирует на закрытие крышки или на воткнутые наушники.


    1. CodeRush Автор
      17.06.2015 08:31
      +4

      Тем не менее, даже с опцией acpi=off ядро успешно загружается и работает. И то, что Linux не использует «свой» набор данных из метода _OSI — это факт.
      Про «на отвяжись» я уже однажды на ГТ писал:

      Примерно 80% ASL-кода пишется производителем CPU (которому плевать на warning'и), еще по 10% — IBV и конечным вендором (и будь они хоть кем, их код — капля в море). Да и если большая часть современных ОС на недоработки ACPI все равно плевать хотела (а серьезно пользуется им только OSX), то и отношение к технологии — соответствующее. Пока оно работает хоть как-то — никто ничего трогать не будет, работы хватает и без этого.
      Ситуация понемногу улучшается, но медленно. Посмотрим, что будет в новых прошивках.
      От использования любых других компиляторов кроме Intel IASL отказались пару лет назад, когда стандарт ACPI был передан UEFI Forum на сопровождение. А после внедрения ASL 2.0 этот компилятор — вообще единственный, который способен собрать из нового кода что-то работающее.


  1. JerleShannara
    17.06.2015 13:38
    +1

    О, такими темпами скоро можно будет снять древнюю мЭдальку «Самый худший стандарт в истории ПК» с ACPI. Линуксу отдельное спасибо за пофигизм в отношении ACPI, особенно за работу с PnP устройствами — какое удовольствие было разбираться, почему линукс видит клавиатуру, а вот винда — фиг там.


    1. CodeRush Автор
      17.06.2015 13:50

      Да, нетребовательность линукса к ACPI позволяет этот самый код ACPI отлаживать в нем без особого бубна. Я бы не назвал ACPI самым худшим стандартом (IEEE 1149.7 уверенно держит марку, на мой взгляд), но и хорошим его пока нызвать тоже рано. Будем посмотреть, возможно руками UEFI Forum из ACPI получится сделать что-то удобоваримое.


      1. justaguest
        17.06.2015 23:02

        А я по сей день считал другой стандарт худшим (старые версии) — из сказания о великом противостоянии OpenGL и DirectX.