Die Sache mit den SIPs und Nforce2
1. Einleitung
Moin zusammen. Ich möchte einen Laberpost absetzen und glieder das Ganze mal, damit es etwas übersichtlicher wird. Grob gesprochen soll der Post um einen Messversuch gehen wo wir die SIP Werte vom Front-Side-Bus ermitteln.
2. Was sind SIPs ?
Ich möchte nur grob einmal wiederholen was
romSIPs sind. Einen ausführlicheren Post dazu hatte ich schon mal gemacht (
#1.704, wird noch aktualisiert). Romsips oder nur
SIPs [
Serial
Initialization
Packet] sind im Grunde Parameter (timings) vom Front-Side-Bus damit die Northbride mit der CPU komunizieren kann. Je nach Multiplikator und der Bus-Geschwindigkeit muss man andere Timings setzen damit die Kommunikation zwischen der CPU und Northbridge erfolgen kann. Die Angabe der SIP Werte erfolgt bei dem Nforce2 Chipsatz in Form einer Tabelle.
Wir wissen welcher Multiplikator welche Position hat, kennen jedoch keine direkte Zuordnung der SIP Werte zu den Werten in dieser Tabelle. Darum soll dieser Test durch Messen der einzelnen Multis die genauen Werte / Bit-Zuordnung helfen.
3. Wo erfolgt der Transfer?
Laut dem AMD Datenblatt erfolgt der Transfer der SIP Werte bei jedem CPU-Reset Befehl, damit neue Werte gesetzt werden können. Das braucht man zum Beispiel auch wenn mann im Betrieb bei einer XP-M CPU den Multiplikator wechselt. Dann muss jedesmal die SIP Werte neu gesetzt werden. Der Transfer erfolg jedesmal über den
Connect PIN. Hier müssen wir messen.
Damit wir die einzelnen Bits auch zuordnen können, müssen wir dazu parallel auch am benachbarten
K7CLKOUT Pin die Frequenz des Front-Side-Busses messen. Laut dem AMD Datenblatt sollte das Ergebnis in Etwa so aussehen:
4.Wie messen wir?
Gemessen wird an einem ASUS A7N8X 2.00 Deluxe. Damit wir die Messpunkte erfassen können hat das board rückseitig ein paar Ösen bekommen. Dazu wurde das BIOS angepasst und bestimmte und verschiedene (!) Multis haben bestimmte SIP Werte zum messen bekommen. Damit wir eine Zuordnung bekommen zwischen SIP Werte BIOS [z.B.
2141 2500 00ED 2618] und den gemessenen Werten.
5. Die Messung
Ich bin bezüglich der Messinstrumente ein Noob. Deshalb sieht es mir nach, wenn ich was falsches schreibe.
Der Anfang war nicht so leicht wie es schien. Den genauen Punkt getriggert zu bekommen war die Schwierigkeit. Dennoch haben wir positive Ergebnisse hinbekommen. Im Laufe der Messungen wurde der Tastkopf des Oszillators gegen eine kürzere Masse Verbindung getauscht. Durch die kleine Feder war das Signal deutlich sauberer und konnten unsere Testreihe sauber durchmessen. Hier ein Messbild als Beispiel.
Bei der Sichtung der einzelnen Messungen ist uns recht schnell aufgefallen, dass alle Messungen gleich waren! Egal welchen Multi und welche SIP Werte auch gesetzt hatten. Wir hatten immer das selbe Bild. Mehr dazu weiter unten.
6. Auswertung
Die "High" Werte des
connect Pins stellt immer eine 1 dar, ein "Low" dementsprechend eine 0. Ein Zahlenwert ist immer von peak to peak beim
K7CLKOut Pin. Somit müssen wir nur noch zuordnen und optisch ablesen:
Die SIP Zahlenfolge ist immer 33Bit lang. Der gemessene Wert ist hier:
1 0 0 001 001 00 000 1 0 1010 0 1 00 00 00 000 000
Jetzt brauchen wir die Definition der SIP Werte aus dem AMD Datenblatt:
Code:
Start bit [0]
ResetClkRatio [1]
BitTimePerSysClk [2]
SysAddRecMuxPreload [5:3]
SysDataMuxPreload [8:6]
SysResetClOffset [10:9]
SysAddClkDLy [13:11]
SysAddPage [14]
SysAddWide [15]
SysDCDelay [19:16]
DECSysComp [20]
SysPushPull [21]
SysAddDly [23:22]
SysDataOddDly [25:24]
SysDataEvenDly [27:26]
SysDataOddClkDly [30:28]
SysDataEvenClkDly [33:31]
[]= #Bits
Dann in rückwertigen Reihenfolge einsetzen.
Code:
SysDataEvenClkDly = 000
SysDataOddClkDly = 000
SysDataEvenDly = 00
SysDataOddDly = 00
SysAddDly = 00
SysPushPull = 1
DECSysComp = 0
SysDCDelay = 0101
SysAddWide = 0
SysAddPage = 1
SysAddClkDLy = 000
SysResetClOffset = 00
SysDataMuxPreload = 100
SysAddRecMuxPreload = 100
BitTimePerSysClk= 0
ResetClkRatio = 0
Die Werte scheinen plausibel zu sein.
PushPull muss bei allen Sockel A CPUs immer 1 sein. Aus dem
SysDCDelay Wert kann ich den Multiplikator auslesen. Der Wert 0101 entspricht der Zahl 5 und laut der AMD Tabelle entpricht das dem Multi 6! Halt! Wir hatten diesen Multi nicht bei unserer Messreie dabei! Wir hatten nur Multiplikatoren 7, 8 und 9 verwendet. Wie kann das sein? Warum der Multiplikator 6? Bei dem Postscreen sind bei der Messung immer der richtige Multiplikator angezeigt worden. Die Multis sind also immer richtig gesetzt worden. Die Messung sagt aber Multiplikator 6.
Nach dieser Sichtung haben wir das Messfeld erweitert und siehe da, im Verlauf des Startprozesses wird der SIP Prozess drei mal ausgefürt. Der dritte wird bei ca. 1 Sekunde nach dem ersten ausgefürt! Mangels Zeit konnten wir keine Weiteren Messungen machen.
7. Mein Fazit
Auch wenn die Messreihe nicht das wiedergegeben hat was wir messen wollten, kann man ein Fazit ziehen.
Der NF2 Chipsatz ist ja allgemein dafür bekannt, dass dieser keine Multiplikatoren im laufenden Betrieb mit einem Athlon XP-M Prozessor ändern kann. Dennoch wird beim Start zuerst der Startmulti (Bei allen XP-M CPUs = Multi 6) der XP-M CPU verwendet um danach den richtigen Multi zu setzen. Also rein technisch geht es scheinbar dann doch. Fragt sich nur wie.
Der zweite Punkt ist etwas komplexer. Warum wurde nicht die richtige SIP Tabelle geladen? Die überwiegende Mehrheit der NF2 Mainboards nutzen ein AWARD BIOS mit SIP Tabellen, die in dem kompromierten System Modul beheimatet sind. Diese Tabellen werden beim Betrieb auch 100%ig genutzt. Alle AWARD NF2 BIOSe haben darüber hinaus noch weitere SIP Tabellen, die im BOOT Block des BIOSes gesichert sind. Ich gehe nun davon aus, dass eine dieser Tabellen beim System Start geladen werden um dann auf die anderen Tabellen im System Modul zu wechseln. Das zu prüfen könnte das nächste Ziel sein.
Ich möchte hier mich auch herzlich für diese Messungen beim
@P4schissel bedanken! Es hat Spaß gemacht!
valid.x86.fr
