Frei nach netkas, MacRumors, Dosdude & Co.: PC-GraKa für Mac Pro flashen

Hab mir das DosDude Video angesehen.

Was macht er mit den PC Rom ?

Was Dosdude im Video macht ist die FFs ganz am Ende des Roms vor den zweiten MCuC zu schieben. Dabei bleibt die Länge gleich. Der MCuC Offset muss dann noch geändert werden.

Danach lässt er die DD Kommandos im Terminal nochmal laufen um den EFi Part einzukopieren und prüft nochmals ob zwei MCuCs drin sind.

Dann kommt das python Script drüber.



Er benutzt die Script Methode und weil das nicht passte hat er den Bereich vor dem zweiten MCuC um die FFs vom Ende erweitert und den Zeiger korrigiert.

Danach funktionierte das Script.


...muss später mal schauen, müsste noch ein, zwei GPUs haben die sich nicht flashen liessen, mit neuem Wissen kann man einen zweiten Anlauf wagen :)


Edit: Genau so wie im Netkas Thread beschrieben, ich hab da was missverstanden :-/
 
Zuletzt bearbeitet:
Zum Glück hat der Pointer drei Bytes und zeigt die Position direkt an und nicht als Multiplikator. Es könnte trotzdem vorkommen, dass man dadurch nicht genug Platz hinterm VBIOS bekommt - das Script würde dann wieder was überschreiben.
 
Das habe ich getestet, auch mit manuell freigeräumtem FFs gibt es nach Ausführung des Scripts wieder nur ein MCuC bei Lucky's GPU.
 
Wenn ich das richtig verstanden habe gibt das dritte Byte des Roms * 512 die Startadresse des EFI Bereichs an.

Ab dieser Startadresse steht der Platz zur Verfügung der mit FFs ausgefüllt ist.

Das ist $7E, also $7E*512 = $FC00

wenn ich das Rom von $FC00 bis zum Ende der $FFs zähle kommt $A400 raus, das ist 40671. Der EFI Teil ist aber 43008 Bytes lang.

Somit passt das nicht.

Am Ende des Roms sind auch nur 863 $FFs, somit hilft das umherschieben dieses Bereichs auch nicht. (40671+863<<43008)

Vor der Startadresse $FC00 wäre auch nur 1 Block á 512 Bytes frei. Auch das genügt nicht. 512 Bytes weil das 3. Byte * 512 dieses vorgibt.

Wie quetscht man nun den Efi Part mit 43008 Bytes in den EFI Bereich ??
 
Ich glaub ich hab's jetzt (hat auch lange genug gedauert)

- Beginnend mit $55 AA (Länge*$200) ist der erste Teil (PC Bios)
- dann zum Offset der durch die Länge bestimmt wird springen
- Overwrite Mode bei 0xed (alles was im Rom drin ist ignorieren)
- Efi Part einsetzen, beginnt auf mit $55 AA (Länge*$200).
- Offsets der MCuC beachten, ggf korrigieren

- dann fixrom.py drüber laufen lassen

eigentlich einfacher wie gedacht
 
  • Gefällt mir
Reaktionen: rembremerdinger, Proinnsias und LuckyOldMan
Macschrauber schrieb:
Ich glaub ich hab's jetzt (hat auch lange genug gedauert)
Zum Vergrößern anklicken....
Respekt, mein Lieber - das muss man Dir lassen: Du bleibst dran und läßt es nicht ruhen. ;)
Hast Du denn jetzt das 5870pc.rom erfolgreich zur 5870mac.rom mit zwei verbliebenen MCUCs umgestrickt?

Ich hatte mir ähnliche Gedanken (nur deutlich weniger wissenschaftlich) auch für's Frühstück aufgehoben. Von der Handhabung her könnte ich das oben nicht umsetzen, weil mir der Umgang mit HEXen fehlt, aber gedanklich durchaus nachvollziehen (das HEX-Rechnen vor 35 Jahren zu-Fuß auf dem Papier, als es noch keine Editoren gab, ist inzwischen auch komplett verschüttet).

Gruß
LOM
 
ot:
LuckyOldMan schrieb:
Für mich sind 1KB immer noch 1024Bytes.
Zum Vergrößern anklicken....
Grundsätzlich bin ich auch so aufgewachsen, aber es gibt einen Standard der IEC

1000 Byte sind ein Kilobyte
1024 Byte sind ein Kibibyte

