Contribute
Register

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

Status
Not open for further replies.
EDIT4.
finaly found reverse offsets to power tables and patched it
It looks like that should work, I'll give it a try on the weekend

Adding two Files:
Before timings insert and reverse offset jumps.zip
After timings insert and reverse offset jumps.zip
The Voltage-offset difference is expected. It is my understanding that the 4170 is pushed harder than the 4150 and this is one of the ways that this is done.
Instead of changing the clocks or stock voltages, the ROM programmers change the offsets.
EDIT8.

IMPORTANT:
You need to disable SecureBoot / Activate CSM in your
Motherboard UEFI because the modification will make
the cryptographic signature invalid.


This may or may not be an issue, since in my G5 the Bios has the UEFI module already cooked into the Bios, so if the signature in the MXM card is checked and fails, it will revert to the bios version for boot, then when the OS drivers kick in and read the VBios from the MXM card, they will get the new stuff and hopefully work... At least in theory

-edit
Actually this could explain why when I change the working ROM to device-id 67E8, it still defaults to 67E0. So again I may be wrong about the switchover and may in fact need to be in CSM mode to work.

Also there's how the DSDT reports the card, and maybe where the drivers get the info:

1621616368481.png


This part we can patch with a SSDT

EDIT9.

And about memory trainings, you was interested in:

Thanks
 

Attachments

  • rw.png
    rw.png
    65.2 KB · Views: 34
Last edited:
I have “greatest “ results:

791C6FC6-E492-4DE3-A9B6-9F45CBAB3E2D.jpeg

I made easier way of unbrick rom without hotgun))) thanks for gpot user recommendation)))


So patching memory test to zeros bricks gpu. The laptop trying to get boot section but freezes, the keyboard usb and other is working, so the system is not in loop, just won’t continue.

Timings patch is working until drivers are starting: as results: Windows failed to initialize driver; Mac OS kernel Panic; Ubuntu Acpi bufer stuck.
622939AE-0F67-4922-8C62-26597142A69C.jpeg

2C3111F6-E612-4499-89F1-A94608C9FBF6.jpeg

OSC is oscillator.


Switch to oem rom (pegatron-desktop) and all is working, even Catalina, but powersaving failed on any os, so if we use it, it will kill vrm or battery controller).

I have some ideas, but tired of this. The answer may be simple: even connectors priority in vbios. Like I was saying before: Apple connectors are related to pegatron, and actually same as three presented framebuffers like Palena, Berbice, Yelcho... but hp connectors are related to Baladi, which is desktop, so maybe it’s a reason.


I will look on your dsdt related images, I think that they could be another way of possibility!
 
Last edited:
Actually this could explain why when I change the working ROM to device-id 67E8, it still defaults to 67E0
No, the Id is written inside of chip. Vbios rom is like operating system for processor, and afterlife communication with driver in os win, etc
 
No, the Id is written inside of chip. Vbios rom is like operating system for processor, and afterlife communication with driver in os win, etc
Ok that makes more sense.

The framebuffer route could be another possible option. When I patched all the connectors on the 4150 ROM to match mine, it wouldn't work in Catalina, but when I only patched the first 3 (didn't include the HDMI connector) then it worked, and it's the same with the 560 ROM. as long as the HDMI connector is defined as DP and not HDMI it seems to have worked. I thought it was due to some other part of the puzzle I was missing with changing the connector to HDMI, but it could be the Catalina driver hates HDMI!!!

This is worth following up on, I'll do some tests tomorrow. Change the HDMI to DP on my good ROM and see what happens.

Test didn't work, I changed Bios to CSM, and tried Rom without HDMI connectors, stall, changed device-id, stall, changed subsystem-id, stall.
So it's not there.

EDIT
On another front, I'm trying to dump the memory range used by the MXM card to try to find a difference between both ROMS as far as ACPI initialization is concerned.
Because if the problem is that Catalina can't initialize properly, it may be an easy SSDT fix to flip the bit on startup (knowing which bit to flip)
 
Last edited:
Ok after comparing the 2 Roms we have for same device-id 67E8 (Vaughn and Pegatron) One works with Catalina the other one doesn't, it should be clear that these are the ones we need to base all our diff work on. Since they're basically for the same card and one works and the other doesn't.

The headers don't have too many diferences and making 10 different Roms with one difference at a time could be a brute force attempt.

Screen Shot 2021-05-21 at 8.53.10 PM.png


Screen Shot 2021-05-22 at 12.25.21 AM.png


Unexplained differences are in green.
I included the Vaughn Rom
 

Attachments

  • Vaughn.ROM.zip
    44.4 KB · Views: 23
