Contribute
Register

<< Solved >> AMD WX4170 dGPU on ZBook G5 17 Laptop

Joined
Mar 29, 2019
Messages
157
Motherboard
H87M-PRO
CPU
i5-4690K
Graphics
HD4600 + GTX 660 TI
Mac
  1. iMac
  2. MacBook Pro
I highly suspect a whitelist in the management engine, based on symptoms.
2 approved cards (4150,4170) only 2 roms post in discrete and both are present as part of the bios. And get shadowed from bios, not the card in discrete mode.
That means the source for the management engine's shadow rom has to be in the bios itself. This explains why Crane works in hybrid, but can't be shadowed and device-id or something else mismatches to what is allowed by management engine or simply management engine looks for rom in bios, can't find it and bricks on post.

One way to test this theory would be to change the id of a known working rom Aomorhid to match Crane and see it if posts.

Same but reverse would be to edit Crane's id to match Aomorhid, and see if it posts.
I suspect if done right the laptop will post but the management engine will use the bios version, completely ignoring the rom in the card.

Because the Bios itself has so many security redundancies, I don't think editing the bios would be a good solution, so we have to find a way to inject our rom from the card to acpi.
There is no white list (only for secure Boot!!!!!!)

I dumped rom from VFCT table, but it was late night, so i cant remember how i did this.
Screen Shot 2021-07-29 at 19.55.42.png

