омг получается для полной разлочки достаточно только модденого биос??

TiN у нас с пофигистом не получилось по такой схеме, но будем пробовать

А поговорить на тему разлочивания множителя с челами, написавшими райтмарк цпу клок утилити, никто не пробовал?

TiN

Если это так, то проблема должна решаться патчем БИОСа в паре мест, отвечающих за управление множителем. Но мне моя интуиция подсказывает, что здесь имеет место просто банальный баг и множитель по факту не меняется.
Дойду до знакомого с DFI Lanparty, возьму парочку процов и проведу опыты... Надеюсь.
Опишите, пожалуйста, подробные условия проведения опыта и возникновения этого бага. А также как он диагностировался. Чтобы можно было повторить его, а то мало ли NeoForce с пофигистом делают не так? Может версия БИОСа критична, может еще что...

Я уже на форуме где-то писал:

Не по теме, но все же: у замобиленных K7-процов StartFID может быть больше MaxFID, но это только до первого изменения FID.


В том то все и дело, что ReadOnly. И JTAG превратить его в RW не поможет.
Он может помочь только в случае запароленных MSR'ов (я с такими еще не встречался).

Так что забейте и не тратьте попусту время.

Ты же сам вкурсе, что существует backdoor регистры, посредством которых можно изменить значение определенного RO регистра. Мне почему-то кажется, что существует парольные MSR, которые позволяют изменить MAX_FID, только нам такая информация врядли будет когда-то доступна

Alex_BY это все стандартный CnQ механизм, и проверки осуществляются процессором в рантайме, так что увы.

FIDVID_CTL Register
This register holds configuration information relating to power management control. Accessing this
register is allowed if the device supports either FID control or VID control as indicated by CPUID. If
neither FID control nor VID control is indicated, accessing the FIDVID_CTL register causes a GP#
fault.

но у нас контроль стоит, так что все ок.

This register is used to specify new Frequency ID (FID) and/or Voltage ID (VID) codes to which to
change on the next FID/VID change. This register is also used to control how long to wait following a
FID/VID change before the PLL and voltage regulator are stable at the new FID/VID. This register is
persistent through a warm reset and is initialized to 0 on a cold reset.

Field Descriptions:
...
New VID (NewVID)—Bits 13–8. This field is the new VID to transition to. If an attempt is made to
write a NewVID value that corresponds to a voltage greater than the voltage that MaxVID
corresponds to in the FIDVID_STATUS register then the MaxVID value is written
instead.See Table 71 on page 299 for VID values and their corresponding voltages. See
“Register Differences in Revisions of AMD NPT Family 0Fh Processors” on page 21 for
revision information about this field.
New FID (NewFID)—Bits 5–0. This field is the new FID to transition to. If an attempt is made to
write a NewFID value greater than MaxFID in the FIDVID_STATUS register then the
MaxFID value is written instead. See Table 80 for FID code translations.
...

вот...
так что как вариант, это либо заменить MaxFID in the FIDVID_STATUS register, но он рид онли, либо уточнить, каким образом проверяется что NewFID value greater than MaxFID (на предмет можно ли обойти эту проверку...)
ИМХО, все это проверяется на уровне биоса, так что соотвествующей модификацией биоса проверки можно обойти.
А JTAG - через JTAG можно сделать запись в регистры, но как...???

FIDVID_STATUS Register
This register holds status of the current FID, the current VID, pending changes, and maximum values.
Accessing this register is allowed if the device supports either FID control or VID control as indicated
via CPUID. If neither FID control nor VID control is indicated, accessing the FIDVID_STATUS
register causes a GP# fault.

Field Descriptions:
...
Max FID (MaxFID)—Bit 21–16. This field indicates the max FID.
...
Добавлено спустя 18 минут, 54 секунды


каким образом осуществляются? откуда инфа?

Откуда такая уверенность ?
Возможно и существуют, но не обязательно.



1. Что из себя представляют парольные MSR'ы ? Я, например, с ними ни разу не сталкивался. Надо будет выяснить. В документации на K8 они вроде упоминаются.

