Acpi 10251229 0 что за устройство

Acpi 10251229 0 что за устройство

Acer Airplane Mode Controller Driver for Acer — Swift SF514-55TA working on Microsoft Windows 10 Home Single Language

ACPI\VEN_1025&DEV_1229
ACPI\10251229
*10251229

Compatible ID:
ACPI\10251229
10251229

List of driver files that match with the above device in our database.

You are viewing the drivers of an anonymous computer which may be not the same with your current computer. These driver(s) may not work with your computer. Please click on the link below to download, scan and get the correct drivers.

Why do i see many drivers ?
Below is a list of drivers that may be suitable for your device. With the different devices, they can have the same driver , it’s because they all use the same chip manufacturer.

How to select driver?
If you are looking for an update , pickup the latest one. If your driver isn’t working, use the driver having the same OEM with the your laptop/desktop brand name.
Watch this video to see how it works — click here

Исправляем ACPI на Samsung N250

Итак, ACPI — это универсальный интерфейс к некоторым функциям аппаратного обеспечения современных компьютеров, от управления питанием и контроля состояния батарей до запроса возможностей подключенных внешних дисплеев.
Он состоит из нескольких конфигурационных таблиц, одна из которых содержит код для виртуальной машины, работающей в ядре операционной системы. Виртуальная машина, существенно усложняющая реализацию ACPI, была добавлена для того, чтобы сделать систему настолько гибкой, насколько это возможно.

В теории, такая система должна была сделать драйвера для чипсета ненужными. Она весьма мощная (если не сказать «раздутая»), и вполне может справиться с такой задачей; например, на Маках ACPI используется весьма широко и грамотно.

В реальности, однако, поставщики PC-совместимых систем зачастую включают ошибочные или неполные таблицы ACPI, и не последней причиной для этого является vendor lock-in. Таким образом, эти системы требуют использования нетривиальных обходных путей, зачастую недокументированных и тоже не всегда корректно работающих. Вместо этого, я попытался исправить ACPI для одной такой системы.

Компьютер, который у меня есть — нетбук Samsung N250+. У него достаточно неплохое «железо» (за исключением охочей до батарейки и вообще кривой WiFi-карточки Broadcom, которую я сразу же заменил на аналогичую Atheros), но качество BIOS-а весьма печальное. На момент релиза не было даже возможности включить (или выключить) WiFi из Linux-системы: его состояние можно было изменить только через CMOS Setup Utility. На данный момент драйвер есть, но он использует фундаментально порочный подход, и страдает от некоторых проблем.

Исследование текущего состояния

Поддержка возможностей нетбука, для которых код в ACPI отсутствовал, изначально была реализована в модуле ядра easy slow down manager, который в итоге был принят в ядро как samsung-laptop.c.

Как видно на строке 725 исходного кода, этот драйвер использует вызовы SMI (и интерфейс Samsung под названием SABI) для того, чтобы устанавливать уровень подсветки, изменять «режим производительности» (который на самом деле всего лишь меняет скорость вращения вентиляторов) и включать питание беспроводному модулю. SMI-вызов — это команда, которая заставляет ЦП активировать так называемый режим управления системой (SMM), специальную возможность чипсета и процессора, одинаково похожую на гипервизор и руткит.

BIOS может настроить чипсет так, чтобы он перехватывал определенные операции (например, доступ к выбранным регионам памяти или портов ввода-вывода) и активировал SMM, ОС не может ни обнаружить факт входа в SMM (кроме как косвенными методами), ни прервать его, ни предотвратить. После этого, BIOS может выполнить произвольный код: например, SMM используется для того, чтобы сэмулировать для старых ОС (например, ДОС) поддержку PS/2-мыши в тех случаях, когда подключена USB-мышь. Более того, область памяти, выделенная для обработчика SMM, ни при каких обстоятельствах не доступна ОС, делая прямой анализ логики ее работы невозможным.

К счастью, в этом случае вызовы SMI, скорее всего, меняют лишь пару байтов, и, если повезет, можно будет определить их расположение, не изучая код режима SMM.

Рассмотрим поближе таблицы ACPI. Существует множество их типов, но в данном случае важна только одна, DSDT — таблица с байткодом обработчиков многих системных событий.

Для извлечения таблицы из системы и модификации ее кода нам потребуются две утилиты: «acpidump» и «iasl». На Debian-подобной ОС они находятся в пакетах с тем же названием.

Для наглядности, я оформил таблицу с историей моих изменений как репозиторий github; начальное состояние содержится в этом коммите. Как видно, таблица весьма длинная: более 5000 строк. Таблицы длиной более чем в 25000 строк встречаются вполне регулярно.

При попытке скомпилировать таблицу обратно в байткод (наберите make ) без каких-либо изменений компилятор выведет несколько ошибок и замечаний. Их достаточно легко исправить, глядя только на сообщения и спецификацию ACPI; в этой теме форума Gentoo есть несколько неплохих подсказок. Кстати, она на семь лет старше моего нетбука, но советы до сих пор актуальны. Исправленную таблицу можно увидеть здесь.

Чиним подсветку

У моего нетбука светодиодная подсветка, и поэтому ее яркость можно менять, просто включая ее на определенную долю одинаковых интервалов времени, например, для затемнения на 30% можно держать ее включенной 70% времени. Чтобы мерцание не было заметно, это переключение (ШИМ) происходит на частоте, заведомо превышающей чувствительность человеческого глаза — скажем, 200кГц вполне достаточно.

В данном случае, скважность ШИМ, вероятно, изменяется встроенным графическим контроллером. Вот он на шине PCI:

Цифры «00:02.0» — адрес устройства на шине. Зная этот адрес, можно запросить или изменить параметры устройства, так как Linux предоставляет множество точек управления через sysfs. Одна из них позволяет читать и записывать конфигурационное пространство PCI: блок из 256 байтов, в котором хранятся настройки устройства. Первые 64 байта в этом блоке имеют определенное спецификацией значение, а остальные могут свободно использоваться производителем для своих нужд.

Проверим, что происходит с конфигурацией при изменении уровня подсветки (несмотря на то, что здесь приведен пример для Linux с открытым драйвером, все это можно сделать и для закрытого драйвера или даже на Windows; считать конфигурационное пространство можно и в ней):

Таким образом, байт по адресу 0xf4 управляет уровнем подсветки. Можно в этом убедиться, запустив команду sudo setpci -s 00:02.0 f4.b=80 (заменив 80 на нужный уровень подсветки).

Теперь перепишем DSDT так, чтобы обновлялось это значение (и, возможно, в процессе этого получится узнать, почему управление подсветкой через ACPI вообще не работает):

Согласно спецификации ACPI (приложение B, раздел 6.2, стр. 704), совместимое описание графического адаптера должно реализовывать методы _BCL , _BCM и _BQC . В нашем DSDT эти методы определены на строке 1767. Вот их откоментированный исходный код:

Чтобы изменить этот код для работы через конфигурационное пространство PCI, нужно добавить новое поле в структуру, описывающую это пространство. Адрес адаптера 00:02.0 соответствует значению 0x0002000 в ACPI (раздел 6.1.1, стр. 200). Устройство с таким адресом определено на строке 1325; за определением следует описание конфигурационного пространства PCI.

Как было упомянуто, первые 64 (0x40) байтов в этом пространстве зарезервированы для внутреннего испольования. Из-за этого ACPI даже не включает их в регион; он определен как OperationRegion(IGDP, PCI_Config, 0x40, 0xC0) , где третий аргумент означает отступ с начала области PCI_Config. Поле, управляющее яркостью, расположено по адресу 0xf4 во всем пространстве, и 0xb4 в этом регионе.

За определением региона следуют определения полей. Вся конструкция Field представляет из себя поток битовых полей (длина определена в битах, а не байтах), одно за другим, перемежающееся указанием смещений (Offset), задаваемых, напротив, в байтах. Назовем наше поле BLVL и включим его в структуру:

Так как система имен ACPI иерархическая, это поле теперь доступно глобально под именем _SB.PCI0.IGD0.BLVL (имя составлено из вложенных конструкций Device и Scope), и методы для управления яркостью теперь можно переписать так, чтобы они обращались к полю BLVL напрямую:

Обновленная DSDT также лежит в репозитории.

Во время тестирования своих изменений мне потребовалось отладить код в DSDT. Отладочный вывод работает при помощи команды вида Store (something, Debug). Для того, чтобы Linux отправил сообщение в лог, нужно добавить параметр ядра acpi.debug_level=0x1f .

Измененную и собранную ( make или iasl -tc dsdt.dsl ) DSDT теперь нужно отправить на место той, что предоставил поставщик. Для этого можно было бы перепрошить BIOS — но я даже не знаю внутреннюю структуру BIOS-а (и, если уж об этом зашла речь, способа его перепрошивки). Проще и безопаснее проинструктировать Linux использовать нашу DSDT вместо системной. Для этого, нужно собрать dsdt.hex (опция -tc инструктирует iasl генерировать массив Си, что и требуется), положить его в каталог include/ исходников ядра и установить опцию CONFIG_ACPI_CUSTOM_DSDT_FILE в «dsdt.hex». (Она недоступна, если включена опция CONFIG_STANDALONE, «Select only drivers that do not need compile-time external firmware» в «Generic driver options».)

Можно собрать ядро, установить его и перезагрузиться. Вуаля: теперь изменение яркости подсветки работает со стандартным драйвером ACPI. (Например, echo 7 >/sys/class/backlight/acpi_video0/brightness ).

Другие функции

Для того, чтобы найти другие похожие поля, изменяемые кодом в SMM, я написал простой скрипт. Нужно отметить, что некоторые устройства, а именно мосты PCI Express и сетевые адаптеры, порождают множество самопроизвольных изменений.

К сожалению, ни скорость вентилятора, ни выключатель беспроводного модуля не оказались связаны ни с какими изменениями в конфигурационном пространстве. Вероятно, они производятся через Embedded Controller или интерфейс SMBus, что означает отсутствие постоянных изменений в системной памяти.

Более того, даже если бы я обнаружил интерфейс отключения беспроводного модуля, я бы не смог использовать стандартный способ его представления системе — из-за отсутствия такого способа в природе. На ноутбуках, где этот интерфейс действительно задан в ACPI, существует платформенно-специфичный драйвер для его обработки (в отличие от подсветки, для которой существует общий стандарт).

Что такое 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, обеспечивающий поддержку компьютером новой архитектуры. То есть со старым оборудованием новый стандарт был несовместим.

Разумеется, это повлекло за собой обновление парка компьютеров. Как это обычно делается, мы с вами, уважаемые читатели, очень хорошо знаем. За примером даже ходить далеко не надо — достаточно вспомнить историю с PCI-E. Правда, парк компьютеров еще не полностью обновился, ведь апгрейд обходится достаточно дорого. Но, как ни крути, плата без PCI-E уже считается устаревшей. С ACPI было точно так же, только польза от него не так сомнительна. Скорее даже наоборот, ведь вместе с ACPI пришел APIC, а это значит, что одно прерывание теперь могло использоваться несколькими устройствами! Для того времени это была настоящая сенсация. Первым процессором с поддержкой ACPI можно считать самый ранний Celeron, однако поддержка нового интерфейса была реализована настолько криво, что эту функцию приходилось отключать. Важно также отметить, что ACPI окончательно вытеснил Plug and Play и, по словам создателей, «обеспечил использование существующих интерфейсных разъемов более безопасным и потенциально более эффективным способом». Помимо участка кода BIOS, в состав ACPI также входила улучшенная схема управления питанием (Advanced Power Management), прикладной программный интерфейс (API), специальный машинный язык (ACPI Machine Language) и еще некоторые полезные вещи. Появился новый термин — OS Power Management, где ACPI, разумеется, отводилась главная роль.

Основные цели разработки

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. Динамическое управление питанием отлично экономит батарею.

Acer TravelMate B117-M Missing ACPI Driver

I’ve reinstalled Windows 10, downloaded and installed all the drivers from Acers website but I have 1 missing driver, namely the ACPI 1025 (10251229) driver in Device Manager — help!

FAQ & Answers

brummyfan2 ACE Posts: 23,691 Trailblazer

Hi,
Go to Acer support site, download and install Chipset driver version 10.1.1.13
https://www.acer.com/ac/en/GB/content/support-product/6660?b=1

brummyfan2 ACE Posts: 23,691 Trailblazer

Ooh! I’ve never noticed that before — the pin hole for the battery reset will come in handy for other issues so thanks for that!

Unfortunately that hasnt resolved this issue as I just followed the instructions, re-installed the Chipset Drivers again but the Unknown Device is still showing up in Device Manager. I’ve got 10 of these laptops that I need to get ready but I cant give them out with a missing driver.

Thanks for you help with this.

brummyfan2 ACE Posts: 23,691 Trailblazer
brummyfan2 ACE Posts: 23,691 Trailblazer

That didnt work unfortunately. However, I am getting closer to finding a solution but still need a bit of help!

I just went through the 10 laptops and one was still as it was out of the box with Windows 10 S on, I used a digital key to upgrade it to Windows 10 Pro so I could run the DoubleDriver program on it. I backed up all of the drivers and then copied the folder with the drivers in to one of the other laptops and got it to search through the whole lot and voila! It found a driver it liked and installed it!

The fact it was called ACPI 1025 (10251229) in Device Manager may be a bit of a ‘red herring’, what it actually is, is the ‘Acer Airplane Mode Controller’ — so I now need to find the driver for this so I can get it installed on the other laptops.