https://de.wikipedia.org/wiki/Byte

Windows rechnet mit 1024, schreibt aber kB dahinter anstatt KiB. Warum sie das nicht einfach mal Ändern frage ich mich schon seit langem.
Letztlich ist es doch auch für den Verbraucher Transparenter.

Man kann einem normalbegabten (Win-)User eher schlecht vermitteln, warum seine frisch gekaufte Terrabyte Festplatte nur 931 Gigabyte Aufweist.

p.s.: Viel erfolg mit der Garfikkarte...
 
  • Gefällt mir
Reaktionen: dg2rbf
LuckyOldMan schrieb:
ast Du denn jetzt das 5870pc.rom erfolgreich zur 5870mac.rom mit zwei verbliebenen MCUCs umgestrickt?
Zum Vergrößern anklicken....

Nein, das hat nicht geklappt, mit der Methode wie ich es probiert (und an eigener 4870 auch getestet habe) bleibt nicht genug Platz, der Bios-Rom Teil ist einfach zu groß. Wie ist denn das dritte Byte Deines Roms ? Vielleicht hast Du ein anderes Rom wie ich geladen habe.
 
geb mal die drei ersten Bytes in Hex durch von Deinem Rom
 
Nein, hat er nicht, wäre aber eine Möglichkeit, wenns nicht anders gegangen wäre.
Udo Martens schrieb:
Bei dem ROM war das Problem (so wie bei irgendwie fast jedem ROM), dass das Script den EFI-Teil stumpf hinters VBIOS einfügt und dadurch den restlichen Code überschreibt. Genau das wird ja bei netkas auch beschrieben, man muss dann händisch Platz freimachen.

Weil das ROM mit EFI aber etwas Überlänge bekommen hat und nicht mehr in den Speicher gepasst hätte, habe ich sein VBIOS gekürzt.
Zum Vergrößern anklicken....
 
vbios gekürzt...

Dann ists klar, sonst hätte das nicht in ein 128er Flash gepasst.

Das ist spannend, wie kürzt mann ein vbios ohne dass es nachher Probleme gibt ? Gibt es da Prüfsummen die angepasst werden oder kürzt man einfach Texte ?
 
Wenn Du nur das VBIOS markierst, kannst Du erkennen, dass am Ende ein Haufen FFs stehen. Statt das ungenutzt stehenzulassen, kann man einfach die Angabe der Länge ändern und das VBIOS vorher enden lassen, steht ja eh kein Code drin.
 
  • Gefällt mir
Reaktionen: LuckyOldMan
Udo Martens schrieb:
Wenn Du nur das VBIOS markierst, kannst Du erkennen, dass am Ende ein Haufen FFs stehen. Statt das ungenutzt stehenzulassen, kann man einfach die Angabe der Länge ändern und das VBIOS vorher enden lassen, steht ja eh kein Code drin.
Zum Vergrößern anklicken....


ok,
Anfang ist
$55 $AA $7E

$7E * $200 ist $FC00, das Ende des VBios

dann die vielen FFs Blockweise a 512 Bytes ($200) löschen und den Zähler $7E entsprechend verkleinern.

Und Prüfsummen müssen keine errechnet werden (?)
 
LuckyOldMan schrieb:
Von der Handhabung her könnte ich das oben nicht umsetzen, weil mir der Umgang mit HEXen fehlt, aber gedanklich durchaus nachvollziehen (das HEX-Rechnen vor 35 Jahren zu-Fuß auf dem Papier, als es noch keine Editoren gab, ist inzwischen auch komplett verschüttet).

Gruß
LOM
Zum Vergrößern anklicken....

In Hex rechnen kann der eingebaute MacOs Rechner im Programmer Mode (Apfel-3)
 
Das fixrom-Script erkennt die neue Größe, setzt den last image indicator auf 0 und berechnet das letzte Byte für die Checksumme. Das ist übrigens falsch, denn kein AMD-BIOS (weder VBIOS noch EFI-Teil) verwendet im Gegensatz zu nVidia das letzte Byte zur Korrektur; das muss also irgendwo dazwischen liegen.
Wahrscheinlich ist es eine Pfuschlösung, das Flashtool bemängelt den Fehler zumindest nicht und die BIOSse scheinen trotzdem zu funktionieren. ;)
 
  • Gefällt mir
Reaktionen: Macschrauber
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben Unten