2. Пространство MSR'ов вроде как ограничено (аргументами команд RDMSR|WRMSR). По идее, простым перебором можно выяснить существующие читабельные MSR'ы и сравнить их список со списком MSR'ов из документации. Далее можно пытаться выявлять различия и пробовать выяснять назначение обнаруженных "лишних" регистров. Вот только самые интересные регисты наверняка становятся видимыми только при выполнении определенных условий. Так что существование всех регистры простым перебором выяснить все равно не удастся.



Вполне вероятно, особенно учитывая, что нам до сих пор не доступна информация по разблокированию процов, выпущенных еще черт знает когда.

ЗЫ:

Кстати, гораздо интереснее разобраться н ес MSR'ами, а с микрокодом.
Помнится, где-то писали, что на K8 должны были ввести микрокодовые апдейты (как на интелах). Кому что известно на эту тему ?

вот, нашел на каком-то сайте, правда для пня-м:

Then here is a small explanation:
Each processor x86 comes with a unit from specific registers which make it possible to know and to modify in certain cases the configuration of the processor… The numbers of the MSR and their role is described in the documentation of the processor. They are of course specific to each processor, then which is the interest?
On Pentium M, there is 2 very interesting MSR: 0x198 and 0x199. They are used in the energy management, and allow to modify the multiplying coefficient and the voltage of the processor. This allows underclocker the processor and to reduce the voltage in order to increase autonomy and to decrease the release of heat.
Under Windows of the software as NHC do it, but not under Linux.
The two joined programs make it possible to read and write MSR, thanks to the interface kernel/Dev.cpu/0/msr (Indeed the instruction assembler cannot be carried out directly because of the privileges defined by Intel). It is necessary thus that the module msr is charged (“modprobe msr” in root), or whereas the kernel is configured properly.
This code was tested with a kernel 2.6.12 on a P-M 760.
A bond towards a site on these MSR of Pentium M:
http://www.x86-secrecy.COMarticlescmg5m100-Nitxpm-8.htm
To compile any option particular to announce: GCC write_msr.C - O write_msr.
Just a detail: it is necessary that the program is launched in root (because of protections of access always…)

Код:
_________________________________________________________________________________________________________________________________
/* Programme d'ecriture de MSR - Utilise l'interface kernel     */
/* Donc que le support soit compile dans le noyau ou que le     */
/* module msr soit charge (modprobe msr)             */
 
/* D'apres /usr/src/linux/arch/i386/kernel/msrc.c :        */
 
/*
* msr.c
*
* x86 MSR access device
*
* This device is accessed by lseek() to the appropriate register number
* and then read/write in chunks of 8 bytes. A larger size means multiple
* reads or writes of the same register.
*
* This driver uses /dev/cpu/%d/msr where %d is the minor number, and on
* an SMP box will direct the access to CPU %d.
*/
 
#include <stdio.h>
  #include <stdlib.h>
#include <sys/types.h>
#include <unistd.h>
#include <sys/stat.h>
#include <fcntl.h>
 
 
 
int main(int argc, char **argv)
{
    unsigned long long int value;
    unsigned int number;
    int fd;
 
    printf("Write MSR - Write Specifc Model Register\n");
 
    if(argc < 3)
    {
        fprintf(stderr,"\nUsage : %s <MSR number> <value>\nValues MUST be given in Hexadecimal format\n",argv[0]);
        exit(0);
    }
     
    sscanf(argv[1],"%x",&number);
    sscanf(argv[2],"%Lx",&value);
 
    printf("MSR number :\t0x%x\nMSR value :\t0x%Lx\n",number,value);
 
    if(setuid(0) != 0)    // On prend les droits root pour pouvoir ouvrir le fichier
    {
        fprintf(stderr, "\nYou must be root to run this program or have the setuid bit set.\n");
        exit(-1);
    }
     
    if((fd = open("/dev/cpu/0/msr",O_WRONLY)) == -1)
    {
        fprintf(stderr,"\nOpen error on /dev/cpu/0/msr\n");
        exit(-1);
    }
    if(lseek(fd,number,SEEK_SET) == -1)
    {
        fprintf(stderr,"\nSeek error in /dev/cpu/0/msr\n");
        exit(-1);
    }
    if(write(fd,&value,8) != 8)
    {
        fprintf(stderr,"\nWrite error in /dev/cpu/0/msr\n");
        exit(-1);
    }
    close(fd);
    return 0;
}

