Reverse Engineering, BIOS-Patch programmieren

Diskussion zum Thema Programmierung unter DOS (Intel x86)
Antworten
Lotosdrache
LAN Manager
Beiträge: 224
Registriert: Sa 9. Jan 2016, 23:25

Reverse Engineering, BIOS-Patch programmieren

Beitrag von Lotosdrache »

Disruptor hat geschrieben:Bei dem Board hat ein Kumpel von mir das BIOS so gepatcht, dass der IDE-Controller nun die volle Leistung im UDMA-Modus bringt; falls Interesse besteht...
Beschäftige mich zur Zeit auch mit dem Patchen des BIOSes meines Gigabyte GA-5AX:
https://www.voodooalert.de/board/forum/ ... post460262
https://www.voodooalert.de/board/forum/ ... post463804

Und anderen Dingen, die man mit Reverse Engineering lösen kann:
https://www.voodooalert.de/board/forum/ ... post462322

Dem RAM-Controller meines DFI K6XV3+/66 will ich später auch noch mittels eines BIOS-Patches à la Pinczakko Beine machen und ihm das Bank Interleave beibringen. 8-)

Allerdings bin ich noch bei der Northbridge. Der IDE-Controller steckt ja üblicherweise in der Southbridge. Von daher habe ich schon Interesse daran, allerdings weniger an dem BIOS selbst, sondern eher daran, wie man es macht, also wie man die Southbridge adressiert, konfiguriert und das ganze dann im BIOS ausführt. Letzteres, also die Ausführung im BIOS, funktioniert vermutlich ähnlich wie bei meinem Patch für die Northbridge.

Auslesen des CPU-Typs, Adressierung und Konfiguration der CPU-Register würden mich auch noch interessieren. Gerade auf dem Super Sockel 7 gibt's da ja viel nachträglichen Optimierungsbedarf. Letztlich träume ich davon, einen Patch im BIOS zu haben, der alles, wofür ich im Moment zig unterschiedliche Konfigurationstools brauche, automatisch erledigt:
- CPU-Typ auslesen (IBM/Cyrix/ST 6x86L/6x86MX/MII; AMD K5/K6/K6-2/K6-III/K6-2+/K6-III+; Intel Pentium/Pemtium-MMX/Pentium-S; Rise mP6/iDragon/mP6-II; IDT Winchip C6/2/2A/2B/3)
- RAM-Kapazität ermitteln
dann je nach CPU-Typ:
- Write Allocation einstellen
- Extended Write Merge Buffer (Write Order) einstellen
- Linear Frame Buffer der Grafikkarte ermitteln
- MTRRs konfigurieren
- Write Combining einstellen
Ob das alles so möglich ist, weiß ich nicht. Wenn's aber manuell machbar ist, sollte es doch auch automatisiert möglich sein, oder?
Zuletzt geändert von Lotosdrache am Fr 5. Jun 2020, 12:19, insgesamt 1-mal geändert.
Ich werde mich von keinem einzzzigen Prozzzessor trennen.
Jedoch lockt es mich beinahe, ihn Dir zu überlassen, nur um zu sehen, wie er Dich in den Wahnsinn treibt :twisted:

Meine Begehren
Disruptor
Norton Commander
Beiträge: 124
Registriert: Do 2. Nov 2017, 12:59

Re: Reverse Engineering, BIOS-Patch programmieren

Beitrag von Disruptor »

Einstellen und im BIOS konfigurierbar machen sind zwei unterschiedliche Dinge.
Ich frag ihn mal, ob er was dazu schreibt.
Lotosdrache
LAN Manager
Beiträge: 224
Registriert: Sa 9. Jan 2016, 23:25

Re: Reverse Engineering, BIOS-Patch programmieren

Beitrag von Lotosdrache »

Das ist schon klar. Im BIOS-Setup konfigurierbar machen will ich es auch gar nicht.
Mein Patch für den internen Tag RAM und ein paar andere Funktionen der Aladdin V-Northbridge ist natürlich auch nicht im Setup konfigurierbar. Der wird schlicht immer ausgeführt, d. h. die Einstellungen der Northbridge werden immer umprogrammiert. So stelle ich mir das dann auch für die Konfiguration von CPUs und Southbridge vor.
Tools wie modbin und amibcp kenne ich natürlich. Die helfen aber bei der Konfiguration der CPU nicht viel weiter, da die notwendigen Einstellungsmöglichkeiten im Setup schlicht nicht da sind, nicht einmal versteckt. :roll: Daher die Automatisierung mittels BIOS-Patch.

