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

[EdwardGeo]

I have an idea for fan controller of zbook g3. Wx4170 have a fan control utility inside vbios. The Strato and Troppo G3 also have that utility, but Wx4150 doesn’t. So I have an idea to use wx4170 registers (they should be the same as 4150 chip have ) to patch data values of Troppo and strato to make fake interface that possibly have pwm functions to EC for controlling fan speed. That’s possibly working idea. But those registers are working through ram and going to cpu, then chipset, LPCBUS and to EC. If this ram addresses are not occupied then it should work. I can try to simply copy data from real registers to fake with mini subprogram attached to the end of speed fan control with simple instruction: if fan register not equal to fake register, then copy data from real register to fake.

 

[theroadw]

@theroadw, Disable module is not enough. Ive made it month ago and got brick. Same i get yesterday. If MemTrainInfo is disabled, then need to patch memory training command. But even then it will brick, as some registers now are missing. But if patch EnableGraphSurfaces registers at the end of the file between 5B and 5B HEX bytes, then those registers will appear again, but now the module connected with EnableHW_IconCursor, MC_InitParameter_AdjustARB_SEQ and they are need to be replaced too. But Key problem is next - encoders will fail as Transmitter will freeze in loop sequence of mismatch (wrong) encoders object IDs. And if Encoders are patched, then need to patch registers of ClockSource and PixelClock for discrete mode.

But I made a Encoders patch that can cheat with ClockSource and pixelclock. So hope that only one register left to patch

Makes sense, thanks for the explanation.

I tested Discrete mode and it works, all OS's except Catalina (black screen) so will need to troubleshoot that one.

Here's the good news though:
Windows Performance is the same as vanilla Aomorhid rom.

Running stability tests, but so far so good. Only glitch so far is fullscreen Windows OpenGL is a bit sensitive to exiting for some reason, but it may be the Valley, as I always run it in windowed mode.

Mojave/Catalina performance seems very similar to original rom, can't quite get the same ultra boost on Mojave, and Catalina seems a bit better than Mojave benchmark-wise, but nothing to sneer at.

This is wicked!!! dual gpu up to Monterey!!!

shikigva=80 flag seems to fix DRM in Catalina and now I'll try to fix the black screen on discrete.

 

[EdwardGeo]

I tested Discrete mode and it works, all OS's except Catalina (black screen) so will need to troubleshoot that one.

Disable framebuffer patches, debug kernel. Debug whatevergreen. One of builds resolve encoder issues , I think that is the reason of black screen


Did you try latest two builds?

Glitchy because of problems with setclock needs to be patched...

What’s shikigva80 patching?

 

[theroadw]

Disable framebuffer patches, debug kernel. Debug whatevergreen. One of builds resolve encoder issues , I think that is the reason of black screen

Not sure what it is, it actually looks the same as the original problem, vanilla aomorhid in discrete also results in same black screen (stalled), and can't test other partially working roms, as discrete breaks everything. Not a dealbreaker for me if this can't be solved as hybrid is my preference anyways.

Did you try latest two builds?

I'm using latest build vanilla connectors

Glitchy because of problems with setclock needs to be patched...

Could be, I'll try again vanilla rom to see if it's the rom or the card/software/os

What’s shikigva80 patching?

for DRM playback, it's whatevergreen set of patches for many protected video appletv, etc... options. shifting all of these to ATI card.

 

[EdwardGeo]

I'm using latest build vanilla connectors

And vanilla connectors is working normally under Windows with discrete mode ? That is really strange, because mine 4150 with vanilla connectors fails boot black screen on Windows.


Try to dump vbios with DarwinDumper and send me ACPI and IOREGISTRY versions. Also need a dump of clover dump vbios F4 or F3, start at address C0000. That will be stored on efi volume at clover/misc. so 3 files as result need for deeper research.


Can you share your PP injection ?

 

[theroadw]