Ok after comparing the 2 Roms we have for same device-id 67E8 (Vaughn and Pegatron) One works with Catalina the other one doesn't, it should be clear that these are the ones we need to base all our diff work on. Since they're basically for the same card and one works and the other doesn't.

The headers don't have too many diferences and making 10 different Roms with one difference at a time could be a brute force attempt.

View attachment 519305

View attachment 519306

Unexplained differences are in green.
I included the Vaughn Rom
I will take a break. And continue research framebuffer on first version of Catalina. Vaguhn has even wrong eDP connector location. This explains why I have this strange micro freezes. On Apple vroms, edp has different location. That’s why patching pegatron to get eDP working has no effect, because eDP is location is 3 connector, while vaguhn is first.

So I force load Berbice and got black screen, which really interesting related to the framebuffer issue.

Edit1.
I made full replacement of Vaughn connectors section with the Pegatron. And still no Catalina desktop. So it’s not a problem.

Problem maybe in power tables


Edit2.

Command and Data tables. Possibly one of command tables are need to be patched
All info in Archive.


Here is differences in COMMAND tables



EDIT3.
GREAT HEX calculator for corrections of table offsets. I decided to get back to memory timings and correct it woth new command and data offsets.

So formula is simple:
memory timings in vaughn are located at offset 0x9776 so after inserted timings, everything lower than it is now wrong offsets. Thats why i found (the latest hex line which can help to find how length of timings change the entire offsets). SO i get offset of vaughn without timings insert 0xC306 than search data in moded rom 7300010200080201020052475202, and get new offset 0xC646. Using hex calculator i found difference "-340". And now i can fast change offsets by adding to old +340, and only after 0x9776


EDIT4.
Example of OFFSETs redirections:


HP Vaughn G1-50 GDDR5.rom

Command Tables:
Original BigEndiad
New BigEndiad
New LittleEndian
0x C306 to 0x C646 litend 46C6 Len 0073 (ASIC_Init)
0x C37A to 0x C6BA litend BAC6 Len 0057 (GetDisplaySurfaceSize)
0x C3D2 to 0x C712 litend 12C7 Len 00b7 (ASIC_RegistersInit)
0x E018 to 0x E358 litend 58E3 Len 009e (VRAM_BlockVenderDetection)
0x EAAE to 0x EDEE litend EEED Len 0267 (SetClocksRatio/DIGxEncoderControl)
0x C48A to 0x C7CA litend CAC7 Len 010b (MemoryControllerInit)
0x E0B6 to 0x E3F6 litend F6E3 Len 001a (MemoryParamAdjust)
0x C596 to 0x C8D6 litend D6C8 Len 00ff (GPIOPinControl)
0x C696 to 0x C9D6 litend D6C9 Len 01ac (SetEngineClock)
0x C842 to 0x CB82 litend 82CB Len 0122 (SetMemoryClock)
0x C964 to 0x CCA4 litend A4CC Len 04cb (SetPixelClock)
0x CE30 to 0x D170 litend 70D1 Len 0187 (DynamicClockGating)
0x CFB8 to 0x D2F8 litend F8D2 Len 0007 (ResetMemoryDLL)
0x CFC0 to 0x D300 litend 00D3 Len 0007 (ResetMemoryDevice)
0x E876 to 0x EBB6 litend B6EB Len 0031 (MemoryPLLInit)
0x E8A8 to 0x EBE8 litend E8EB Len 0010 (AdjustDisplayPll)
0x D348 to 0x D688 litend 88D6 Len 0111 (AdjustMemoryController)
0x D45A to 0x D79A litend 9AD7 Len 0021 (EnableASIC_StaticPwrMgt)
0x D47C to 0x D7BC litend BCD7 Len 008e (ASIC_StaticPwrMgtStatusChange/SetUniphyInstance)
0x D50A to 0x D84A litend 4AD8 Len 02bf (CV1OutputControl)
0x F466 to 0x F7A6 litend A6F7 Len 0096 (TMDSAEncoderControl)
0x F4FC to 0x F83C litend 3CF8 Len 0189 (LVDSEncoderControl)
0x D7CA to 0x DB0A litend 0ADB Len 0078 (EnableScaler)
0x D842 to 0x DB82 litend 82DB Len 0074 (BlankCRTC)
0x D8B6 to 0x DBF6 litend F6DB Len 003e (EnableCRTC)
0x D8F4 to 0x DC34 litend 34DC Len 002c (EnableVGA_Render)
0x D920 to 0x DC60 litend 60DC Len 0022 (EnableVGA_Access/GetSCLKOverMCLKRatio)
0x D942 to 0x DC82 litend 82DC Len 0019 (SetCRTC_OverScan)
0x D95C to 0x DC9C litend 9CDC Len 0080 (SetCRTC_Replication)
0x D9DC to 0x DD1C litend 1CDD Len 00c6 (SelectCRTC_Source)
0x DAA2 to 0x DDE2 litend E2DD Len 016f (EnableGraphSurfaces)
0x DC12 to 0x DF52 litend 52DF Len 004e (UpdateCRTC_DoubleBufferRegisters)
0x DC60 to 0x DFA0 litend A0DF Len 0090 (LUT_AutoFill)
0x FA80 to 0x FDC0 litend C0FD Len 0297 (EnableHW_IconCursor)
0x DCF0 to 0x E030 litend 30E0 Len 003d (GetMemoryClock)
0x DD2E to 0x E06E litend 6EE0 Len 00d8 (GetEngineClock)
0x DE06 to 0x E146 litend 46E1 Len 0153 (SetCRTC_UsingDTDTiming)
0x F76C to 0x FAAC litend ACFA Len 01d1 (LVTMAOutputControl)
0x DF5A to 0x E29A litend 9AE2 Len 00be (VRAM_BlockDetectionByStrap)
0x F9B0 to 0x FCF0 litend F0FC Len 00cf (MemoryCleanUp)
0x E0D0 to 0x E410 litend 10E4 Len 0231 (ReadEDIDFromHWAssistedI2C/ProcessI2cChannelTransaction)
0x F686 to 0x F9C6 litend C6F9 Len 00e5 (WriteOneByteToHWAssistedI2C)
0x E302 to 0x E642 litend 42E6 Len 005f (ReadHWAssistedI2CStatus/HPDInterruptService)
0x E362 to 0x E6A2 litend A2E6 Len 000a (SpeedFanControl)
0x E36C to 0x E6AC litend ACE6 Len 000a (PowerConnectorDetection)
0x E376 to 0x E6B6 litend B6E6 Len 003c (MC_Synchronization)
0x E3B2 to 0x E6F2 litend F2E6 Len 01af (ComputeMemoryEnginePLL)
0x E562 to 0x E8A2 litend A2E8 Len 0007 (MemoryRefreshConversion)
0x ED16 to 0x F056 litend 56F0 Len 0029 (VRAM_GetCurrentInfoBlock)
0x E56A to 0x E8AA litend AAE8 Len 0165 (DynamicMemorySettings)
0x E6D0 to 0x EA10 litend 10EA Len 011a (MemoryTraining)
0x E7EA to 0x EB2A litend 2AEB Len 008c (EnableSpreadSpectrumOnPPLL)
0x E8B8 to 0x EBF8 litend F8EB Len 0171 (SetVoltage)
0x F93E to 0x FC7E litend 7EFC Len 0071 (DAC2OutputControl)
0x CFC8 to 0x D308 litend 08D3 Len 032d (ClockSource)
0x D2F6 to 0x D636 litend 36D6 Len 0052 (MemoryDeviceInit)
0x ED40 to 0x F080 litend 80F0 Len 0146 (DIG1TransmitterControl/UNIPHYTransmitterControl)
0x EE86 to 0x F1C6 litend C6F1 Len 0338 (DIG2TransmitterControl/LVTMATransmitterControl)
0x F1BE to 0x F4FE litend FEF4 Len 024c (ProcessAuxChannelTransaction)
0x F40A to 0x F74A litend 4AF7 Len 005c (DPEncoderService)



Data Tables:

0x 8C76 to ++ ______ litend ____ Len 00e4 Rev 01:02 (StandardVESA_Timing)
0x 8D5A to ++ ______ litend ____ Len 006c Rev 02:02 (FirmwareInfo)
0x 8DC6 to ++ ______ litend ____ Len 0034 Rev 02:01 (DAC_Info)
0x 8DFA to ++ ______ litend ____ Len 004e Rev 01:03 (LVDS_Info)
0x C278 to 0x C5B8 litend B8C5 Len 0038 Rev 02:01 (AnalogTV_Info)
0x 8E48 to ++ ______ litend ____ Len 00dc Rev 01:01 (GPIO_I2C_Info)
0x 8F24 to ++ ______ litend ____ Len 000c Rev 01:05 (VRAM_UsageByFirmware)
0x 8F30 to ++ ______ litend ____ Len 0020 Rev 01:01 (GPIO_Pin_LUT)
0x 8F50 to ++ ______ litend ____ Len 0074 Rev 01:01 (VESA_ToInternalModeLUT)
0x 8FC4 to ++ ______ litend ____ Len 0018 Rev 02:03 (ComponentVideoInfo)
0x 8FDC to ++ ______ litend ____ Len 032a Rev 07:01 (PowerPlayInfo)
0x C260 to 0x C5A0 litend A0C5 Len 0018 Rev 02:01 (SaveRestoreInfo/DispDevicePriorityInfo)
0x 9306 to ++ ______ litend ____ Len 011e Rev 01:03 (Object_Info/Object_Header)
0x 96F8 to ++ ______ litend ____ Len 007d Rev 01:01 (IndirectIOAccess)
0x 9424 to ++ ______ litend ____ Len 02d4 Rev 02:01 (MC_InitParameter/AdjustARB_SEQ)
0x C1D4 to 0x C514 litend 14C5 Len 0028 Rev 03:01 (ASIC_InternalSS_Info/ASIC_MVDDC_Info)
0x C1FC to 0x C53C litend 3CC5 Len 0064 Rev 02:03 (TV_VideoMode/DispOutInfo)
0x 9776 to ++ ______ litend ____ Len 0310 Rev 02:02 (VRAM_Info)
0x 9A86 to 0x 9DC6 litend C69D Len 261a Rev 03:01 (MemoryTrainingInfo/ASIC_MVDDQ_Info)
0x C0A0 to 0x C3E0 litend E0C3 Len 010c Rev 03:06 (ASIC_ProfilingInfo/ASIC_VDDCI_Info)
0x C1AC to 0x C4EC litend ECC4 Len 0028 Rev 03:01 (VoltageObjectInfo/VRAM_GPIO_DetectionInfo)
 

Attachments

  • _AMD_TABLES.zip
    678.7 KB · Views: 23
Last edited:
I will take a break. And continue research framebuffer on first version of Catalina. Vaguhn has even wrong eDP connector location. This explains why I have this strange micro freezes. On Apple vroms, edp has different location. That’s why patching pegatron to get eDP working has no effect, because eDP is location is 3 connector, while vaguhn is first.

So I force load Berbice and got black screen, which really interesting related to the framebuffer issue.

Edit1.
I made full replacement of Vaughn connectors section with the Pegatron. And still no Catalina desktop. So it’s not a problem.

Problem maybe in power tables


Edit2.

Command and Data tables. Possibly one of command tables are need to be patched
All info in Archive.



Here is differences in COMMAND tables




EDIT3.

GREAT HEX calculator for corrections of table offsets. I decided to get back to memory timings and correct it woth new command and data offsets.

So formula is simple:
memory timings in vaughn are located at offset 0x9776 so after inserted timings, everything lower than it is now wrong offsets. Thats why i found (the latest hex line which can help to find how length of timings change the entire offsets). SO i get offset of vaughn without timings insert 0xC306 than search data in moded rom 7300010200080201020052475202, and get new offset 0xC646. Using hex calculator i found difference "-340". And now i can fast change offsets by adding to old +340, and only after 0x9776


EDIT4.
Example of OFFSETs redirections:

And It looks like in the header there's an offset that most likely points to the signature or EOF, that will also need to be changed.
It's in RED in my previous post 3A88.
Also there's a mystery offset in light brown color 9902 and it may be after your changes.
 
And It looks like in the header there's an offset that most likely points to the signature or EOF, that will also need to be changed.
It's in RED in my previous post 3A88.
Also there's a mystery offset in light brown color 9902 and it may be after your changes.
Here is timmings and command + data tables offsets corrected
+ another file with header offsets

Not tested yet
 

Attachments

  • timings+data&cmdpatch_+header offset.zip
    89.7 KB · Views: 24
Affleck matches Aomorhid in many things, and the same with Pegatron and Vaughn, so between those and the Dell560 as a wildcard I expected to be able to find a link to at least a couple of things present in the command tables that linked Pegatron&Dell, but different in the others, but no luck and without knowing what these commands actually are, this is another dead end.

Screen Shot 2021-05-22 at 5.03.40 PM.png


I'll try your rom next:

Update:
Didn't work, KP reboot in MacOS and Windows device fault.
 
Last edited:
Affleck matches Aomorhid in many things, and the same with Pegatron and Vaughn, so between those and the Dell560 as a wildcard I expected to be able to find a link to at least a couple of things present in the command tables that linked Pegatron&Dell, but different in the others, but no luck and without knowing what these commands actually are, this is another dead end.

View attachment 519374

I'll try your rom next
Use hexfiend app for hex compare. In one second it will show you all differences and offsets if they are present
 
Status
Not open for further replies.
Back
Top