Würde mich sehr über Hilfestellung und Hinweise freuen :-)

P.S. Als Beispiel: So sieht mein Patch für die Aladdin V-Northbridge meines GA-5AX im Moment aus:

Code: Alles auswählen

; ---------------------- file: PatchAll.asm -------------------------
use16

start:

    pushf
    cli

    mov cx, 0x41
    call Read_PCI_Bus0_Byte
    or al, 0x1                  ; disable external TAG RAM. Kann auch aktiviert bleiben, bringt aber keine Vorteile. Max. cachebarer RAM bleibt bei 512 MiB (getestet mit 1 GiB RAM).
    mov cx, 0x41
    call Write_PCI_Bus0_Byte

    mov cx, 0x40
    call Read_PCI_Bus0_Byte
    or al, 0x40                 ; enable internal TAG RAM
    mov cx, 0x40
    call Write_PCI_Bus0_Byte

    mov cx, 0x48
    call Read_PCI_Bus0_Byte
    or al, 0x1                  ; Trc=7T and Tras=4T
    mov cx, 0x48
    call Write_PCI_Bus0_Byte

    mov cx, 0x49
    call Read_PCI_Bus0_Byte
    or al, 0x2                  ; enable SDRAM Internal Page Detection
    mov cx, 0x49
    call Write_PCI_Bus0_Byte

    mov cx, 0x49
    call Read_PCI_Bus0_Byte
    or al, 0x8                  ; enable SDRAM Enhanced Page Mode
    mov cx, 0x49
    call Write_PCI_Bus0_Byte

    popf

    clc             ; Indicate that this POST routine was successful
    retn            ; Return near next POST entry

    pushf
    cli

    mov cx, 0x86
    call Read_PCI_Bus0_Byte
    and al, 0xF7                ; disable LINEAR_WORD-Merge for Frame Buffer Cycle
    mov cx, 0x86
    call Write_PCI_Bus0_Byte

    popf

    clc             ; Indicate that this POST routine was successful
    retn            ; Return near next POST entry

    pushf
    cli

    mov cx, 0x43
    call Read_PCI_Bus0_Byte
    or al, 0x2                  ; enable Fast NAJ asserted in single write cycle
    mov cx, 0x43
    call Write_PCI_Bus0_Byte

    mov cx, 0x48
    call Read_PCI_Bus0_Byte
    or al, 0x8                  ; tRP=2T
    mov cx, 0x48
    call Write_PCI_Bus0_Byte

    mov cx, 0xC9
    call Read_PCI_Bus0_Byte
    or al, 0x40                ; AGP Control Register II: Output delay control of AD_STB[1:0] : Default-1nsec=2,5nsec
    mov cx, 0xC9
    call Write_PCI_Bus0_Byte

    popf

    clc             ; Indicate that this POST routine was successful
    retn            ; Return near next POST entry

; -- Read_PCI_Byte__ --
; in: cx = dev_func_offset_addr
; out: al = reg_value

Read_PCI_Bus0_Byte:
    mov ax, 8000h
    shl eax, 10h
    mov ax, cx
    and al, 0FCh
    mov dx, 0CF8h
    out dx, eax
    mov dl, 0FCh
    mov al, cl
    and al, 3
    add dl, al
    in  al, dx
    retn
    
; -- Write_Bus0_Byte --
; in: cx = dev_func_offset addr
;     al = reg_value to write

Write_PCI_Bus0_Byte:
    xchg ax, cx
    shl ecx, 10h
    xchg ax, cx
    mov ax, 8000h
    shl eax, 10h
    mov ax, cx
    and al, 0FCh
    mov dx, 0CF8h
    out dx, eax
    add dl, 4
    or dl, cl
    mov eax, ecx
    shr eax, 10h
    out dx, al
    retn