The next step is to find where the image is located and to which one GFX0/*X* this one connected. I think, that if you change only one byte at this header (the number of spare, or subid device, then bios will no longer recognize gpu and will work only through MXM spi)


But!!! Only @nikey22 have suggestions about how to decode this data. Anyway the SMBus is connected to EC, and your firmware support any addresses of system management data, etc, so your system wont post about dead GPU as in my case. Why I am so sure?
Screen Shot 2021-07-29 at 19.08.04.png


That is really interesting why board have additional holes after SMD resistors, maybe this one connected else where, for example to chipset? And if i desolder those two resistors, maybe i will solve post issue problem? Hmm or somewhere else connected another device?




Screen Shot 2021-07-29 at 19.06.34.png
Screen Shot 2021-07-29 at 20.06.52.png


The other way, i started to test, but cant afford more time now to this way of efishell64 research. But recommend for reading: https://forums.macrumors.com/threads/2011-imac-graphics-card-upgrade.1596614/post-30132232

By @joevt from macrummors

early results:


 
Last edited:
Joined
Jul 21, 2011
Messages
318
Motherboard
Zbook G5 17"
CPU
i7
Graphics
AMD WX-4170
Mac
  1. MacBook Pro
  2. Mac mini
  3. Mac Pro
Ok not whitelist, but the same result. if Firmware Management Engine only shadows a rom that is already present in the bios image, it is a "whitelist" per se.
Now if the first GPU is IGPU, then it's all allowed, so no whitelist, but for discrete, the first GPU is MXM, and if the only way to make it work is to shadow the rom, and only an already present rom can be shadowed... = "whitelist by another name"
 
Joined
Mar 29, 2019
Messages
157
Motherboard
H87M-PRO
CPU
i5-4690K
Graphics
HD4600 + GTX 660 TI
Mac
  1. iMac
  2. MacBook Pro
Ok not whitelist, but the same result. if Firmware Management Engine only shadows a rom that is already present in the bios image, it is a "whitelist" per se.
Now if the first GPU is IGPU, then it's all allowed, so no whitelist, but for discrete, the first GPU is MXM, and if the only way to make it work is to shadow the rom, and only an already present rom can be shadowed... = "whitelist by another name"
Okay, I get your vision of white list. You’re talking about SSID - subsystem id. And this part of atombios config, but this ssid is coded in he part of the rom which are comes with the mxm spare part. And we can easy to identify that coded ssid with comparing the Apple 13.3, 14.3 mbp vbios roms. As the header should be same, but coded ssid are different. That is good theory but it cannot pretend to be perfect as there is the gpu with no spi. So in this case efi program compares the device I’d with preloaded images. But this can be easy test with OEM vbios with two bytes patch of ascii code for example. If change ssid to non present, then system will load mxm vbios!
 
Joined
Mar 29, 2019
Messages
157
Motherboard
H87M-PRO
CPU
i5-4690K
Graphics
HD4600 + GTX 660 TI
Mac
  1. iMac
  2. MacBook Pro
Or stall/brick
It bricks if:
Checksum is wrong, and vrom won’t be loaded.

Subid or other data not corresponding to mxm itself, then cpu simply won’t find the gpu in address mapping. That’s data we need to decode to understand what’s wrong could be there.

One of modules causes infinite loop of procedure that freezes system.

Some registers are missing or not corresponding to expected and gpu is waiting for something

Wrong initialization sequence is executed
 
Joined
Mar 29, 2019
Messages
157
Motherboard
H87M-PRO
CPU
i5-4690K
Graphics
HD4600 + GTX 660 TI
Mac
  1. iMac
  2. MacBook Pro
Good news!
Finally hack unknown part of header, decode it and patch, then code it back. The method explained in my 4150 for Zbook G3 theme at techpowerup.

So, I done the fully new build that is based on 560x header with patching and vgafirmware but with vortex vbios and parser + connectors patch + Apple memory training. And build is working fine with discrete mode. Stunning stable then ever before on such extreme hybrid vbios. But this means that with this method is possible to build 4170 vbios that will be almost fully vanilla and will work on discrete mode!!!



Also I recorded extended tutorial on how this was done! I will edit it next week. Two hours of work on new build!
 

Attachments

  • 0295D327-8CAE-4521-89CC-44332AFE3BB7.jpeg
    0295D327-8CAE-4521-89CC-44332AFE3BB7.jpeg
    4.9 MB · Views: 24
  • A91D7AD2-6553-41FC-AE1D-8D8CAE5B8D03.jpeg
    A91D7AD2-6553-41FC-AE1D-8D8CAE5B8D03.jpeg
    2.6 MB · Views: 25
  • CDEB1C73-F66A-4546-A516-0C43FEAC7DC0.jpeg
    CDEB1C73-F66A-4546-A516-0C43FEAC7DC0.jpeg
    3.7 MB · Views: 23
  • 902C9F2E-9F61-4241-95B3-3E7DBD4D0472.jpeg
    902C9F2E-9F61-4241-95B3-3E7DBD4D0472.jpeg
    3.4 MB · Views: 21
Joined
Mar 29, 2019
Messages
157
Motherboard
H87M-PRO
CPU
i5-4690K
Graphics
HD4600 + GTX 660 TI
Mac
  1. iMac
  2. MacBook Pro
Also I found who is loading vbios from mxm. And this is not a MacOS, that is clover/ OpenCore. Because that bootloader emulating parts of Apple ram mapping! The clover or whatevergreen loads there a video driver. So that’s why the whatevergreen has an option of injection for acpi and ioregistry vbioses!
 
Joined
Mar 29, 2019
Messages
157
Motherboard
H87M-PRO
CPU
i5-4690K
Graphics
HD4600 + GTX 660 TI
Mac
  1. iMac
  2. MacBook Pro
I am really impressed with the amount of work you've put into this. Makes me wonder how hard it would be to hack the rom of a similar device (the W4190M on a G4).
Thanks! But what is the problem and that gpu suppouse to be old now?
 
Joined
Mar 29, 2019
Messages
157
Motherboard
H87M-PRO
CPU
i5-4690K
Graphics
HD4600 + GTX 660 TI
Mac
  1. iMac
  2. MacBook Pro
WX 4170
Final vBios build for Zbook G5 17
And WX 4170 for iMac 2011 (patched by @nikey22)


for additional info visit (project page):


 

Attachments

  • ZBOOK17_G5_WX4170_NEBULA_VBIOS_v2(GOP).rom.zip
    115.3 KB · Views: 17
  • WX4170_NEBULA_imacOBJ.rom.zip
    115.1 KB · Views: 15
Top