Добавлено спустя 1 минуту, 45 секунд
____________________________________________________________________

но похоже, на пне регистры типа R\W, а не Read Only...
Добавлено спустя 57 секунд
а вообще вот эта ветка интересная: http://www.xtremesystems.org/forums/sho ... hp?t=80608
и вот эта: http://www.overclocking-masters.com/for ... 722-p1.htm
Добавлено спустя 11 минут, 48 секунд
забыл добавить: пояснения к коду - автоперевод с французского, так что не удивляйтесь

А как быть тогда с сертифицированными CPU-Z репортами на Opteron 144 с множителем 11 ?

На хтриме подробнее инфа, последние ветки треда unlocking A64's

xKVtor Я несколько раз пытался выяснить у stargaz0r'а, как он их читает - молчит как партизан по этому вопросу Я знаю точно, что при обычной попытке чтения парольного MSR без предварительных процедур - возникает исключение. По этому поводу может также высказаться тов. Jungle, но он предпочитает вести партизанскую войну и спамить коллегам, считая их конкурентами
Ходили мифы в свое время о некой AMDшной утилите, которая могла менять множитель у заблокированных K7, так что по идее механизм существует.
Alex_BY эта инфа абсолютно бесполезна, даунклок мало кого интерисует
Я вот только что задумался, может даже не процессором, а MB, но всеравно в рантайме.

я этот код рассматривал в основном с точки зрения чтения/записи в мср...

Еще немного оффтопика.

Нашел здесь кое-какую инфу по парольным MSR'ам:



Осталось выяснить:

1) В работе с парольными MSR'ами участвует регистр EDI. Распространяется ли этот механизм на все процессоры ?

2) В EDI указатель на пароль или сам пароль? Если первое (что вероятнее), то какой длины должен быть пароль и сколько дается попыток.

3) И самое главное : какие же MSR'ы требуют парольного доступа ?


Добавлено спустя 3 минуты, 1 секунду
[крик души] Люди добрые, автор, господа модераторы! Поправьте плиз ЭТО сообщение. А то этот лист читать невозможно, расползлось все на полтора экрана! Не у всех же стоит разрешение экрана 1600x1200...

xKVtor
1) EDI:ESI. Да, распространяется на все процы. Правда, у каждого проца свой список MSR'ов и свой список запароленных MSRов
2) в EDI:ESI указывается сам пароль
3) склероз, но могу поискать список.

Откуда дровишки ? В AMD-шных доках, что я на данный момент просмотрел, о них лишь упоминается, но описания механизма работы нет.


Если не сложно, хотя бы на AMD-шники. Желательно с практическими примерчиками кода и указанием причины, по которой их запаролили.

xKVtor
по поводу первого - скачай HWDirect и посмотри. Единственное, что бывают MSR с защитой и от чтения.
Добавлено спустя 1 минуту, 25 секунд
по поводу второго:
http://cbid.amdclub.ru/html/undocmsrs.html

Root

Спасибо за ценную инфу!
День, точнее ночь, прожита не зря.

Root писал(а):

http://cbid.amdclub.ru/html/undocmsrs.html

Ну вот и этот товарищ на что-то сгодился.

xKVtor
И этот товарищ, кстати, хвастался на XS наличием у него AMD Hardware Debug Tool которой К8 процы проверяются на фабрике. Однако поделиться увы, отказался.


Это факт ИМХО. Ведь множитель процессора задается уже после всех стадий упаковки и сборки, и не иначе как программно. Всякие там Laser-сut - миф чистейшей воды.
Добавлено спустя 7 минут, 10 секунд
Кстати, жителям Украины могу выслать компакт со всеми моими изысканиями по поводу сабжа. там метров 400, включая доки и проги. Ну и россиянам тоже могу, если возьмут на себя гимор с доставкой )