; --------------------- file: PatchAll.asm --------------------------
Ausgeführt wird er zu drei unterschiedlichen Zeitpunkten während des POSTs.
Read_PCI_Bus0_Byte und Write_PCI_Bus0_Byte sind die Prozeduren zur Adressierung der Northbridge und praktisch auf (fast) jede Northbridge anwendbar, die am PCI-Bus hängt. Sie sind etwas kryptisch und haben ein paar seltsame Befehle drinnen, die sich aus der PCI-Spezifikation ergeben (näheres dazu siehe: https://github.com/pinczakko/BIOS-Disas ... -Uncovered)
Mich interessiert nun vor allem, wie die Prozeduren zur Ansteuerung von CPU und Southbridge aussehen.
Ich werde mich von keinem einzzzigen Prozzzessor trennen.
Jedoch lockt es mich beinahe, ihn Dir zu überlassen, nur um zu sehen, wie er Dich in den Wahnsinn treibt :twisted:

Meine Begehren
S+M
DOS-Übermensch
Beiträge: 1059
Registriert: Mo 10. Jun 2013, 17:04
Wohnort: BW

Re: Reverse Engineering, BIOS-Patch programmieren

Beitrag von S+M »

Es gibt einen Bios-Patcher, der es alles automatisiert für einen erledigt. Zum Verständnis was da genau gemacht wird trägt es aber nicht unbedingt bei :-|

Siehe hier: http://www.rom.by/articles/BP/index_english.htm

PS: Beeindruckend :like:
Lotosdrache
LAN Manager
Beiträge: 224
Registriert: Sa 9. Jan 2016, 23:25

Re: Reverse Engineering, BIOS-Patch programmieren

Beitrag von Lotosdrache »

soggi von voodooalert.de hat mir das BIOS vorher mit der Version 6 davon behandelt:
##################################
# Gigabyte GA-5AX soggi BIOS 1.0 #
##################################

Bios Issue Date: 2018/07/12

Features:
---------

1. Fixed CPU support.
2. Fixed HDD detection.


Known Bugs:
-----------

-

BIOS Patcher 6.00.alpha_15 report:
----------------------------------

BIOS Patcher ver. 6.00.alpha_15. |for Award/Phoenix & AMI bioses|
Attention! Advanced qualification is required!

Found 1Mbit Award BIOS!
Attention! - found Gigabyte-BIOS!

1. New CPU Support : -> fixed.
2. P3-detect error : is not needed to be fixed.
3. New Koeffs Support : -> fixed.
4. 32Gb-problem : not found.
5. Some HDD detect-problem : -> fixed.
6. "MB"/"GB" string search : is not needed to be fixed.
9. Error display Freq>999MHz : is not needed to be fixed.
10.Error display Koefs>9.5x : not found.
11.New Stepping Support : is not needed to be fixed.
12.Tualatin L2-init error : not found.
13.New Freq in Setup open : not found.

14.Set "Y" as default on exit: -> fixed.

Write Allocate addinng: not found.
UDMA66/100/133 on UDMA33_only_MB patch: not found.

Tweak options addinng:

Not free space in BIOS!
error!

if you can`t see all messages - choose 80x50 mode or run with ">report.txt".
(c)2002-2004 apple_rom, http://www.ROM.by
(c)2006 Angel07, http://www.cgi-scripts.info
Leider hat das meine Probleme/Wünsche nicht gelöst. Die sind, besser waren, so speziell :roll: , daß sie auch gar nicht im readme des BIOS Patchers auftauchen.

Danke für die Blumen :-)
Ich werde mich von keinem einzzzigen Prozzzessor trennen.
Jedoch lockt es mich beinahe, ihn Dir zu überlassen, nur um zu sehen, wie er Dich in den Wahnsinn treibt :twisted:

Meine Begehren
mkarcher
LAN Manager
Beiträge: 204
Registriert: Fr 5. Jun 2020, 19:38

Re: Reverse Engineering, BIOS-Patch programmieren

Beitrag von mkarcher »

Lotosdrache hat geschrieben:
Disruptor hat geschrieben:Bei dem Board hat ein Kumpel von mir das BIOS so gepatcht, dass der IDE-Controller nun die volle Leistung im UDMA-Modus bringt; falls Interesse besteht...
Allerdings bin ich noch bei der Northbridge. Der IDE-Controller steckt ja üblicherweise in der Southbridge. Von daher habe ich schon Interesse daran, allerdings weniger an dem BIOS selbst, sondern eher daran, wie man es macht, also wie man die Southbridge adressiert, konfiguriert und das ganze dann im BIOS ausführt.
Ich bin derjenige Kumpel. Im Fall mit der IDE-Tabelle bin ich gar nicht bis in den Code eingedrungen. Es gibt im BIOS eine Chipsatz-Initisalisierungs-Tabelle. In dieser Tabelle ist die Nummer eines Chipsatz-Registers, eine Bitmaske, welche Bits initialisiert werden sollen und die neuen Bits enthalten. In alten BIOSen aus der 286/386/486(VL)-Zeit, war die Nummer des Chipsatz-Registers häufig ein 8-Bit-Wert, der für das Index-Register im "System Controller" verwendet wurde, mit PCI-Boards ist des jetzt häufig (und so auch beim K6XV3+/66) direkt ein 16-Bit-PCI-Adresse auf Bus 0. Das bedeutet, dass in den unteren 8 Bit der Offset im 256-Byte-Configuration-Space steht, und in den oberen 8 Bit "device number" und "function number" kodiert sind. Die function number kann 0 bis 7 sein, und ist in den unteren drei Bit, die device number kann 0 bis 31 sein, und ist in den oberen 5 Bit. Zusammen ist der 16-Bit-Wert in dieser Tabelle direkt das, was in die unteren 16 Bit des Port CF8 geschrieben werden muss, um auf das Konfigurationsregister zuzugreifen.

Auf dem K6VX3+ hat die Northbridge die device id 0 (das ist IIRC fest verdrahtet in der Northbridge), und die Southbridge hängt auf device id 7. Da unter die device id noch 3 bits für die function id kommen, beginnt die Southbridge also mit 38h im oberen byte. Der IDE-Controller liegt auf function id 1, also liegt er bei 39h.

Das schöne an der Tabelle ist, dass sich die Tabelle in Teilen mit modbin bearbeiten lässt: Die Registeradressen und die Maske ist in modbin nicht bearbeitbar, aber der Wert. Um dem IDE-Controller Beine zu machen, muss man im Konfigurationsregister 44h des IDE-Controllers (des VT82C596B) die Bits 5 und 6 löschen (sie sorgen für je 1WS bei Busmaster-Read und Busmaster-Write-Zugriffen), und in Register 45 des IDE-Controllers die Bits 2 und 3 setzen (sie schalten (bessere) Read Bursts und Write Bursts ein, genauer gesagt geht es um die PCI-Transaktionstypen "Memory Read Multiple" und "Memory Write and Invalidate", die dann auch Cacheline-übergreifend arbeiten). Die Bezeichnung "Memory Read and Invalidate" in meiner Ausgabe des VT82C596B-Datenblatts ist ein Druckfehler - einen solchen Transaktionstyp gibt es nicht).

Wenn man das aktuelle BIOS des K6XV3+/66 mit modbin öffnet, erscheint auf der Seite "Chipset Regs Default" unter anderem ein Eintrag für Register 3944 (und zwar "01101000"), der die beiden Waitstate-Bits setzt. Dieser kann einfach auf "00001000" geändert werden, und die Waitstates sind aus. Das Register 3945 wird in dieser Liste aber nicht aufgeführt, weil es im BIOS in der Initialisierungsliste nicht enthalten ist. Ich habe daher (mittel AWDHACK - ein Tools, was in den richtigen Umständen das tut, was es soll, aber von mir keine Empfehlung erhält) im BIOS-Code (also "original.tmp") nach dieser Tabelle gesucht, und einen "unnötigen" Eintrag umgebogen, so dass er das Register 3945 enthält. Als unnötigen Eintrag habe ich den Eintrag für 3946 identifiziert, da der Wert "11000000" dort genau den dokumentierten Power-On-Defaults entspricht. Dieser Tabelleneintrag ist also nur für einen Warmstart relevant, wenn das Betriebssystem das Register verstellt haben sollte (wofür es aber eigentlich keinen Grund gibt). Dann habe ich im BIOS einfach die 46 durch eine 45 ersetzt, und danach lässt dann mit modbin auch ein Wert für Register 3945 eintragen.

Nebenbei bin ich noch über das Problem gestolpert, dass die von mir verwendete modbin-Version (das müsste die 4.50.80C gewesen sein) offenbar nicht mit dem BIOS kompatibel ist, und eine Prüfsumme nicht neu berechnet. Das aktuelle BIOS des K6XV3+ prüft über die ersten 224KiB-1, also von Dateioffset 0 bis 37FFEh, und die Summe muss durch 256 teilbar sein. Es wirkt so, als ob das Byte an Adresse 37FFEh dazu angepasst wird. Dieses Byte liegt im Bereich des LHA-Dekompressors, der von 37000h bis 37FFFh geht, und ebenfalls eine 8-Bit-Prüfsumme mit dem Wert 0 haben muss. Dazu scheint im Original-BIOS das Byte 37FFF angepasst worden zu sein. Ich habe (nachdem ich zunächst im Recovery Mode gelandet war) diese beiden Bytes per Hand angepasst und neu geflasht, und damit das Ergebnis erzielt, was Disruptor oben erwähnt hat.
S+M
DOS-Übermensch
Beiträge: 1059
Registriert: Mo 10. Jun 2013, 17:04
Wohnort: BW

Re: Reverse Engineering, BIOS-Patch programmieren

Beitrag von S+M »

mkarcher hat geschrieben:[...]genauer gesagt geht es um die PCI-Transaktionstypen "Memory Read Multiple" und "Memory Write and Invalidate", die dann auch Cacheline-übergreifend arbeiten).
Hilft das allgemein die PCI-Performance zu erhöhen?
Gibt's dazu Messungen?
mkarcher
LAN Manager
Beiträge: 204
Registriert: Fr 5. Jun 2020, 19:38

Re: Reverse Engineering, BIOS-Patch programmieren

Beitrag von mkarcher »

Lotosdrache hat geschrieben: Auslesen des CPU-Typs, Adressierung und Konfiguration der CPU-Register würden mich auch noch interessieren. Gerade auf dem Super Sockel 7 gibt's da ja viel nachträglichen Optimierungsbedarf. Letztlich träume ich davon, einen Patch im BIOS zu haben, der alles, wofür ich im Moment zig unterschiedliche Konfigurationstools brauche, automatisch erledigt:
- CPU-Typ auslesen (IBM/Cyrix/ST 6x86L/6x86MX/MII; AMD K5/K6/K6-2/K6-III/K6-2+/K6-III+; Intel Pentium/Pemtium-MMX/Pentium-S; Rise mP6/iDragon/mP6-II; IDT Winchip C6/2/2A/2B/3)
- RAM-Kapazität ermitteln
dann je nach CPU-Typ:
- Write Allocation einstellen
- Extended Write Merge Buffer (Write Order) einstellen
- Linear Frame Buffer der Grafikkarte ermitteln
- MTRRs konfigurieren
- Write Combining einstellen
Ob das alles so möglich ist, weiß ich nicht. Wenn's aber manuell machbar ist, sollte es doch auch automatisiert möglich sein, oder?
Natürlich ist das alles automatisiert möglich. Das BIOS tut ja auch schon einiges davon automatisch.

Leider haben nicht alle Prozessoren (in allen Konfigurationen) den CPUID-Befehl, so dass das BIOS die uralte Methode mitverwenden muss, dass der Prozessor das DX-Register nach dem Reset mit CPU-ID-Informationen initialisiert. Um diese Daten über den POST aufzubewahren, nutzt das Award-BIOS dazu die Bytes 3Dh (vollständig) und 3Fh (nur Bits 3-7) im CMOS. Das unterste Bit in 3D steht für das Vorhandensein eines Koprozessors, und die nächsten 6 Bit stellen eine Nummer des Prozessortyps dar. Zu 486-Zeiten war das noch sehr informativ, aber auf dem K6XV3+/66-Board steht zum Beispiel Typ 13 für "Pentium-artige CPU" (inklusive Rise, IDT), 26 für 6x86-Varianten, 32 für den 6x86MX, 42 für K5 und 43 für den MediaGX. Wo der K6 eingeordnet wird, ist gerade nicht offensichtlich, aber vermutlich auch unter 13. Wenn während des POSTs mehr Details benötigt werden, wird das just-in-time erkannt (über CPUID oder Cyrix-ID-Register).

RAM-Kapazität will man möglichst nicht selbst erkennen, sondern sich auf die Erkennung des BIOS verlassen. Das sollte über eine BIOS-Schnittstelle abfragen. Bei dem ACPI-fähigen K6XV3+/66-Board steht ab POST-Code 3D die Speicherbelegung über Int15/E820 zur Verfügung. Int15/E801 ist dort nicht implementiert, und Int15/88 ist doof, weil es maximal 64MB melden kann. Hier musst Du für ältere Boards und neuere Boards also verschiedenen Code verwenden, oder prüfen, ob E820 funktioniert hat.

Den LFB bekommt man "recht einfach" heraus, indem man in der Grafikkarte (Oops, das könnten auch mehrere sein, und dann wirds lustig) nach eine PCI-Speicher-Resource vom Type "prefetchable" sucht. Das klappt erst ab dem Zeitpunkt, wo das BIOS die PCI-Adressen zugewiesen hat. Das ist kein Problem auf dem K6XV3+/66-BIOS, denn die Resourcenzuweisung findet sehr früh im POST statt, nämlich bei POST-Code 0B

Spät in der Bootfolge sollte also folgendes gehen
  • Cyrix-CPU erkennen (typischerweise über Flags beim Dividieren), wenn Cyrix, dann ID-Register lesen
  • Sonst auf CPU-ID-fähigkeit prüfen, und CPU mittels CPUID erkennen
  • Wenn weder Cyrix noch CPUID, abbrechen
  • Adresse der Grafikkarte auf dem PCI-Bus heraussuchen
  • Prozessor-Register passend initialisieren.
mkarcher
LAN Manager
Beiträge: 204
Registriert: Fr 5. Jun 2020, 19:38

Re: Reverse Engineering, BIOS-Patch programmieren

Beitrag von mkarcher »

S+M hat geschrieben:
mkarcher hat geschrieben:[...]genauer gesagt geht es um die PCI-Transaktionstypen "Memory Read Multiple" und "Memory Write and Invalidate", die dann auch Cacheline-übergreifend arbeiten).
Hilft das allgemein die PCI-Performance zu erhöhen?
Gibt's dazu Messungen?
Es handelt sich an der Stelle um die Konfiguration des IDE-Chips, und zwar darum, welche PCI-Zugriffstypen er im (Ultra-)DMA-Modus zum Busmastering verwendet. Es hilft daher ausschließlich bei IDE-Zugriffen, die per DMA abgewickelt werden, also unter allen modernen Betriebssystemen, sowei unter DOS mit UDMA.SYS oder ähnlichem. Mit einer Platte, die offenbar besonders empfindlich ist (möglicherweise, weil sie UDMA66 in kleinen Happen macht) habe ich eine Verbesserung von ich glaube um 15MB/s Coretest-Wert auf etwa 45MB/s Coretest-Wert erhalten.

Gruß,
Michael
Lotosdrache
LAN Manager
Beiträge: 224
Registriert: Sa 9. Jan 2016, 23:25

Re: Reverse Engineering, BIOS-Patch programmieren

Beitrag von Lotosdrache »

Vielen Dank, daß Du was dazu geschrieben hast! :like:
mkarcher hat geschrieben:Auf dem K6VX3+ hat die Northbridge die device id 0 (das ist IIRC fest verdrahtet in der Northbridge), und die Southbridge hängt auf device id 7. Da unter die device id noch 3 bits für die function id kommen, beginnt die Southbridge also mit 38h im oberen byte. Der IDE-Controller liegt auf function id 1, also liegt er bei 39h.
Die Northbridge eines PCI-Systems hat wohl immer die Geräte-ID 0 (mag Ausnahmen geben). Die ID der Southbridge kannte ich noch nicht, insofern hilft mir das schon mal weiter, diese Werte des Gigabyte GA-5AX zu verstehen:
Chipset_Registers_Default_page1.png
Chipset_Registers_Default_page1.png (15.37 KiB) 8863 mal betrachtet
Chipset_Registers_Default_page2.png
Chipset_Registers_Default_page2.png (15.67 KiB) 8863 mal betrachtet
Auto_Table_83MHz.png
Auto_Table_83MHz.png (12.11 KiB) 8863 mal betrachtet
Auto_Table_100MHz.png
Auto_Table_100MHz.png (12.12 KiB) 8863 mal betrachtet
Ich nehme mal an, daß 38h auch hier für die Southbridge steht. Für welche Geräte könnten dann die IDs 18h (0001.1000), 78h (0111.1000) und 08h (0000.1000) stehen? Im Index 0887 steht Bit 5 nämlich nur bei 83 MHz auf 1, sonst immer auf 0.
mkarcher hat geschrieben:Wenn man das aktuelle BIOS des K6XV3+/66 mit modbin öffnet, erscheint auf der Seite "Chipset Regs Default" unter anderem ein Eintrag für Register 3944 (und zwar "01101000"), der die beiden Waitstate-Bits setzt. Dieser kann einfach auf "00001000" geändert werden, und die Waitstates sind aus. Das Register 3945 wird in dieser Liste aber nicht aufgeführt, weil es im BIOS in der Initialisierungsliste nicht enthalten ist. Ich habe daher (mittel AWDHACK - ein Tools, was in den richtigen Umständen das tut, was es soll, aber von mir keine Empfehlung erhält) im BIOS-Code (also "original.tmp") nach dieser Tabelle gesucht, und einen "unnötigen" Eintrag umgebogen, so dass er das Register 3945 enthält. Als unnötigen Eintrag habe ich den Eintrag für 3946 identifiziert, da der Wert "11000000" dort genau den dokumentierten Power-On-Defaults entspricht. Dieser Tabelleneintrag ist also nur für einen Warmstart relevant, wenn das Betriebssystem das Register verstellt haben sollte (wofür es aber eigentlich keinen Grund gibt). Dann habe ich im BIOS einfach die 46 durch eine 45 ersetzt, und danach lässt dann mit modbin auch ein Wert für Register 3945 eintragen.
Auf den Seiten "Chipset Regs Default" habe ich auch schon einige Einträge mittels modbin geändert. AWDHACK kannte ich bisher noch nicht und so wie Du das schreibst, scheint es auch nicht ohne Risiko zu sein. Ab der Änderung des Herstellercodes mittels AWDHACK für nicht vorhandene Einträge unterscheidet sich daher meine Vorgehensweise nach der Methode, wie sie Darmawan M S a.k.a Pinczakko beschreibt, auch grundsätzlich. Statt den Herstellercode zu ändern, habe ich eine eigenständige Konfigurationsroutine für die Northbridge im BIOS ausgeführt. Solange der Hersteller die entsprechenden Offsets nicht selbst konfiguriert, funktioniert der Aufruf an einer beliebigen Stelle zwischen den Prozeduren des Herstellers. Bei vier Einstellungen mußte ich die Ausführung allerdings solange zum Ende des POSTs hin verschieben, bis ich nicht mehr von der Programmierung durch Gigabyte überschrieben wurde.
Nettes Nebenprodukt dieser Vorgehensweise: Sucht man einen bestimmten Programmcode, läßt sich dessen Position im BIOS auf diese Weise theoretisch leicht eingrenzen und man muß nicht mehr den ganzen Code durchwühlen. :geek:

Die Sachen zur CPU-Konfiguration lesen sich ziemlich kompliziert. Da muß ich noch ne Weile drüber nachdenken. ;-)
Trotzdem schon mal Vielen Dank auch dafür! :like:
Ich werde mich von keinem einzzzigen Prozzzessor trennen.
Jedoch lockt es mich beinahe, ihn Dir zu überlassen, nur um zu sehen, wie er Dich in den Wahnsinn treibt :twisted:

Meine Begehren
mkarcher
LAN Manager
Beiträge: 204
Registriert: Fr 5. Jun 2020, 19:38

Re: Reverse Engineering, BIOS-Patch programmieren

Beitrag von mkarcher »

Lotosdrache hat geschrieben:Vielen Dank, daß Du was dazu geschrieben hast! :like:
mkarcher hat geschrieben:Auf dem K6VX3+ hat die Northbridge die device id 0 (das ist IIRC fest verdrahtet in der Northbridge), und die Southbridge hängt auf device id 7. Da unter die device id noch 3 bits für die function id kommen, beginnt die Southbridge also mit 38h im oberen byte. Der IDE-Controller liegt auf function id 1, also liegt er bei 39h.
Die Northbridge eines PCI-Systems hat wohl immer die Geräte-ID 0 (mag Ausnahmen geben). Die ID der Southbridge kannte ich noch nicht, insofern hilft mir das schon mal weiter, diese Werte des Gigabyte GA-5AX zu verstehen:

Ich nehme mal an, daß 38h auch hier für die Southbridge steht. Für welche Geräte könnten dann die IDs 18h (0001.1000), 78h (0111.1000) und 08h (0000.1000) stehen? Im Index 0887 steht Bit 5 nämlich nur bei 83 MHz auf 1, sonst immer auf 0.
Es gibt für alle Betriebssysteme Tools, die einem die Liste der PCI-Geräte mit den Device-IDs anzeigen. Da die Low-Level-Bastler-Community Ende der 90er unter Linux deutlich stärker im Internet vertreten war als unter DOS, findet man für viele Boards den Output des Linux-Tools "lspci" problemlos per Google, indem man einfach den Board-Namen und lspci, am besten jeweils in Anführungszeichen, in Google eingibt. Für das GA-5AX habe ich damit auf die Schnelle folgenden http://t2sde.org/hardware/board/Gigabyte/GA-5AX/ gefunden. Daraus ergibt sich folgende Zuweisung für die Onboard-Komponenten:
Internetquelle auf t2sde.org hat geschrieben:

Code: Alles auswählen

0.0 (00h) = FSB-to-PCI (Ein Teil der Northbridge)
1.0 (08h) = FSB-to-AGP (auch Teil der Northbridge)
2.0 (10h) = USB-Controller
7.0 (38h) = ISA-Bridge
F.0 (78h) = IDE-Controller
Lotosdrache hat geschrieben: Auf den Seiten "Chipset Regs Default" habe ich auch schon einige Einträge mittels modbin geändert. AWDHACK kannte ich bisher noch nicht und so wie Du das schreibst, scheint es auch nicht ohne Risiko zu sein. Ab der Änderung des Herstellercodes mittels AWDHACK für nicht vorhandene Einträge unterscheidet sich daher meine Vorgehensweise nach der Methode, wie sie Darmawan M S a.k.a Pinczakko beschreibt, auch grundsätzlich. Statt den Herstellercode zu ändern, habe ich eine eigenständige Konfigurationsroutine für die Northbridge im BIOS ausgeführt.
Die Probleme, die ich beschrieben haben, kommen nicht primär von AWDHACK, sondern von MODBIN selbst. AWDHACK berechnet keine Prüfsummen, sondern modifiziert die ORIGINAL.TMP im Hintergrund im richtigen Moment, während MODBIN das BIOS zusammenpackt. Ich habe sogar das BIOS nach der Anwendung von AWDHACK (wo ich die Registernummer geändert habe) noch einmal mit MODBIN ohne AWDHACK im Hintergrund geöffnet, um den neuen Wert für das Register auf vorgesehene Art über die UI einzufügen. Die Probleme mit AWDHACK lassen sich eigentlich auf zwei Punkte zusammenfassen. Diese Liste ist vor allem für andere Leser dieses Threads. Wenn Du bereits einen funktionierenden Workflow hast, um das Laufzeit-BIOS zu patchen, bleib' einfach dabei!
  1. Es funktioniert dadurch, dass es bestimmte Zustände von MODBIN anhand von DOS-Funktionsaufrufen erkennt. Dabei geht etwas durcheinander, welche Werte wirklich von MODBIN kommen, und welche eigentlich aus dem DOS stammen. So wie ich das sehe, funktioniert AWDHACK nur mit bestimmten DOS-Versionen aus der Win-9x-Reihe wie vom Autor vorgesehen.
  2. Da AWDHACK beim Abspeichern des modifizierten BIOS durch MODBIN den Hex-Editor HIEW aufmacht, müssen MODBIN, HIEW und AWDHACK gleichzeitig in den konventionellen Arbeitsspeicher passen. AWDHACK selbst gibt sich zwar ausreichend viel Mühe, selber klein zu sein, aber auch HIEW ist in späteren Versionen immer größer geworden, genauso wie MODBIN. Man sollte also eine ältere Version von HIEW greifbar haben, und auch bei MODBIN sich auf die empfohlenen Versionen auf der AWDHACK-Seite beschränken, wenn man mit dem Tool arbeiten will.
Was ich bei meiner Vorgehensweise bevorzuge, ist der minimalistische Eingriff. Und ich lege Wert darauf (wobei Du das sicher nicht so genau gemeint hast), dass ich eben gerade nicht *Code* vom Hersteller anfassen muss, sondern es reicht, den Inhalt von *Tabellen*, also Daten zu ändern. Dadurch sinkt zwar die Flexibilität, aber gleichzeitig auch das Risiko, etwas dummes falsch zu machen. Und ich brauche nicht selbst die Funktionen zum Lesen und Schreiben von PCI-Registern zu finden. Das Patchen des BIOS von Pinczakko ist natürlich die flexiblere und mächtigere Methode, so dass jeder je nach Bedürfnissen entscheiden kann, was besser passt. Das größte Problem an meiner Tabellen-Variante ist, dass die Tabelle nicht mal eben mit einer CALL- oder JMP-Instruktion in einen ungenutzten Bereich des BIOS vergrößert werden kann, und man daher auf die Größe der Tabelle beschränkt ist, die der Hersteller vorgegeben hat. Die Idee war ja mal (zu 386-Zeiten), dass der Chipsatzhersteller hier eine Tabelle zuliefert, in der *alle* konfigurierbaren Register drin sind, die nicht über Setup-Optionen konfiguriert werden können, und daher eine Vergrößerung der Tabelle gar nicht nötig ist...
Lotosdrache hat geschrieben: Die Sachen zur CPU-Konfiguration lesen sich ziemlich kompliziert. Da muß ich noch ne Weile drüber nachdenken. ;-)
Trotzdem schon mal Vielen Dank auch dafür! :like:
Viel Spaß! 8-)
Antworten