Will do.
Also the black screen (Catalina +) in discrete doesn't respond to radeon--deinit, iMacPro1,1 smbios, direct device-id injection using plist or ssdt, using external screens, closed lid, injecting display+ connector features,pp tables, wegoff, agpd=vit9696/pikera/ignore. So basically not responding to any tricks.
I'll keep testing and get some debug logs to try to find out what's happening, only different symptom from before is the pink lines in Monterey stall.
Unfortunately as before the OS has not finished loading so there's no ssh or remote login capability, only hard reset.
On the plus side, zero problems with Linux or Mojave. And the Windows glitch seems to only affect Valley in Open GL mode the first time it is run, subsequent runs or using directx shows no glitch, and no other software seems to be affected. So I doubt it's the rom.

 

[EdwardGeo]

Also the black screen (Catalina +) in discrete doesn't respond to radeon--deinit, iMacPro1,1 smbios, direct device-id injection using plist or ssdt, using external screens, closed lid, injecting display+ connector features,pp tables, wegoff, agpd=vit9696/pikera/ignore. So basically not responding to any tricks.

debug, need debug. Vbios is not completed. DynamicClockGating operations could be buggy.

This problem with Aomorhid-nomemtrain-02-Connectors_V1-VanilaConnectors and Aomorhid-nomemtrain-02-Connectors_V2-MyStyle?

Try to dump vbios with DarwinDumper and send me ACPI and IOREGISTRY versions. Also need a dump of clover dump vbios F4 or F3, start at address C0000. That will be stored on efi volume at clover/misc. so 3 files as result need for deeper research.

that is important too.

 

[EdwardGeo]

@theroadw , I think we should continue here, as we are close to important openings in research!




Yeah, mine vbios from mxm also is in VCTF acpi table as hex. And that’s a poof that vbios is load correct, even if that is not in system bios. So definitely the problem of errors is smbus data of mxm. As smbus signaling of data lanes is 2.1v for One and 0.8v for zeros, it’s easy to check if smbus is working, using red led, as it operates with 2.1-2.4v. If I will get blinks, then the smbus signals are working. And initializing problem is problem of EC firmware. And it’s only for mine scenario of unsupported gpu by system.

Anyway my unsupported gpu opening curtain to deeper research.

Clover also can dump that acpi. But clover inject pci spi to ioregistry that’s is maybe not an issue, but developers concept. Anyway the clover or OpenCore could add option to read vbios from shadow ram, or from acpi tables or from pci spi. That’s doesn’t matter why they done that, but vctf table could be patched for Windows usage for testing of discrete without flashing the rom.

 

[EdwardGeo]

I compared G5 POSTED (ACPI) vbios of AOMORHID with System bios, end here is what i get:

AOMORHID POSTED VBIOS VS THE ROM ITSELF
	POSTED VBIOS	ROM
FirmwareInfo
USHORT FirmwarePosted:1	0x0001 (1)	0x0000 (0)
UCHAR ucMemoryModule_ID	0x01	0x00
VRAM_UsageByFirmware
ULONG ulStartAddrUsedByFirmware	0x003fffe0 (4194272)	0x00000000 (0)
USHORT usFirmwareUseInKb	0x0020 (32)	0x0000 (0)
LVDS_INFO
usPixClk	0x3bb4 (15284)	0x0000 (0)
usHActive	0x0780 (1920)	0x0000 (0)
usHBlanking_Time	0x014a (330)	0x0000 (0)
usVActive	0x0438 (1080)	0x0000 (0)
usVBlanking_Time	0x0034 (52)	0x0000 (0)
usHSyncOffset	0x0030 (48)	0x0000 (0)
usHSyncWidth	0x0020 (32)	0x0000 (0)
usVSyncOffset	0x0003 (3)	0x0000 (0)
usVSyncWidth	0x0005 (5)	0x0000 (0)
usImageHSize	0x017d (381)	0x0000 (0)
usImageVSize	0x00d6 (214)	0x0000 (0)
(union) ATOM_MODE_MISC_INFO sbfAccess
=> USHORT HSyncPolarity:1	0x0000 (0)	0x0001 (1)
=> USHORT RGB888:1	0x0001 (1)	0x0000 (0)
(union) USHORT usAccess	0x0204 (516)	0x0000 (0)
ucRefreshRate	0x3c (60)	0x0000 (0)
ucLCDPanel_SpecialHandlingCap	0x01 (1)	0x0000 (0)

So EFI runtime modifying vbios on thy fly to make it more fitted to hardware.

 

[theroadw]

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.