Acpi driver что это
Несколько лет назад, когда CardBus и FireWire (IEEE 1394) еще были относительно «в ходу», многие производители ноутбуков в своей продукции использовали контроллеры семейства PCIXX21 и PCIXX11 фирмы Texas Instruments: один небольшой чип обеспечивал поддержку не только упомянутых интерфейсов, но и многих популярных стандартов сменных карт памяти.
Такой чип (а именно, PCI7411) стоит и в моей NEC Versa S950. Этот малоизвестный ноутбук я в свое время предпочел даже ThinkPad-серии практически исключительно из-за более лучшей поддержки FreeBSD (оборудования в целом и спящего режима в частности) — специально тестировал в новосибирском Техносити перед покупкой. Долгое время я не пользовался встроенным кард-ридером, по привычке обходясь USB'шными «свистками». Но недавно я обнаружил, что FreeBSD до сих пор его не поддерживает. И если лет пять-шесть назад это можно было объяснить отсутствием нормального драйвера для этих контроллеров (нужно было что-то скачивать и собирать самому), то теперь я точно знал, что они «из коробки» поддерживаются во FreeBSD драйвером sdhci(4) , о чем прямо сказано на странице руководства (и позже подтвердилось чтением исходников).
Я начал неспешно гуглить на эту тему, и картина стала вырисовываться невеселая. Оказалось, что таких «счастливчиков», как я, немало. Многие постили в рассылки и форумы «портянки» dmesg и pciconf -lv , заводили баги в трекерах (например, OpenBSD PR i386/5843), но решения никто не предлагал. Более того, фактически поставив точку в вопросе, Александр Мотин, автор драйвера sdhci(4) , в 2010 г. написал на форуме, что-де TI документацию на чип не дают, а значит, если производитель сконфигурировал чип неверно, а его настройка через BIOS не предусмотрена, сделать что-либо затруднительно. В свою очередь, Theo de Raadt закрыл i386/5843 со словами: «We do what we can. This vendor, amongst other, have their sdhc controllers locked out and hidden behind little undocumented bits. We've strugged before to find this information, and failed. If you can find this information on some other operating system, or in some vendor documentation, we would be thrilled.»
В отчаянии я загрузился с Ubuntu LiveCD. И очень удивился тому, что в Linux кард-ридер работает. Значит…
Результат
Прежде всего, обратим внимание, что контроллер 0x803 3 104c (FlashMedia) исчез из вывода pciconf -lv , зато появился 0x803 4 104c (SD Host). Загружаем нужные модули ядра, вставляем карточку и пробуем примонтировать ее:
Вроде все работает, ну и славно. Можно убирать отладочный код из DSDT и наслаждаться жизнью пользоваться кард-ридером.
За дело
Для начала посмотрим, что нам скажет утилита pciconf(8) про PCI configuration space «головной» (нулевой) функции чипа, т.е., в терминологии FreeBSD, селектора pci0:6:7:0 . Ради краткости я не буду приводить дамп всех 256 байт, а ограничусь лишь интересующим нас, по смещению 86h:
Интересно. Смотрим в табличку на 65-й странице pdf'ки, видим, что тройка в нижнем нибле (полубайте) равна типичному значению бит, отвечающих за top level arbitration, SmartCard socket power control и OHCI 1394, это нас мало интересует. А вот верхний нибл как раз маскирует (включает-выключает) логику остальных контроллеров (таблицу целиком не привожу опять же для экономии места):
0xD это 1101, т.е. установлены биты DISABLE_SC, DISABLE_SD и DISABLE_SKTB, а бит DISABLE_FM сброшен. Следовательно, чтобы «оживить» контроллер SD Host, нам, по логике, надо сбросить DISABLE_SD (разрешить), а DISABLE_FM, напротив, выставить (запретить). Маске 1011 соответсвует значение 0xB, т.е. по сути, нам надо поменять байт 0xD3 на 0xB3. Проблема, однако, в том, что сделать это нужно сильно заранее, до того, как чип будет проинициализирован, вернее, до того, как он определит, какие контроллеры включать. После того, как система загрузилась, менять конфигурацию бесполезно: все устройства уже «в строю». И вот тут нам на помощь приходит
Что такое ACPI и для чего оно нужно, я объяснять не стану: это выходит за рамки топика, к тому же, на Хабре уже был хороший пост на эту тему. В данном случае нам важен вопрос: можно ли пропатчить DSDT до инициализации чипа так, чтобы он включил нужный контроллер (SD Host) и выключил ненужный, для которого у нас нет драйвера (FlashMedia).
Посмотрим, какие у нас есть средства отладки и вывода информации в рамках интерпретатора («виртуальной машины») ACPI. В спецификации ACPI (параграф 19.5.25, с. 733) упоминается специальный объект Debug , который операционная система должна «донести» до пользователя. Во FreeBSD за это отвечает системная переменная debug.acpi.enable_debug_objects , которую нужно выставить в единицу:
Теперь мы можем писать произвольные строчки в Debug , а ядро FreeBSD будет выводить их на консоль. Осталось придумать, как заставить ACPI выдавать интересующую нас информацию по требованию. Для начала сдампим и дизассемблируем DSDT ноута, и поизучаем его:
Я решил найти метод, который вызывается через какое-либо внешнее воздействие (или внутреннее, но периодическое, типа опроса батарейки), при этом практически не затрагивая работу «железа». Изучая код DSDT, я наткнулся на любопытный кусок:
Больше нигде метод \_SB.PCI0.PEGP.VGA.SWIH не вызывается, а его название намекает, что это некое переключение дисплея. На клавиатуре многих ноутбуков одна из функциональных клавиш в сочетании с Fn-модификатором переключает видео-вывод с внутреннего дисплея на внешний. На моей «версе» это F3. Попробуем модифицировать код метода следующим образом:
Чтобы FreeBSD использовала нашу таблицу при загрузке, добавим в /boot/loader.conf следующие строчки:
Плохо гуглил
Оказывается, еще в 2006 г. Алекс Дубов написал Linux-драйвер для TI FlashMedia ридеров. Я скачал исходники и принялся их изучать, надеясь впоследствии доработать sdhci(4) или даже спортировать драйвер целиком. В первую очередь я посмотрел список поддерживаемых PCI vendor/device ids, чтобы сравнить с «нашим» драйвером. Он оказался небольшим:
Число 0x8033 мне уже знакомо по выводу pciconf -lv на моем ноуте (chip=0x8033104c):
Это тот самый кард-ридер, который не работает во FreeBSD, но работает в Linux. А вот кусок кода из sdhci.c (FreeBSD):
Можно заметить, что идентификатор устройства TI XX21/XX11 SD (0x803 4 104c) похож на мой (0x803 3 104c) с точностью до одной цифры. Кроме того, я обратил внимание, что контроллеры CardBus (0x8031104c) и FireWire (0x8032104c) не просто имеют схожие id'шки, но и PCI-селекторы всех устройств отличаются только номером функции, а устройство у них у всех одно и то же:
Забегая вперед, скажу, что удивительнее всего то, что люди, раскопав практически datasheet на «капризный» чип, останавливались в шаге от решения проблемы. Я так и не нашел ни у кого рецепта, как правильно воспользоваться документацией (что и побудило меня написать этот пост). Но обо всем по порядку.
PCIXXX21/PCIXXX11 Implementation Guide — документ о 117 страницах для проектировщиков аппаратуры на базе этих контроллеров. Подробно его разбирать смысла не имеет; самое важное, что я из него почерпнул: контроллер действительно реализует пять функций: CardBus, 1394, FlashMedia, SD Host и SmartCard; начальная конфигурация обычно берется из EEPROM. Главный регистр конфигурации — General Control Register (раздел 12.4.28, с. 65) — находится по адресам 1Eh-1Fh в ROM (нас интересует только нулевой байт, т.к. именно там маскируются функции чипа) и соотвествует PCI offset 86h нулевой функции устройства. Теперь —
Достучаться до регистра 86h
Физические адресные пространства всевозможных устройств (оперативная память, порты ввода-вывода, платы расширения, CMOS, IPMI и пр.) отображаются в пространство имен ACPI в виде т.н. операционных регионов (OperationRegion), внутри которых обычно выделяются битовые поля (Field), состоящие из одного или нескольких поименованных «виртуальных регистров», или field units (параграф 19.5.96, с. 782 спецификации). OperationRegion для нашего контроллера может выглядеть, например, так:
Или даже проще, если в OperationRegion объявить не все 256 байт, а только интересующий нас, и не выделять отдельные биты в конфигурационном регистре:
Нетрудно заметить, что само по себе такое определение бесполезно: оно не привязано к какому-либо устройству, являясь по сути просто структурой из одного байта по известному смещению. Устройства в DSDT задаются через ключевое слово Device (параграф 19.5.30, с. 735); совокупность всех устройств представляет собой этакое дерево. Так, все PCI-устройства находятся чаще всего внутри пространства устройства \_SB.PCI0 , которое соответствует корневой шине PCI (обычно такая шина одна, но теоретически их может быть до 256 в одном PCI-домене).
Для идентификации устройства на шине нужно задать его адрес в виде (device << 16) | function. В нашем случае (помните вывод pciconf -lv ?) function = 0, device = 7, bus = 6. То есть устройство, видимо, должно выглядеть как-то так:
Хорошо, но откуда взялась шестая шина? И где она в DSDT? Посмотрим лог загрузки ядра ( dmesg ):
Получается, pci6 — это дополнительная, «виртуальная» шина на мосту PCI-PCI. Номер 6 (как и 4 для моста) ей достался потому, что FreeBSD так распределила устройства. Внутри DSDT никаких шести шин и четырех мостов, конечно, нет. Мост — Device (PCIB) — там ровно один, как и ожидалось. Полностью наше описание должно выглядеть так (привожу краткий вариант, не раскладывая регистр на отдельные биты):
Теперь мы можем заменить наш отладочный код в методе _Q0C на что-то более осмысленное:
Пересобираем ASL, перезагружаемся, жмем Fn-F3. Если мы все сделали верно, то должны увидеть то же самое значение, которое мы ранее читали через pciconf(8) :
(Реализация функции для записи значения регистра напрямую в видеопамять оставляется читателю в качестве легкого упражнения.)
Нам остается ответить на самый главный вопрос: получится ли изменить значение регистра и заставить чип сконфигурировать себя так, как нам нужно?
Стандарт ACPI определяет специальный метод для инициализации устройств, _INI (параграф 6.5.1, с. 349). Добавим в наше устройство следующий код:
Компилируем ASL, копируем получившийся файл AML в /root/s950-patched.aml , снова перезагружаемся. Смотрим на
За что отвечает ACPI драйвер, и как его удалить ?
Промышленный стандарт управления питанием компьютера и его устройствами с помощью ОС был необходим технологии как воздух, ведь постоянные конфликты операционной системы и оборудования мешали разработке и того, и другого. BIOS никак не мог угодить операционке, она — ему. Каждый хотел конфигурировать устройства по-своему. Представляете, что бы было, если бы не существовал ACPI при нынешнем многообразии различных девайсов? Даже подумать страшно. Вот поэтому ведущими IT-компаниями было принято решение отделить "софт от харда" и разработать системную архитектуру, которая брала бы на себя всю тяжесть общения с BIOS'ом. Заодно разработчики не забыли об энергопотреблении, поэтому ACPI еще должен был управлять питанием. 1 декабря 1996 года консорциум, состоящий из Hewlett-Packard Corporation, Intel Corporation, Microsoft Corporation, Phoenix Technologies Ltd. и Toshiba Corporation, объявил о завершении работы над новым стандартом — ACPI, что расшифровывается как Advanced Configuration and Power Interface, или расширенный интерфейс конфигурирования и управления питанием компьютера. ACPI состоял из множества составляющих, главной из которых был специальный участок кода BIOS, обеспечивающий поддержку компьютером новой архитектуры. То есть со старым оборудованием новый стандарт был несовместим.
ACPI расшифровывается как Advanced Configuration and Power Interface - расширенный интерфейс конфигурирования компьютера и управления питанием. ACPI - та основа, вокруг которого построен, по идее, любой современный компьютер на аппаратном уровне. В системе с ACPI именно этот свод стандартов и правил используется для конфигурирования и работы аппаратных средств - например, для назначения прерываний и ресурсов устройствам на современных шинах (PCI и AGP), для получения информации о работе устройств, для работы дополнительных "энергосберегающих" кнопок и датчиков, или, например, для получения данных об оставшейся в аккумуляторах энергии
Что новые версии UEFI-стандартов нам готовят, часть вторая, ACPI 6.0
Если вам интересно, что именно изменилось за 10 месяцев разработки стандарта, и какими новшествами нас порадуют или огорчат будущие системы с поддержкой ACPI 6.0 — добро пожаловать под кат.
Что вообще такое ACPI
ACPI 6.0
С момента выпуска предыдущей версии 5.1. прошел почти год, но каких-то радикальных изменений в новом стандарте не случилось, что позволит производителям прошивок реализовать его поддержку в достаточно короткие сроки.
Для начала я перечислю все заметные изменения, а потом уже постараюсь дать развернутый комментарий по каждой группе. Поехали!
Поддержка NVDIMM
Поддержка USB-C
Add USB-C Connection support to _UPC — теперь у каждого USB-порта можно узнать, является ли он портом USB Type C и если да, то какие именно новые режимы поддерживает.
Обновление для языка ASL
Температуры, питания и производительность
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
Остальное
Совсем немного про 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 в своих продуктах.
Что такое ACPI?
Многим из вас знакомо слово ACPI. Кто-то видел его в статьях про NT-системы, кто-то в Диспетчере устройств, а кто-то еще где-нибудь. Однако далеко не все хорошо знают, что это такое. Обычное определение вроде "ACPI — это менеджер питания" слишком поверхностно отражает суть этой системной архитектуры. Между прочим, с приходом ACPI в индустрию канули в лету "разборки" между BIOS'ом и операционкой, появился спящий режим и еще куча полезных функций, о которых раньше можно было только мечтать. Конечно, на полноту изложения данный материал не претендует, но ответ на вопрос, вынесенный в заголовок, дает. Итак, что же такое ACPI?
Промышленный стандарт управления питанием компьютера и его устройствами с помощью ОС был необходим технологии как воздух, ведь постоянные конфликты операционной системы и оборудования мешали разработке и того, и другого. BIOS никак не мог угодить операционке, она — ему. Каждый хотел конфигурировать устройства по-своему. Представляете, что бы было, если бы не существовал ACPI при нынешнем многообразии различных девайсов? Даже подумать страшно. Вот поэтому ведущими IT-компаниями было принято решение отделить "софт от харда" и разработать системную архитектуру, которая брала бы на себя всю тяжесть общения с BIOS'ом. Заодно разработчики не забыли об энергопотреблении, поэтому ACPI еще должен был управлять питанием. 1 декабря 1996 года консорциум, состоящий из Hewlett-Packard Corporation, Intel Corporation, Microsoft Corporation, Phoenix Technologies Ltd. и Toshiba Corporation, объявил о завершении работы над новым стандартом — ACPI, что расшифровывается как Advanced Configuration and Power Interface, или расширенный интерфейс конфигурирования и управления питанием компьютера. ACPI состоял из множества составляющих, главной из которых был специальный участок кода BIOS, обеспечивающий поддержку компьютером новой архитектуры. То есть со старым оборудованием новый стандарт был несовместим.
Основные цели разработки
1. Компьютерная система должна выполнять конфигурирование устройств программными средствами. Управление питанием должно быть более
функциональным и безопасным.
2. Использование ПК должно стать более экономичным.
3. Разработчики оборудования имеют максимальную свободу при проектировании готовых систем: от самых легких решений до самых экстремальных при полной поддержке ОС.
4. Политика управления питанием слишком сложна для реализации в ROM BIOS, поэтому должна осуществляться исключительно самой ОС.
5. Унификация всех алгоритмов питания в единый стандарт ACPI позволит избавиться от конфликтов операционной системы и BIOS'а в вопросах конфигурирования устройств.
6. ОС развивается независимо от аппаратного обеспечения, поэтому на всех ACPI-совместимых машинах можно будет добиться увеличения
производительности и стабильности за счет смены операционной системы.
Нужно сказать, что разработчики своих целей достигли. Стоит рассмотреть структуру работы ACPI подробно.
Структура ACPI
Чтобы понять, как работает та или иная технология, необходим хороший пример. В технической документации разработчики пишут следующее: "Предположим, что ОС имеет политику разделения всех запросов ввода/вывода на ленивых и неленивых. Ленивые запросы (редактирование текста или электронных таблиц) объединяются в группы и исполняются устройством только тогда, когда оно начинает работать по какой-либо _другой_ причине. Неленивые операции заставляют устройство работать при первой же отправке запроса". Для ОС важно различать, какие операции являются ленивыми, а какие — нет. Кроме того, система должна знать состояние всех своих устройств, ведь выключенный девайс никогда ничего делать не станет. Все это обеспечивает ACPI. В то время, когда какая-то железка простаивает без дела, ACPI-драйвер снижает ей мощность питания и вместе с этим уменьшает общее энергопотребление работающей системы. Представьте, что в вашем системном блоке установлен автоответчик. Его задача — отвечать на входящие звонки. Разумеется, вам звонят не постоянно, поэтому большую часть времени автоответчик совершенно ничего не делает, зря потребляя драгоценную электроэнергию. Это очень нерационально. Поэтому ACPI создает девайсу специальную политику поведения, согласно которой он входит в состояние глубокого сна, однако при входящем звонке устройство проснется в течение одной секунды и ответит на вызов. Разумеется, есть одно но: автоответчик обязательно должен быть ACPI-совместимым.
Как было сказано выше, появилось новое состояние оборудования — спящий режим. Состояние всех устройств сохраняется на жесткий диск, а затем может быть восстановлено при следующей загрузке операционной системы. Преимущества спящего режима очевидны. Это быстрый старт системы, возможность продолжения работы с того места, где остановился в прошлый раз, практически моментальное выключение. К минусам можно отнести лишь обязательное наличие файла hiberfil.sys размером с оперативку и остающиеся в памяти невыгруженные dll'ки, которые со временем тормозят работу. Тем не менее, эта фича хорошо прижилась в народе, и многие ею пользуются. Производители корпусов стали даже выпускать модели с двумя кнопками: включение/выключение и спящий режим. Отныне любая кнопка на системном блоке (кроме Reset, конечно) являются программируемой — ACPI позволяет переопределять их. Откройте апплет Электропитание в Панели управления, вкладка Дополнительно. Видите, здесь можно переназначить действия кнопок на вашем корпусе. Благодаря возможностям ACPI мы можем отправлять компьютер в спящий режим по нажатию кнопки Power на системном блоке (если системный блок ATX — впрочем, AT уже можно найти только в музее). ..\Электропитание.jpg. ..\ACPI.jpg Все устройства подключаются к виртуальной ACPI-шине, хотя реальный ввод/вывод идет через обычные интерфейсы (IDE, AGP и т.д.). В этом можно убедиться, если в Диспетчере устройств в меню Вид выбрать пункт Устройства по подключению. Сначала Windows загружает ACPI-драйвер, опрашивающий ACPI-контроллер на предмет подключенных к нему устройств, главным из которых является PCI-шина. Затем выявляются подключенные платы расширения, и процесс повторяется до тех пор, пока не будут определены все шины и подключенные к ним устройства. ..\Device.jpg ACPI состоит из трех компонентов: ACPI-регистры, ACPI BIOS и ACPI-таблица.
ACPI-таблица. ACPI-таблица описывает интерфейсы аппаратных средств. Некоторые из этих описаний могут ограничивать использование устройством каких-либо функций, но большинство из них позволяют устройствам выполнять произвольные последовательности операций. ACPI-таблица содержит так называемые блоки определения (Definition Blocks), которые могут быть запрограммированы из-под ОС. Другими словами, ACPI использует встроенный интерпретатор псевдокода, называемый ACPI Machine Language (AML). AML исполняет код, содержащийся в блоках определения.
ACPI-регистры. Здесь содержится ограниченная часть описания интерфейсов из ACPI-таблиц для быстрого доступа к таким данным.
ACPI BIOS. Это часть кода BIOS, которая совместима с ACPI-спецификациями. Как правило, это код, отвечающий за загрузку, засыпание/пробуждение и перезагрузку машины. ACPI-таблицы также обеспечиваются за счет ACPI BIOS.
ACPI и железо
Специальная таблица описывает поведение обычных и ACPI-совместимых программных и аппаратных средств.
| Тип железа | Обычная OS | ACPI OS с OSPM |
| Обычное железо | Обычная ОС на обычном оборудовании делает то, что делала всегда | Если ОС испытывает недостаток в поддержке нужного железа, она осуществляется исключительно за счет BIOS |
| Обычное и ACPI-железо в одной машине | Работает точно так же, как обычная ОС на обычном железе | Во время загрузки ОС переключает совместимое оборудование из обычного режима в режим OSPM/ACPI, и с этого момента система имеет поддержку OSPM/ACPI |
| Только ACPI-железо | Управление питанием отсутствует | Полная поддержка всех функций OSPM/ACPI |
Выводы и заключение
1. Концепция ACPI одинакова для всех типов компьютеров включая десктопы, лэптопы, КПК, мобильные телефоны, рабочие станции и серверы.
2. Новая системная архитектура является достаточно переносимой — как между различными ОС, так и между процессорами.
3. Внедрение ACPI в ОС позволило несколько упростить (и удешевить) разработку кода BIOS, исключив из него примитивные энергоуправляющие функции.
4. Появление этой архитектуры значительно увеличило стабильность работы операционных систем и повысило безопасность использования оборудования.
5. Существование столь большого парка мобильных компьютеров вряд ли было бы возможным без ACPI. Динамическое управление питанием отлично экономит батарею.
Читайте также: