Как получить ssdt dsdt в ubuntu
Обновлено: 07.07.2024
На сегодня, у многих специалистов, использование ACPI ассоциируется в первую очередь с функциями управления электропитанием и минимизацией энергопотребления. Вместе с тем, данная спецификация разработана как альтернатива устаревающему стандарту Plug and Play, и сферы ее применения значительно шире.
Спецификация ACPI содержит огромное количество определений, протоколов и форматов, поэтому в рамках одной статьи можно изложить только основные принципы ее функционирования. Для подробного изучения вопроса рекомендуется обратиться к документам [1], [2], [8]. Предлагаемый материал позиционируется как практический пример, интересный для специалистов, уже имеющих некоторые базовые знания в данной области. На уровне ассемблерных инструкций и схемотехники материнской платы рассматривается процедура программного выключения питания. К статье прилагаются также протоколы ручного дизассемблирования таблиц ACPI с подробными комментариями.
Как это работает?
Рассмотрим абстрактный пример. Пусть для выполнения заданного действия необходимо записать в регистр по адресу X данные Y. При использовании подхода, основанного на вызове сервисных процедур BIOS, в выполняемом блоке BIOS будет размещена процедура, которая осуществляет указанную запись. Задача операционной системы — просто вызвать эту процедуру. В данном случае, особенности реализации конкретного чипсета, если таковые имеются, скрыты внутри BIOS и не являются заботой разработчика ОС.
Второй вариант — ОС не обращается к BIOS и выполняет указанную запись самостоятельно. В этом случае, драйвер напрямую взаимодействует с регистрами чипсета, распознает и эффективно использует его возможности. Но расплата за это — усложнение и ограниченная совместимость. Как известно, под каждый чипсет нужен свой драйвер.
Разработчикам ACPI удалось придумать третий вариант. Численные значения X и Y, отражающие особенности реализации конкретной платформы, хранятся в специальных таблицах, которые генерирует BIOS при старте и размещает в оперативной памяти. Для этого, как правило, используется последний мегабайт верхней памяти. Операционная система находит и считывает эти параметры. Процедура записи в регистр по адресу X данных Y является частью ОС, а не BIOS, но параметры X и Y предоставляет BIOS посредством таблиц ACPI.
Какие преимущества это дает? Таблицы ACPI, в отличие от сервисных процедур BIOS, не содержат выполняемого кода, поэтому независимо от архитектуры процессора и режима его работы, можно использовать одни и те же таблицы. Чтобы оценить это преимущество, вспомним о неудобствах, связанных с тем, что большинство функций BIOS могут быть вызваны только в реальном режиме процессора (Real Mode). Функции, доступные в защищенном режиме (Protected Mode) должны иметь несколько точек входа (для Real Mode, Protected Mode 16, Protected Mode 32).
Так как процедура взаимодействия с оборудованием является частью ОС, для настройки на конкретную платформу, можно совместно использовать данные, полученные от BIOS (из таблиц ACPI) и данные, размещенные в драйвере при его разработке. Это дает дополнительную гибкость.
Таким образом, таблицы ACPI обеспечивают эффективное использование BIOS для информирования программного обеспечения об особенностях конкретной платформы. При этом отсутствуют неудобства, связанные с использованием сервисных процедур BIOS.
Таблицы и структуры ACPI
Ниже перечислены основные таблицы ACPI, полная номенклатура таблиц приведена в [1].
Таблица FADT (Fixed ACPI Description Table) содержит набор параметров, описывающих платформу и чипсет. ОС использует эти параметры при взаимодействии с оборудованием. Таблица FADT форматирована, то есть назначение каждого поля определяется его адресом внутри таблицы. Здесь содержатся константы, характеризующие платформу, адреса структур в оперативной памяти, используемых для взаимодействия BIOS и ОС, адреса регистров чипсета, используемых для передачи заданных команд (регистры управления) и опроса текущего состояния (регистры статуса), номера линий запросов на прерывание, используемых для оповещения ОС о заданных событиях в подсистеме ACPI и другая информация.
Структура FACS (Firmware ACPI Control Structure) используется для управления переходом в спящий режим и выходом из него. Она содержит вектор для передачи управления на процедуру, запускаемую при выходе из спящего режима. Также здесь находится 32-битная сигнатура оборудования или Hardware Signature, используемая для контроля изменений конфигурации, произошедших за время нахождения системы в спящем режиме, например удаления или подключения каких-либо устройств. Это переменная, вычисляемая как функция от текущей конфигурации оборудования. После выхода из спящего режима, значение этой переменной вычисляется повторно и сравнивается с образцом, хранящимся в структуре FACS.
Таблица DSDT (Differentiated System Description Table) является самой сложной. Она содержит описание методов выполнения типовых системных операций (например, считывание температуры процессора или изменение номера линии запроса на прерывание, используемой заданным устройством), информацию об устройствах, шинах, всех системных объектах и методах взаимодействия с ними. Декларации системных устройств (объекты System Plug and Play Nodes), также продублированы в этой таблице, при этом номенклатура описанных устройств существенно расширена. Таблица DSDT, в отличие от FADT, не форматирована, то есть доступ к заданной записи осуществляется не по фиксированному адресу, а последовательным сканированием и детектированием требуемой записи. Исходный код таблицы DSDT пишется программистом на языке ASL (ACPI Source Language), который преобразуется компилятором в код AML (ACPI Machine Language). Интерпретатор языка AML, входящий в состав операционной системы, обеспечивающий обработку DSDT, обычно называется виртуальной машиной ACPI.
Таблицы SSDT (Secondary System Description Table) используются как модули расширения таблицы DSDT. В системе может присутствовать несколько таблиц SSDT. Мотивация применения таблиц SSDT состоит в том, что отдельные порции AML кода (например, выбираемые в зависимости от типа установленного процессора или состояния BIOS Setup) удобно выделить в виде отдельных таблиц, а не размещать в главной таблице DSDT.
Таблица MADT (Multiple APIC Description Table) используется для информирования операционной системы о логических и физических процессорах и контроллерах прерываний I/O APIC (Input-Output Advanced Programmable Interrupt Controller). Подобно старой таблице MPT (Multiprocessing Table), расположенной в выполняемом блоке BIOS, таблица MADT содержит последовательность информационных структур, описывающих процессоры, контроллеры прерываний, а также соответствие между номерами линий запросов на прерывание и входами контроллеров прерываний. В большинстве систем, использующих технологию Hyper Threading, в таблице MPT декларированы только физические процессоры или ядра, а в таблице MADT перечислены все логические процессоры. Это дает операционной системе дополнительную возможность для распознавания типа мультипроцессорной системы.
Первые 36 байт каждой таблицы образуют заголовок, назначение полей которого одинаково для всех таблиц. Далее следует основной блок, это информация, структура которой определяется типом таблицы. Полная номенклатура и детальное описание всех таблиц и структур, а также формат указателя RSDP приводится в [1].
Протоколы дизассемблирования таблиц ACPI
В прилагаемом каталоге DISASM содержатся протоколы ручного дизассемблирования некоторых таблиц ACPI и их фрагментов с детальными комментариями (текстовые файлы в кодировке DOS). Разумеется, существует возможность для автоматизированного выполнения этой задачи, например, дизассемблер фирмы Phoenix Technologies — AD.EXE (ACPI Dump). Вместе с тем, для получения некоторых сведений, необходимых для написания собственной виртуальной машины ACPI и других исследовательских работ, автор посчитал уместным «копнуть глубже», несмотря на очевидную трудоемкость данного подхода.
Примечание. В комментариях к дизассемблированным таблицам ACPI, используются ссылки на страницы и пункты документов, указанных в файле README.TXT. Для того чтобы ссылки оставались верными, необходимо использовать именно те версии документов, которые указаны. Например, вместо доступной на сегодня спецификации ACPI 3.0 (документ [1]), во время выполнения данных работ использовалась спецификация ACPI 2.0.
Описание работы программы
Как и в ранее опубликованных статьях данного цикла, в целях монопольного и беспрепятственного взаимодействия программы с оборудованием, автор применил древнюю технологию отладки под DOS. Аргументация такого шага и рекомендации по организации рабочего места приведены в ранее опубликованной статье «64-битный режим под DOS: исследовательская работа №1».
В качестве примера взаимодействия с оборудованием посредством интерфейса ACPI, рассмотрена процедура программного выключения питания компьютера (для систем с блоком питания ATX).
Предлагаемый пример является полуфабрикатом, и совместим не со всеми реализациями таблиц DSDT. Текущая версия программы способна находить объекты _S5, только в таких реализациях, где указанные объекты расположены в начале таблицы DSDT. Для универсального решения такой задачи, необходима полноценная реализация виртуальной машины ACPI, так как чтобы добраться до объекта _S5, потребуется интерпретировать AML код, расположенный до требуемого объекта. В случае несовместимости выдается сообщение Incompatible version of AML code.
На базе данного примера, заинтересованный читатель может самостоятельно реализовать полнофункциональную виртуальную машину ACPI. Автор также ведет работы в данном направлении и при наличии читательского интереса, планирует представить такую разработку в последующих публикациях.
Прилагаемый каталог WORK содержит следующие файлы:
Рассмотрим выполнение основного модуля. Нумерация пунктов данного описания соответствует нумерации пунктов комментариев в исходном тексте - файле WORK\atx_off.asm.
Стандартное для ACPI имя переменной _S5, используемой в процедуре выключения питания, обусловлено тем, что дежурный режим, при котором на блок питания ATX подается напряжение сети, но система выключена (блок питания выдает только напряжение +5V Standby и сигнал PS_ON=1) классифицируется спецификацией ACPI как состояние S5=Soft-Off.
- Выполняем запись заданных значений в заданные порты, что приводит к выключению питания (переводу сигнала PS_ON в состояние логической «1»). Предварительно выводим дамп значений, полученных на шагах 5 и 6. Считываем порт PM1a_CNT_BLK, в прочитанном значении, бит 13 (Sleep Enable) устанавливаем в «1», биты 12-10 (поле Sleep Type) устанавливаем в состояние, равное содержимому объекта S5a_Value, остальные биты не изменяем. Значение, с модифицированными битами 13-10 записываем обратно в порт PM1a_CNT_BLK. Считываем порт PM1b_CNT_BLK, в прочитанном значении, бит 13 (Sleep Enable) устанавливаем в «1», биты 12-10 (поле Sleep Type) устанавливаем в состояние, равное содержимому объекта S5b_Value, остальные биты не изменяем. Значение, с модифицированными битами 13-10 записываем обратно в порт PM1b_CNT_BLK. После задержки, связанной с прохождением сигналов через Power Management контроллер, питание должно выключиться. Запрещаем прерывания и останавливаем процессор. В типовой платформе, инструкции CLI и HLT, расположенные после процедуры записи регистров, успеют выполниться до выключения питания, так как существует задержка срабатывания контроллера Power Management и инерционность блока питания. Вместе с тем, вариант, при котором питание выключится раньше, также допускается.
Использование двух портов управления PM1a_CNT_BLK и PM1b_CNT_BLK обусловлено тем, что спецификация ACPI поддерживает описание нетипичных платформ, у которых для выключения питания требуется выполнить запись в два порта, имеющие различные адреса и физически расположенные в разных микросхемах (Северном и Южном мостах чипсета). В типичной платформе такая возможность избыточна, так как для рассматриваемого действия достаточно записи в один порт, расположенный в составе Южного моста чипсета. При этом переменная PM1a_CNT_BLK содержит адрес этого порта, а переменная PM1b_CNT_BLK содержит нуль, что соответствует отсутствию порта. Программа, выполняющая запись значений в указанные регистры, пропускает операцию записи, если адрес нулевой.
Управление блоком питания ATX
Рассмотрим процессы, происходящие при выполнении вышеописанной программы, на уровне принципиальной электрической схемы. Разумеется, в каждой материнской плате, в зависимости от модели чипсета, микросхемы MIO (Multi Input/Output) и других факторов, рассматриваемый узел реализован по-своему.
Для определенности возьмем частный случай - материнские платы, использующие Южный мост Intel ICH6, описанный в [6] (это платы на чипсетах Intel 915 и 925) и микросхему MIO Winbond W83627THF, описанную в [12].
Ядро Power Management контроллера, а именно, логика, принимающая решение о включении и выключении питания находится в составе Южного моста чипсета. Здесь же расположен программно-доступный регистр PM1_CNT_BLK, используемый в приведенном примере для выключения питания. Обеспечение интерфейса Power Management контроллера с внешним миром входит в обязанности микросхемы MIO. В ее составе находится схема опроса кнопки Power Switch, которая, получив сигнал от кнопки, транслирует его Power Management контроллеру (ICH6). Также в составе MIO находится формирователь сигнала PS_ON для блока питания ATX. При получении соответствующего приказа от ICH6, микросхема MIO выдает сигнал PS_ON=0, что приводит к включению блока питания.
Другие примеры реализаций микросхем Южных мостов и MIO приведены в [7], [9], [10], [11], [13].
При рассмотрении работы блока питания, не следует путать сигналы PS_ON и PWR_OK. Сигнал PS_ON (Power Supply On) используется для включения блока питания ATX. Это входной сигнал для блока питания и выходной сигнал для материнской платы. При логическом «1» на этой линии, блок питания выключен (работает только дежурный источник +5V Standby, необходимый для схемы управления питанием). При логическом «0» на этой линии блок питания включен, выдаются все выходные напряжения. Сигнал PWR_OK (Power OK, синоним Power Good) используется для запуска материнской платы при включении питания и блокировки работы ее устройств на время переходных процессов при включении и выключении питания. Это входной сигнал для материнской платы и выходной сигнал для блока питания. Логический «0» на этой линии равносилен нажатию кнопки RESET. При этом все устройства зафиксированы в состоянии сброса. При включении питания, в течение нескольких миллисекунд, сигнал PWR_OK=0, это обеспечивает запуск компьютера и препятствует выполнению каких-либо операций до стабилизации питания. При выключении питания, во время переходного процесса, сигнал PWR_OK также переходит в состояние логического «0». Во время рабочего сеанса на этой линии присутствует логическая «1». Подробности в [3], [4].
Источники информации
Электронные документы, доступные на сайте ACPI
- Advanced Configuration and Power Interface Specification. Revision 3.0
Электронные документы, доступные на сайте Intel
- Instantly Available Power Managed Desktop PC Design Guide. Revision 1.1
- ATX Specification. Version 2.03
- ATX / ATX12V Power Supply Design Guide. Version 1.0 (Public Release)
- ATX Balanced Technology Extended (BTX) Interface Specification. Version 1.0
- Intel I/O Controller Hub 6 (ICH6) Family Datasheet. Document Number 301473-001
- Intel I/O Controller Hub 7 (ICH7) Family Datasheet. Document Number 307013-002
Электронные документы, доступные на сайте AMD
- VIA VT82C686A South Bridge Datasheet. Revision 1.54
- VIA VT82C686B South Bridge Datasheet. Revision 1.71
Электронные документы, доступные на сайте Winbond
Электронные документы, доступные на сайте ITE
- IT8712F Environment Control - Low Pin Count Input/Output (EC-LPC I/O)
Загрузить ZIP-архив
с примером программирования
на ассемблере
можно здесь.
Данные таблиц DSDT используются для различных целей: от написания приложений для управления устройствами материнской платы до установки "Хакинтош". Также данные эти часто используются для устранения возникших проблем во взаимодействии ОС с оборудованием.
*****
Таблица DSDT является частью спецификации ACPI, отвечающей за работу устройств материнской платы. ACPI, в свою очередь, является интерфейсом конфигурации и управления питанием. Его задача определять и управлять питанием устройств компьютера, тем самым обеспечивая взаимодействие операционной системы с аппаратной начинкой компьютера.
Таблицы ACPI приведены в прошивке материнской платы компьютера и отличаются от модели к модели. А потому некоторые узконаправленные устройства могут не работать либо не совсем корректно работать в вашей ОС. Например, на новых лэптопах могут не отключаться по сигналу wi-fi модули или не затухать дисплей по закрытии крышки.
Часть подобных проблем можно решить при помощи корректировки DSDT таблицы. Но, для того, чтобы получить данные с таблицы DSDT, нам для начала необходимо сделать ее копию в домашней директории. Для чего воспользуемся командой:
sudo cat /sys/firmware/acpi/tables/DSDT > dsdt.dat
Но полученный файл в таком виде мы не сможем прочесть. Его сперва необходимо декомпилировать, а для этого нам понадобится приложение iasl. А так как в Linux Ubuntu 12.10 оно не предустановлено, и у вас, скорее всего, тоже, то установим его такой командой:
sudo apt-get install iasl
После установки iasl файл dsdt.dat можно декомпилировать такой командой:
iasl -d dsdt.dat
В итоге мы получим файл dsdt с расширением .dsl, который легко откроется в любом текстовом редакторе, например, gedit.
При помощи приложения iasl можно не только декомпилоировать, но и перекомпилировать таблицы ACPI. Для этого используется команда:
iasl -tc dsdt.dsl
После чего мы обратно получим файл dsdt с расширением .dat.
Здесь я описал пример лишь для таблицы DSDT, но данный мануал также подходит и для других. Все они находятся в той же директории, что и DSDT, то есть в /sys/firmware/tables.
Не знаю почему, но я всегда воспринимал системы охлаждения в ноутбуках как некий закрытый черный ящик. Тупость алгоритмов, по которым вентилятор начинал надрывно завывать при еще вполне холодном процессоре, изрядно раздражала во многих ноутбуках, но мне казалось, что все параметры там производители прибили гвоздями и поменять их можно разве что расковыряв BIOS или вообще только вставив какие-нибудь регулируемые резисторы в нужных местах. Ни тем, ни другим мне заниматься совершенно не хотелось, поэтому я об никогда всерьёз даже не задумывался.
Нет, конечно, я слышал про всякие программы, которые могут вмешиваться в управление охлаждением и вроде кто-то ими успешно пользуется, но лично мне с ними вечно не везло, точнее не везло с железом, на котором я пытался их завести. Например, какое-то время назад я пробовал настроить fancontrol на довольно старом ноутбуке HP nc8430 с Убунтой. В итоге, известный скрипт sensors-detect не смог найти ни одного вентилятора в системе, а без этого fancontrol не работает. На разных форумах периодически появляются люди с похожими проблемами, но никто им толком помочь не может.
Тогда я в очередной раз забросил эту тему и вернулся к ней только на днях, когда читал обзоры, подыскивая себе новый ноутбук, и уже вроде бы выбрал почти всем хороший Sony S15, как опять в одном из обзоров читаю про него, что вентилятор в нем вообще не останавливается никогда, даже когда точно можно. Постоянно шумящий ноутбук я больше не хочу, а выбирать как всегда особо не из чего, учитывая, что надо 15", что TN матрицу я тоже больше не хочу, и бюджет ограничен. Ну сами знаете, как оно бывает. Может быть на нем все-таки заведется fancontrol и все будет хорошо, но а если нет? Никаких отчетов по его установке на этот ноутбук найти не удалось. Это побудило меня еще раз копнуть тему программного управления вентиляторами и пройти довольно непростой, но очень увлекательный квест.
Как оно в Windows
Я решил, что если мне удастся разобраться с охлаждением моего HP, то и с новым Sony скорее всего справлюсь. Если нет, придется искать другой ноутбук. Погуглив немного, удалось узнать, что под Windows есть замечательная программа Notebook Hardware Control, она бесплатная, её все хвалят. Что же, надо попробовать. Перезагрузился в Windows, скачал, запустил – программа действительно работает. Можно задать температуры, при которых вентилятор будет выключен совсем, работать на низких оборотах, средних и высоких, а самое главное можно задать мощности моторчика вентилятора в процентах для всех трех режимов. Именно мощности, а не обороты в секунду, но какая разница.
Оказалось, что в этом ноутбуке по умолчанию самым низким оборотам соответствует 55% мощности. Т. е. либо вентилятор молчит совсем, либо довольно громко гудит на своих 55%, а при повышении температуры еще громче: 70%, 80% и 100%. При этом молчит он только до 50 градусов, а потом сразу начинает работать. Процессор стоит довольно горячий – Core 2 Duo T7600, меньше 50 градусов он бывает только сразу после включения, потом температура быстро становится выше, даже при нулевой нагрузке, и уже ни в какую не хочет опускаться ниже 50 C, только если раскрутить вентилятор на полную и оставить так на несколько минут, и то когда в комнате не очень жарко. На дефолтных 55% у вентилятора просто нет никаких шансов охладить процессор обратно ниже 50 С. Хотя может быть надо просто попробовать термопасту поменять, но сейчас речь не об этом.
С помощью программы я просто установил минимальную мощность равной 30% и поднял минимальную температуру, при которой включается вентилятор до 60 С. Температура корпуса при этом на ощупь почти не изменилась, как было довольно горячо, так и осталось, а вот тише стало намного. Днем вентилятор на 30% мощности можно услышать только если поднести к нему ухо. Ночью в тихой комнате его вполне слышно, но терпимо. Это гораздо лучше, чем было. Если еще чуть-чуть поднять минимальную температуру и перевести процессор и видеокарту в режим энергосбережения, можно получить абсолютно тихий ноутбук, только жесткий диск слышно как вращается, но это решается только заменой его на SSD, что вобщем-то в любом случае хорошо бы сделать. Короче, оказывается возможность полностью контролировать температуру и шум есть. Тут бы и сказочки конец, но это же под Windows, а мне надо под Linux!
Как оно под Linux
Под Linux такой программы нет. И как она работает, я честно говоря до сих пор до конца не понимаю, а на тот момент я там только подсмотрел ключевые слова, которые потом очень пригодились: ACPI и DSDT. К ним я еще вернусь позже. А пока, я перезагрузился обратно в Ubuntu и начал внимательно изучать предварительно нагугленный путь в sysfs: /sys/class/thermal. Там оказалось вот что:
Целых 10 cooling_devices и 6 thermal_zones. С термальными зонами более менее все ясно, температуры CPU, GPU, какие-то еще три точки, не особо важно. А последняя thermal_zone5 – это вовсе не температура, как выяснилось опытным путем, а текущая мощность вентилятора. Браво HP! Теперь понятно почему sensors-detect ничего не нашел, тут такой бардак, что черт ногу сломит. Вот так вот просто записав какое-нибудь число в thermal_zone5/temp поменять мощность нельзя. Файл только для чтения, оно и понятно.
Теперь посмотрим на cooling_device*, зачем их 10? Внутри каждой папки примерно вот такое содержание:
В файлах type для cooling_device c 0 по 6 написано Fan, в 7-8 — Processor, а в 9 — LCD. Хм, я точно знаю, что у меня в ноутбуке только один вентилятор. Процессоров, можно сказать, действительно два и есть один LCD экран, это правда. Но это же не cooling devices, зачем они тут? Ладно, будем пробовать разбираться дальше в этом бардаке. В файлах cur_state бывает либо 0, либо 1. Ага, похоже на какую-то такую развесистую битовую маску. Если попробовать во все cur_state записать нули с помощью «echo 0 | sudo tee /sys/thermal/cooling_device*/cur_state», то вентилятор остановится. А если записать единицу в cooling_device3/cur_state, то вентилятор закрутится на 55%. Ура, у меня получилось управлять вентилятором вручную в Убунте. Тут бы можно было бы сколхозить какой-нибудь демон на Питоне, который бы ставил нужные мощности при определенных температурах, но во-первых, так можно установить только «стандартные» мощности из набора 0, 55, 70, 80, 100, а мне теперь надо 30. А во-вторых, что-то же еще в системе меняет эти биты. Надо бы попробовать разобраться, что именно этим занимается и как на это можно влиять. Иначе говоря, «we have to go deeper». Тут я вспомнил про первое ключевое слово подсказанное той программой под Windows: ACPI.
Раз есть байт-код, значит где-то должен быть интерпретатор, который будет его исполнять. И действительно, ядро каждой ОС, которая поддерживает ACPI, должно содержать виртуальную машину для выполнения AML-кода DSDT и других таблиц. Есть она и в Linux. Вот и нашлось то, что меняет эти битики в файлах cur_state, это само ядро.
Код таблиц можно взять в sysfs, в директории /sys/firmware/acpi/tables/. Но сначала надо установить интеловский компилятор для ASL/AML, в Debian-based системах это делается так: «sudo apt-get install iasl». Потом просто сделав «sudo cat /sys/firmware/acpi/tables/DSDT > /tmp/dsdt.dat» и «iasl -d /tmp/dsdt.dat», мы получим исходный код DSDT в файле /tmp/dsdt.dsl. ASL хоть и трудно читаемый, но довольно простой сам по себе язык, видимо, специально спроектированный так, чтобы было легче писать его интерпретаор, т. к. для каждой ОС он должен быть свой. Я довольно быстро разобрался как мне поменять мощности вентилятора, просто поискал те самые мощности (55, 70, 80, 100) переведя в шестнадцатеричную ситему и они сразу нашлись. Сборка делается командой «iasl -tc /tmp/dsdt.dsl».
При этом могут вылезти ошибки и предупреждения, причем в тех строках, которые вы и не трогали. Все говорят, что происходит это потому что почти все производители биосов пользуются компилятором от Microsoft, а он просто игнорирует многие ошибки, интеловский гораздо строже. Но у меня есть версия, что программисты просто отказываются нормально писать на этом дурацком языке. Помимо прочего, я в своем DSDT нашел довольно досадную опечатку в названии метода, который возвращает текущий уровень подсветки экрана из-за этого ядро при загрузке всегда ругалось «[Firmware Bug]: ACPI: No _BQC method, cannot determine initial brightness», и при выходе из сна настройки подсветки всегда сбивались. Так что даже если с охлаждением у вас все в порядке, повод посмотреть на свой DSDT все равно есть. В сети полно рецептов, как исправлять те или иные ошибки в DSDT, здесь я не буду на этом подробно останавливаться.
Получается, что если мы можем декомпилировать, редактировать и компилировать обратно в байт-код DSDT и другие таблицы, то мы можем делать всё что угодно с питанием любых устройств. Теперь надо только как-то подсунуть ядру патченный DSDT. Делать это опасно, можно что-нибудь сжечь по неосторожности, поэтому 100 раз подумайте нужно ли оно вам, прежде чем делать что-либо из описанного ниже.
Как заставить ядро выполнять пропатченный DSDT
Весь AML-код хранится в BIOS и ядро, по умолчанию, берет его оттуда. Первое, что приходит в голову, сделать свой образ BIOS с патченной DSDT и прошить его. Риск получить кирпич очень велик, зато при удачном исходе все изменения будут доступны сразу во всех ОС, которые вы используете. Но, конечно, есть способы получше и побезопаснее.
Перед тем, как писать эту статью поискал, что есть на Хабре на эту тему и очень позавидовал тому, как просто это делается во FreeBSD.
Для Linux во всяких HowTo чаще всего советуют пересобрать ядро из исходников интегрировав туда свой DSDT. Таких инструкций много, там ничего сложного, на Хабре тоже про это есть, так что не буду про это ещё раз.
Раньше, до версии ядра 2.6, был удобный способ загрузки через initrd, но потом пришел Линус и сказал, что так делать плохо, а надо либо хорошо, либо никак, и способ убрали. Линусу придется поверить, раз он говорит, что так надо, значит надо.
Говорят, что ещё можно через GRUB2 ядру передать нужный DSDT. Ядро мне пересобирать очень не хотелось и я решил попробовать. Сначала я прописывал в конфиг груба только DSDT, у автора той статьи так работало, но ядро вообще его не грузило, в логе было примерно следующее:
Соответственно, ACPI вообще не работал. Страшное дело, между прочим. Wi-fi у меня при этом не работал, кнопка выключения выключала все сразу, а не запускала нормальный shutdown. Короче, пользоваться совсем нельзя. Потом я еще попробовал вообще все таблицы передать в параметрах, получилось так:
На этот раз была попытка загрузить DSDT, но там видимо есть какая-то ссылка на таблицу FACS, которую в данном окружении не получается разрешить. Немного помучившись с этим, раз 20 перезагрузив систему, мне так и не удалось заставить все работать этим способом. Плюнув на всё, поставил пересобираться ядро и лег спать, с утра все заработало как надо:
Можно было бы открывать шампанское и праздновать успех, но в голове свербила мысль, что можно же сделать как-то лучше. Ведь та программа под Windows позволяла все менять вообще на ходу. Оказывается и в Linux так тоже можно сделать, вот документация. Об этом способе на форумах почти не пишут, а способ на самом деле замечательный. Обычно-то и надо переопределить один-два метода, а если при этом ещё и перезагружаться не надо, то это же вообще красота.
Я подготовил .aml файл с переписанным методом управления вентилятором и, радостно предвкушая как сейчас все замечательно заработает набираю «sudo cat ./fan-speeds.aml > /sys/kernel/debug/acpi/custom_method» и… получаю «zsh: permission denied: /sys/kernel/debug/acpi/custom_method». Как так permission denied? Я не забыл сделать sudo, директория /sys/kernel/debug/acpi/ судя по permissions открыта на запись для рута, нет никаких там immutable атрибутов и прочего. WTF? Оказалось, что эту фичу объявили дырой, т. к. якобы бывают такие окружения, где рут может не всё. Например, не может грузить модули ядра после того, как система полностью загрузится. Зачем и кому такое нужно, я честно говоря даже предполагать боюсь, но факт. Вроде бы в любой Убунте рут точно может делать все, что угодно, поэтому не очень понятно почему их Security Team тоже считает, что это очень серьезная уязвимость. К счастью, совсем это не выпилили из ядра, а просто выключили в конфиге по умолчанию и сделали возможность грузить отдельно, как модуль. Ну что же, собрать один модуль, это не тоже самое, что все ядро, а подключение модулей нам в Убунте, слава богу, пока не запретили.
Исходники ядра у меня уже были, поэтому по инструкции я собрал, поставил и включил модуль custom_method. Теперь все работало просто прекрасно.
Осталось как следует, а не по диагонали почитать спецификацию ACPI на досуге и подумать, что еще можно улучшить в ноутбуке. Программных проблем в системах охлаждения ноутбуков я теперь точно не боюсь. Надеюсь, что и вы теперь тоже, если вдруг боялись раньше.
Работа с DSDT.aml
Извлечение оригинальных файлов | Дизассемблирование ACPI-файлов | Исправление ошибок | Патчинг
Программа для редактирования и патчинга DSDT.aml - MaciASL
Следите за тем какая версия ACPI в редакторе, в версии 1.4 почему то ACPI 4.0 по умолчанию
Программа для компилирования - iASL
Положить на «рабочий стол» скачанный файл(iasl), и в терминале выполнить команду: sudo mv
/Desktop/iasl /usr/local/bin/ что бы переместить файл в /usr/bin
Добавление репозиториев в MaciASL:
В Linux файлы лежат по путям /sys/firmware/acpi/tables и /sys/firmware/acpi/tables/dynamic.При старте флешки в меню Clover`а нажать клавишу F4, после чего он сохранит все по пути /EFI/Clover/ACPI/origin
cd "путь к папке, куда вы положили DSDT и SSDT файлы"
iasl -da -dl *.aml
Примечание: Не пытайтесь разобрать другие ACPI файлы с помощью флага “-da“.
Оригинальный код;
Исправленный;
Method (_CRS, 0, NotSerialized)
If (IGDS)
Return (CRS)
>
Sample Problem ( example below is Tag: 1 bit, Field: 8 bits ) :
CreateByteField (CRS3, \_SB.PCI0.LPC0.SIO1._Y0D._HE, IRQS) // _HE_: High-Edge
Fix ( depending on the size Tag mismatch: 1 bit = CreateBitField, 8 bits = CreateByteField, 16 bits = CreateWordField, 32 bits = CreateDwordField, 64 bits = CreateQwordField ) :
Удалить Return (RP00)
Путь к патченному файлу DSDT.aml в Clover: EFI/Clover/ACPI/patched/
Причина редактирования: Для винды есть еще один способ сдампить DSDT - с помощью скрипта SSDTTimeМануал по заводу не будешь писать самого инструмента и репозиториев.?
Собственно он и не нужен, просто в настройках программы вписать ссылку)
Если у вас не показываются патчи в программе а ссылки есть в настройках - нужно в список репозиториев нажать + а затем удалить нажать -, тогда все показывает.. Странное поведение у программы. WinSSLioN,
Я о о том что может кому-то захочется освоить это самому. Допустим начиная со скачивания с репозитория , сборки , копирования в систему и процесс применения практически. Наподобие этого :
Сразу куча вопросов.
Столкнулся с тем, что разные версии DSDT Editor дают разные данные об ошибка в DSDT, MaciASL вообще третье. Кому верить?
Читайте также: