Прививаем PowerNow! десктопным материнским платам
реклама
(version 0.01 от 29-03-2004)
Уже почти четыре месяца прошло с момента обнаружения возможности переделки десктопных процессоров Athlon XP в мобильные. Практическую пользу этого открытия в первую очередь оценили владельцы процессоров с заблокированным коэффициентом умножения, поскольку в мобильных процессорах существует воозможность не просто менять этот коэффициент, а делать это на лету, прямо по ходу работы операционной системы.
К сожалению, судя по тому, что в соответствующей ветке форума обсуждение мобилизации атлонов идет не очень активно, интерес к этой теме немного поутих. А жаль... Надеюсь, эта статья заставит взглянуть немного по-другому на тему мобилизации десктопных процессоров.
Сразу определюсь с термином PowerNow! В контексте данной статьи под этой технологией я буду понимать способность системы в автоматическом режиме изменять напряжение и коэффициент умножения (далее просто КУ) процессора в зависимости от загрузки процессора. Или хотя бы только КУ.
Итак, рассмотрим случай, когда пользователь уже замобилил ( / мобилизовал / мобилизировал) свой процессор, а чипсет его материнской платы поддерживает смену КУ.
Поскольку подавляющее большинство существующих материнских плат под K7 не обеспечивает поддержку PowerNow!, то пользователю приходится вручную выставлять нужный КУ. Доступные способы:
- Пропатчить биос Bios Patcher’ом от apple_rom’а с целью установить желаемый коэффициент умножения на этапе загрузки системы.
- Изменять КУ при загрузке ОС специальными утилитами (CPUMSR, CrystalCPU, а теперь еще и CBI).
Эти два способа не взаимоисключающие, их можно использовать совместно.
Наверняка пользователь захочет установить (и установит) максимальный КУ для своей системы. В дальнейшем, КУ можно будет при необходимости вручную понизить теми же утилитами. Это может быть полезно в случае, если ожидается простой компьютера, когда загрузка процессора невелика. Снизится частота процессора, соответственно уменьшится тепловыделение. И как следствие, можно тем или иным способом (об этом в следующей статье) понизить частоту вращения вентиляторов и снизить шум системы охлаждения. К сожалению, если на время простоя системой запланированы какие-то действия (запуск антивирусника или программы обслуживания дисков), резко повышающие загрузку процессора, то им придется довольствоваться имеющейся вычислительной мощностью.
В мобильных системах на платформе AMD (мобильный процессор + материнская плата с поддержкой мобильных процессоров) пользователь освобожден от необходимости постоянно следить за частотой процессора. Здесь этим параметром автоматически (в зависимости от загрузки CPU) вовсю управляет особый драйвер. Для системы MS Windows XP SP1 это драйвер процессора. Для остальных версий OC от MS – специальный PowerNow! драйвер (своеобразные «костыли», как я его про себя называю ) от самой AMD. Драйвер несколько десятков раз в секунду оценивает степень загрузки процессора и при необходимости корректирует КУ процессора: при полной загрузке частота максимальная, при нулевой – минимальная.
Возникает закономерный вопрос: что же мешает использовать возможности упомянутых драйверов для мобильных процессоров в десктопных компьютерах ? Этот вопрос я как раз и попытаюсь осветить в этой статье.
Для того, чтобы на компьютере можно было заставить работать технологию PowerNow!, необходимо чтобы его компоненты отвечали следующим требованиям:
1. Процессор. Очевидно, что он должен быть мобильным (оригинальным или переделкой из десктопного).
2. Материнская плата. Здесь должен выполняться целый комплекс условий:
2.1 Чипсет, на котором изготовлена материнская плата. Должен поддерживать специальный цикл системной шины (FID/VID change), предусмотренный для изменения вольтажа или КУ. Из всех известных чипсетов для K7 на сегодняшний день этому условию пока не удовлетворяют только чипсеты nForce/nForce2 от nVidia (точнее, нет достоверной информации о том, что они это умеют делать).
2.2 SoftVID. На материнской плате должны быть разведены ножки процессора, через которые процессор информирует чипсет о необходимом для его работы напряжении.
2.3 BIOS. Должен обнаруживать присутствие мобильного процессора и соответственным образом настраивать следующие компоненты:
2.3.1 Чипсет (через настройку ответственных конфигурационных регистров Host Bridge’а)
2.3.2 Процессор (изменить КУ и рабочее напряжение процессора на максимальные для ускорения последующей загрузки ОС, но это не обязательно)
2.3.3 Память.
2.3.3.1 Для т.н. устаревших (legacy) операционных систем (w9x/w2k), использующих драйвер от AMD, БИОС должен создать в памяти блок данных PSB (Perfomance State Block), содержащий в том числе и информацию по возможным состояниям процессора (т.н. Perfomance States или PStates). Каждое состояние описывается парой “КУ + соответствующее ему напряжение”. Таких пар для каждого процессора может быть несколько (обычно 3-4). Теоретически БИОС должен оставлять в памяти лишь PStates для установленного в системе процессора. На практике, как я понял, многие биосы оставляют в памяти подобные таблицы для всех поддерживаемых материнкой процессоров.
2.3.3.2 Для операционных систем, в полной мере поддерживающих ACPI (WinXP
SP1): создать или активировать в таблицах ACPI необходимые вспомогательные объекты (_PCT, _PPC, _PSS и некоторые другие). Упомянутые объекты создаются/изменяются БИОСом для поддержки только установленного в системе процессора.
3 Операционная система, точнее соответствующий драйвер. Требуется наличие мобильного процессора. Кроме того:
3.1 если это драйвер от самой AMD, то он проверяет наличие в памяти блока PSB, и в дальнейшем управляет КУ и напряжением на основе содержащейся там информации. (этот драйвер НЕ использует ACPI из п.1.3.3.2)
3.2 если это драйвер от MS (в случае WinXP SP1), то он действует на основе информации об объектах, содержащейся в таблицах ACPI (в основном DSDT). Надо отметить, что тот же драйвер (amdk7.sys) устанавливается и для десктопных процессоров, но в этом случае частоту/вольтаж он, естественно, не регулирует. (Надо сразу упомянуть, что этот драйвер НЕ использует PSB из п.1.3.3.1)
Легко заметить, что выполнения условий 1, 2.1, 2.3.1 можно добиться и для десктопной материнской платы.
Пункт 2.2 выполнить практически нереально – это потребует перепайки платы: даже если это возможно теоретически, никто в здравом уме за это не возьмется. От этого пункта, как и от п.2.3.2, можно отказаться.
Под вопросом остаются пункты 3 и 2.3.3. Очевидно, что они напрямую связаны друг с другом.
Частотой и напряжением процессора в процессе работы непосредственно управляет только драйвер операционной системы. На БИОС же (поскольку он уже идет с материнской платой, и лучше знает, поддерживает ли она мобильные процессоры и какие именно) возлагается задача правильно распознать процессор и передать необходимые параметры работы процессора соответствующему драйверу операционной системы (п.2.3.3). Если драйвер не получит такой информации, то он не задействует функции PowerNow!
В этой взаимной зависимости как раз и заключается проблема для жаждущих PowerNow! для десктопов. Чтобы ее разрешить, необходимо:
- либо модифицировать биос, чтобы он создавал нужные драйверу структуры.
- либо написать свой собственный драйвер, который кроме функций регулирования частоты/вольтажа возьмет на себя еще и функции биоса по распознанию железа (процессора и чипсета). Нечто подобное обещал в своем FAQ’е реализовать автор программы CpuMSR. Но что-то он не торопится. А жаль... Базу данных по процессорам и чипсетам можно было бы обновлять через инет по мере появления новых моделей. Кстати, очень заманчиво выглядит идея расширять имеющийся для процессора набор PStates за счет добавления новых пользовательских и/или редактирования старых состояний. Неплохо было бы дать возможность пользователю самому выбирать, при каком уровне загрузки процессора переходить на то или иное состояние. Подобные нововведения дали бы такому драйверу конкурентное преимущество перед стандартными, которые богатством настроек не отличаются. Кстати, написание подобного драйвера – дело очень перспективное, поскольку он пригодится в будущем для процессоров K8, которые, как известно, изначально поддерживают смену КУ.
Но это все мечты. Для меня, простого смертного, написание драйвера ядра является нереальной задачей. Именно ядра, поскольку потребуется выполнять некоторые инструкции процессора (например, WRMSR, RDMSR), которые в защищенном режиме позволены лишь приложениям с CPL=0. Можно, конечно, прибегнуть к услугам специальных драйверов (например, TVicHW32 от Victor Ishikeev), умеющих исполнять код приложений на нулевом уровне привилегий. Но я сомневаюсь в 100%-й надежности такого способа.
Вот, собственно, почему я сосредоточил свои усилия на попытке модифицировать БИОС. Из всех БИОСов на сегодняшний день лучше всех изучены БИОСы от фирмы AWARD. Именно с авардовскими биосами я и начал экспериментировать. К сожалению, биосы от AMI, PHOENIX (родные) и др. производителей остались в стороне из-за недостатка информации по ним
Начать решил с попытки втиснуть PSB куда-нибудь в диапазон адресов C0000h...FFFFFh. Для этого создал PSB по правилам, описанным в даташите на K8. Затем на его основе по всем правилам создал ROM образ (так, чтобы PSB в нем начинался с начала параграфа). Этот образ затем вшил с помощью CBROM в биос материнской платы EPoX 8RDA. При загрузке этот образ оказывался как раз где-то в диапазоне D0000h...E0000h. Но, к моему величайшему удивлению, PowerNow! драйвер от AMD все равно ругался на несовместимость с моей системой и гордо сообщал, что установиться он установится, но работать не будет При этом он отказался более конкретно сообщить, что же его не устроило (не нашел PSB, там где ожидал; не понравился процессор или н-видиевский чипсет).
На материнской плате EPoX 8KHA+ этот трюк не сработал: любой ROM-образ, прошитый с помощью CBROM с параметром /PCI, биосом просто не обрабатывался. Может стоило попробовать варианты отличные от /PCI ? Скорее всего в данном случае проблема кроется в том, что биос этой материнской платы шибко продвинутый и обрабатывает только те образы, адреса которых указаны (на момент загрузки) в конфигурационных регистрах соответствующих PCI карт. Дальше я разбираться не стал, отложив решение этого вопроса “на потом”.
Недавно случайно пришла идея, поместить PSB в биос видеокарты . Этот образ всегда и везде распологается точно по адресу C0000h. Думаю, что сделать это реально, поскольку PSB для одного процессора занимает несколько десятков байт, а в биосах некоторых видеокарт неиспользуемого места, забитого символами FFh, гораздо больше. Надо будет поэкспериментировать.
Поскольку опыты с PSB удачными назвать сложно, то пришлось перейти к попыткам реализовать запасной вариант с использованием ACPI. Сразу скажу, что в этом направлении изыскания оказались более результативными (в противном случае и статьи бы не появилось )
Здесь я хотел было дать краткое описание этой технологии, но понял, что для этого потребуется отдельная статья. Вопрос этот интересный и обширный (только спецификация занимает около 500 страниц). Поэтому ограничусь толко упоминанием основных понятий, необходимых для успешной модификации.
Одной из компонент, составляющих технологию ACPI (Advanced Configuration & Power Interface), являются таблицы ACPI, главная из которых DSDT. На момент загрузки операционной системы они располагаются в памяти выше 1Mb. Таблицы могут содержать ссылки на другие таблицы, а так же исполняемый AML (ACPI Machine Language) псевдокод, который содержит описание объектов, и применимых к ним методов, и пр. необходимую информацию. AML код при необходимости можно дизассемблировать в ASL (ACPI Source Language) для внесения изменений. Этим я и воспользовался.
Отличие таблиц DSDT для мобильной и десктопной систем, состоит в том, что мобильная имеет несколько дополнительных объектов (_PCT, _PSS) и метод (_PPC), которые как раз и позволяют операционной системе задействовать технологию PowerNow!
(Есть еще пара отличий в другой таблице FADT: объекты PSTATE_CNT и CST_CNT. Но я их трогать пока не буду)
Надеюсь, все уже догадались, что требуется сделать в данной ситуациии
Правильно! Добавить в десктопную таблицу DSDT несколько новых объектов, или активировать их, если они там уже есть. Другой вопрос: как это сделать ? К счастью, для этого не потребуется добавлять в биос новый код, который бы вычислял местоположение таблиц ACPI в памяти и модифицировал их. В случае с биосами от AWARD все обстоит гораздо проще: таблицы ACPI там содержатся в виде отдельного модуля ACPITBL.BIN, который можно извлечь с помощью CBROM, отредактировать, и обратно запаковать с помощью того же CBROM.
С этого мометна, как мне кажется, проще и понятнее рассмотривать все манипуляции на конкретном примере. В качестве подопытного я взял материнскую плату EPoX 8KHA+, точнее, БИОС для нее (файл 8KHI3916.BIN).
Этап 1. Извлечение таблиц ACPI из БИОС материнской платы:
Для этого потребуется CBROM (BIOS ROM Combination Utility) – официальная утилита от AWARD. Позволяет манипулировать (добавлять/извлекать/удалять) дополнительными образами, содержащимися в файле БИОС материнской платы. Скачать ее всегда можно с сайта http://www.rom.by
Честно признаться, я сильно надеюсь, что эта утилита у Вас уже имеется и Вы прекрасно знаете, для чего она существует. В противном случае я Вам крайне не рекомендую претворять в жизнь описанные далее в этой статье действия по модификации биоса !!! Сразу предупреждаю, что за возможный ущерб, который Вы себе причините после попытки реализации на практике описанных в этой статье действий Я НИКАКОЙ ОТВЕТСТВЕННОСТИ НЕ НЕСУ !!! Действуйте на свой страх и риск!
Командная строка для извлечения таблиц:
CBROM.exe 8KHI3916.BIN /ACPI extract
В ответ на запрос об имени сохраняемого файла введите: ACPITBL.BIN <Enter>
Этап 2. Удаление старого ACPITBL.BIN из БИОС материнской платы:
Файл с таблицами мы извлекли, теперь его можно удалить из файла с БИОСом.
Предварительно не забудьте сохранить на всякий пожарный оригинальный файл с БИОС.
copy /b 8KHI3916.BIN 8KHI3916.BIN.original
CBROM.exe 8KHI3916.BIN /ACPI release
Этап 3. Выделение таблицы DSDT из ACPITBL.BIN
Как уже ранее упоминалось, ACPITBL.BIN содержит несколько таблиц. Нас же пока интересует только одна: DSDT. Она начинается с сигнатуры DSDT и распологается последней. Т.е. все содержимое ACPITBL.BIN начиная с сигнатуры DSDT и до конца файла является таблицей DSDT. Извлечь ее можно с помощью любого HEX-редактора. Сохраним ее в файл с названием DSDT.hex. Ту часть файла ACPITBL.BIN, которая предшествует таблице DSDT, также необходимо сохранить (например, в файл OTHERS.hex) – она нам еще пригодится.
Для проведения этого этапа можно воспользоваться написанной мною специально для этого случая простенькой утилиткой GetDSDT.exe
GetDSDT.exe ACPITBL.BIN
Этап 4. Дизассемблирование таблицы DSDT: AML -> ASL.
Полученную таблицу DSDT необходимо дизассемблировать (хотя здесь больше уместно понятие декомпилировать). Для проведения этой операции потребуется интеловская утилита IASL. Скачать ее можно с сайта Интела.
iasl.exe –d DSDT.hex
В результате получим файл с названием DSDT.dsl, который содержит исходный код на языке ASL. Открываем его в любом текстовом редакторе и убеждаемся, что в этом файле отсутствуют объекты, которые мы собираемся добавлять. Для этого достаточно запустить поиск по словам: _PCT, _PSS, _PPC. Если ничего не найдено, то переходим к следующему этапу.
Этап 5. Конструирование объектов _PCT, _PSS, _PPC.
Рассмотрим эти объекты по порядку.
_PCT (Perfomance Control) Этот объект описывает контрольный регистр и регистр состояния. Имеет следующий вид (описание взято из даташита на K8, но подходит и для K7):
Name (_PCT, Package (2)// Perfomance Control Object
{
// ResourceTemplate () {Register (FFixedHW,0,0,0)} // Control
Buffer () {
0x82,
0xC,0,
0x7F,
0,
0,
0,
0,0,0,0,0,0,0,0,
0x79,0
},
// ResourceTemplate () {Register (FFixedHW,0,0,0)} // Status
Buffer () {
0x82,
0xC,0,
0x7F,
0,
0,
0,
0,0,0,0,0,0,0,0,
0x79,0
},
}
) // End Of _PCT object
Этот объект постоянен, т.е. не изменяется в зависимости от процессора или каких либо других факторов.
_PCT (Perfomance Present Capabilities) Метод, возвращающий номер минимально допустимого (на момент вызова) состояния PState. PState с наименьшим номером (0) содержит наибольший КУ, а с наибольшим номером -- наименьший КУ.
Этот метод применяется только в случае, когда необходимо искусственно ограничить частоту процессора. Например, в ноутбуке, когда он работает от батарей. Для настольных систем этот метод должен всегда возвращать ноль (номер PState с максимальным КУ).
Method (_PPC, 0, NotSerialized)
{
Return (0x00)
}
_PSS (Perfomance-Supported States) – самый интересный объект. Именно он задает тот набор состояний PStates (пары КУ+вольтаж), в которых может пребывать процессор. Очевидно, что этот объект индивидуален для каждой модели процессора.
Пример такого объекта, состоящего из двух PStates для замобиленного Duron1200(Morgan):
реклама
Name (_PSS, Package (0x02) // 02 – количество PStates
{
Package (0x06)
{
0x000004B0, // CoreFreq = 1200 MHz (ожидаемая частота процессора)
0x000061A8,
// Power = 25000 mW (ожидаемое энергопотребление, взято от балды )
0x00000064, // TransitionLatency = 100 mks (лучше не менять!)
0x00000007, // BusMasterLatency = 7 mks (лучше не менять!)
0xE3202802, // Control Field
// (зависит от NewFID, NewVID, IRT, RVO, Res, PLL_Lock_Time, MVS, VST)
0x00000002, // Status Field (зависит от NewFID и NewVID)
// Multiplier = 12.0; NewFID = 02h; NewVID = 00h
},
Package (0x06)
{
0x000003E8, // CoreFreq = 1000 MHz
0x00005DC0, // Power = 24000 mW
0x00000064, // TransitionLatency = 100 mks
0x00000007, // BusMasterLatency = 7 mks
0xE320280E, // Control Field
0x0000000E, // Status Field
// Multiplier = 10.0; NewFID = 0Eh; NewVID = 00h
}
})
ВНИМАНИЕ! Поскольку предполагается использование данного объекта на материнской плате, которая не поддерживает SoftVID, то значение напряжения здесь устанавливается как NewVID = 00h (1.85/2.00 Вольта !!!)
В ближайшем будущем постараюсь более подробно описать, что означает каждая аббревиатура, за что отвечает и какие значения принимает (некоторые сведения даны в ptchACPI.cfg)
Все три объекта вместе составляют один, который называется \_PR.CPU0 и располагается сразу за объектом \_PR. Для облегчения процесса конструирования пришлось написать еще одну утилитку ptchACPI.exe, которая на основе информации из файла конфигурации ptchACPI.cfg конструирует объект \_PR.CPU0 и записывает его в файл CUSTOM.ASL.
Далее требуется лишь добавить полученный объект в файл DSDT.dsl сразу после объекта \_PR и результат записать в файл newDSDT.dsl.
Пример: (интересующий фрагмент файла DSDT.dsl до изменения)
/*
* Intel ACPI Component Architecture
* AML Disassembler version 20040211
*
* Disassembly of DSDT, Sun Mar 07 20:48:17 2004
*/
DefinitionBlock ("DSDT.aml", "DSDT", 1, "VIA694", "AWRDACPI", 4096)
{
Scope (\_PR)
{
Processor (\_PR.CPU0, 0x00, 0x00004010, 0x06) {}
}
// Здесь будет вставлен объект \_PR.CPU0
Name (\_S0, Package (0x04)
{
0x00,
0x00,
0x00,
0x00
})
................
А это интересующий фрагмент файла DSDT.dsl ( newDSDT.dsl) уже после внесения изменений:
/*
* Intel ACPI Component Architecture
* AML Disassembler version 20040211
*
* Disassembly of DSDT, Sun Mar 07 20:48:17 2004
*/
DefinitionBlock ("DSDT.aml", "DSDT", 1, "VIA694", "AWRDACPI", 4096)
{
Scope (\_PR)
{
Processor (\_PR.CPU0, 0x00, 0x00004010, 0x06) {}
}
//========================================
Scope (\_PR.CPU0)
{
Name (_PCT, Package (2)// Perfomance Control Object
{
// ResourceTemplate () {Register (FFixedHW,0,0,0)}// Control
Buffer ()
{
0x82,
0xC,0,
0x7F,
0,
0,
0,
0,0,0,0,0,0,0,0,
0x79,0
},
// ResourceTemplate () {Register (FFixedHW,0,0,0)}// Status
Buffer ()
{
0x82,
0xC,0,
0x7F,
0,
0,
0,
0,0,0,0,0,0,0,0,
0x79,0
},
}
) // End Of _PCT object
Method (_PPC, 0, NotSerialized)
{
Return (0x00)
}
Name (_PSS, Package (0x02)
{
Package (0x06)
{
0x000004B0, // CoreFreq = 1200 MHz
0x000061A8, // Power = 25000 mW
0x00000064, // TransitionLatency = 100 mks
0x00000007, // BusMasterLatency = 7 mks
0xE3202802, // Control Field
0x00000002, // Status Field
// Multiplier = 12.0; NewFID = 02h; NewVID = 00h
},
Package (0x06)
{
0x000003E8, // CoreFreq = 1000 MHz
0x00005DC0, // Power = 24000 mW
0x00000064, // TransitionLatency = 100 mks
0x00000007, // BusMasterLatency = 7 mks
0xE320280E, // Control Field
0x0000000E, // Status Field
// Multiplier = 10.0; NewFID = 0Eh; NewVID = 00h
}
})
}
//========================================
Name (\_S0, Package (0x04)
{
0x00,
0x00,
0x00,
0x00
})................
Этап 5. Ассемблирование таблицы DSDT: ASL -> AML
Для того, чтобы из ASL кода получить бинарник, опять воспользуемся интеловской утилитой:
iasl.exe newDSDT.dsl
В результате получаем новую таблицу DSDT в файле DSDT.aml.
Примечание:
На этом этапе могут возникнуть трудности Дело в том, что утилита IASL более продвинут, чем те, которыми пользовались разработчики БИОС (а пользуются они обычно компилятором от мелкософта). По этой причине она зачастую находит ошибки и выдает предупреждения при компиляции ASL файлов, которые только-что были ею же декомпилированы и вручную не изменялись.
Перед тем, как приступить к этому этапу, попробуйте скомпилировать не newDSDT.dsl, а оригинальный DSDT.dsl. Еще один вариант: на Этапе#4 пользуйтесь опцией –dc вместо –d. Тогда после декомпиляции IASL сразу же попытается скомпилировать полученный *.dsl файл. Если ему это не удастся и посыпятся еггоги и варнинги, то вам сюда: http://forums.gentoo.org/viewtopic.php?t=122145 или сюда http://www.cpqlinux.com/acpi-howto.html.
Этап 6. Воссоздаем файл ACPITBL.BIN
copy /b OTHERS.hex + DSDT.aml ACPITBL.BIN
Здесь:
OTHERS.hex - файл, который был создан на Этапе#3
DSDT.aml - файл, полученный на предыдущем Этапе#5
Этап 7. Запихиваем ACPITBL.BIN обратно в файл БИОСа материнской платы
CBROM.exe 8KHI3916.BIN /ACPI ACPITBL.BIN
Здесь:
ACPITBL.BIN – файл, полученный на предыдущем Этапе#6
8KHI3916.BIN – файл биоса, из которого на Этапе#2 была удалена таблица ACPI (ACPITBL.BIN)
Этап 8. Прошивка БИОСА
Надеюсь, с этим этапом Вы справитесь и без моих рекомендаций ))
Этап 9. Загрузка WindowsXP SP1, тестирование
Загружаете XP. В раздере панели управления смените тип энергосбережения с "настольного" на "портативный"/"экономия батарей". Все должно заработать.
Если нет, то попробуйте удалить драйвер процессора. Если вы устанавливали SP1 вручную, то вам просто необходимо проделать операцию по удалению старого драйвера. После перезагрузки ОС установит драйвер заново. Частота процессора должна меняться в зависимости от степени его загрузки.
Не забудьте прошить обратно оригинальный биос при смене процессора !!! Или хотя бы смените тип энергосбережения с "портативного"/"экономии батарей" на "настольный" Иначе WinXP вы загрузить не сможете.
Сразу заявляю, что прекрасно представляю все недочеты и недостатки этой статьи. В свое оправдание скажу лишь следующее. Учитывая те черепашьи темпы, с которыми статья писалась (н-да, шестидневная рабочая неделя не способствует литературному творчеству), на момент, когда она станет совершенной, она уже потеряет свою актуальность. Торжественно обещаю, что до тех пор, пока не угаснет мой интерес к этой теме, буду обновлять статью по мере поступления материала.
Благодарности:
- serj_'у за наводку на полезный даташит, с которого все и началось
- фирме Комсел за предоставленное оборудование.
- участникам форума на этом сайте
- всем остальным, кого я забыл здесь упомянуть
Планы на ближайшее будущее:
- Разобраться с софтом от AMD. Что же ему конкретно нужно для нормальной установки ? Необходимо также уточнить, в какой диапазон адресов записывается PSB.
- Разобраться, почему при установке в качестве минимального КУ=3x система в простое становится нестабильной и обычно в итоге зависает. И это при том, что с отключенным драйвером при установке КУ=3x вручную через CrystalCPU все работает великолепно.
- При совместном использовании BUS disconnect система ведет себя нестабильно. Понятно, что регистр CLK_CTL MSR, через который настраиваются параметры BUS disconnect, используется также во время спец. цикла. Нужно только уловить связь и выработать рекомендации. Есть подозрение, что причина в объекте CST_CNT из таблицы FADT, точнее в его отсутствии.
- Попробовать провести эксперимент по определению максимально допустимого количества PStates. Заодно определить, при достижении каких величин загрузки процессора драйвер выбирает тот или иной КУ. А то обычно складывается впечатление, что процессор работает только на двух частотах: максимальной или минимальной.
- Почитать про UPS'ы.
Огромные просьбы к владельцам ноутбуков/дескноутов на мобильных процессорах K7:
- Если вы пользуетесь драйверами от AMD для реализации PowerNow!, то сообщите пожалуйста, версию используемого драйвера (и ссылку на его расположение в инете), версию операционной системы и по возможности модель ноутбука.
- Вышлите мне ACPI таблицы, которые используются в вашем ноутбуке. WindowsXP (и возможно в W2K) сохранить их можно с помощью команды: regedit /e "ACPItbl.reg" HKEY_LOCAL_MACHINE\HARDWARE\ACPI (здесь "ACPItbl.reg" название файла, в который сохранится ветка реестра, содержащая образ ACPI таблиц)
- Если на вашем ноутбуке используется биос от AWARD, сохраните, пожалуйста, его образ с помощью утилиты AWDFLASH и вышлите мне, или киньте ссылку, откуда этот образ можно утянуть.
Поскольку, ко мне в руки до сих пор ни разу не попадали ноутбуки на мобильных процессорах AMD, ваша информация окажет неоценимую помощь в моих изысканиях.
Заранее благодарю.
PS: обсудить статью можно в форуме
Изменения/дополнения:
10-07-2004
Изменил форматирование текста. Надеюсь, статья стала более читабельной. Перевел сей опус из разряда ЗАПИСИ в СТАТЬИ.
31-10-2004
Некоторые мысли и замечания относительно технологии Cool'n'Quiet (PowerNow!)
Изменение 'мобильных' множителей процессоров AMD (немного справочной информации)
BIOS and Kernel Developer's Guide for AMD Athlon 64 and AMD Opteron Processors rev.3.08 [26094] -- весьма полезный документ, причем не только для K8, многие вещи справедливы для K7 (еще раз спасибо serj_'у за наводку).
реклама
Лента материалов
Соблюдение Правил конференции строго обязательно!
Флуд, флейм и оффтоп преследуются по всей строгости закона!
Комментарии, содержащие оскорбления, нецензурные выражения (в т.ч. замаскированный мат), экстремистские высказывания, рекламу и спам, удаляются независимо от содержимого, а к их авторам могут применяться меры вплоть до запрета написания комментариев и, в случае написания комментария через социальные сети, жалобы в администрацию данной сети.
Сейчас обсуждают