Search results

@jonisign, great! With the trick, do you still have OC and WEG ?

@jonisign I have the same issue and under testing of RTCMemoryFixup.kext. The reference comes from this thread.

@candurin I'm using OC 0.59, and I noticed the OC CleanNvram function can alter the boot priority without getting into BIOS setting page. It seems that 4.4c stores some parameters in the NVRAM. Could that be the main different between Clover and OC ?

Clover or OC and which version No. ?

I have the same issue, even after I disable the SSDT. Maybe it's related to BIOS 4.4c.

@candurin you're using Clover ?

Thanks @sffjawsh . Cause I’m not quit sure the exact function of WEG. In my opinion, if it’s mimicking an EGPU, maybe the cause would be the system failed to catch the graphic card that supposed to be connected to TB but actually not.

Don't know if it's related to TB SSDT ? But it happened many times after TB SSDT was set. Could this be a conflict between WEG and TB SSDT ? panic(cpu 0 caller 0xffffff7f86a858b6): "virtual bool AMD9500Controller::detectPowerDown(): GPU is not found. PCI config access fails...

Thanks! @mango1122 . The KP keeps happening esp. after a long sleep. The error message is fixed. panic(cpu 4 caller 0xffffff8000e91b2c): Sleep transition timed out after 180 seconds while calling power state change callbacks. Suspected bundle: com.apple.iokit.IOGraphicsFamily. Thread 0x2cedd...

Thanks @mango1122 , in terms of a random DROM, I decided to put the original UID in though that's not following the CaseySJ's TB rule. No more error found. But the link speed changed. And the Domain UUID still changing every reboot. Is that normal ?

Sorry to confuse you @sffjawsh , my graphic card is RX460. Follow the CaseySJ's method, I build my own DROM into the SSDT. The system showed "Failed CRC8 Verification", while the UID in the TB page remain the same. I wonder if the SSDT DROM works only after we flashing the patched ROM.

The same as @fangf2018 , I use SSDT method. Don't know the relationship of enabling TB and the KP. But the error code can be traced to this article but I can not duplicate the process as the article mentioned.

Congratulate ! And great to know that our UID are different. UUID dominio changes every reboot while UID remain the same. It's better to mask UID. You still stay in the stock 14? Is the type-c working normally?

Maybe disable TB Boot Support.

@mango1122 Every reboot, the Domain UUID changes while UUID remain the same. Which means we do not have a fixed DROM and the system creates one by itself . Am I right ?

Sorry that I do not have TB device to test it. However, after several sleep, the TB tree/system info/type c hot plugging, still there. And I noticed the content of IOThunderboltPort@3, CaseSJ points out for the prover of DROM exists, is the same as CaseSJ's. This seems to be the prover that we...

Thanks for your great work! @mango1122 One more question. I got this error message, the only one about TB, from the system log: 2020-05-08 15:59:07.403064+0800 localhost kernel[0]: (IOThunderboltFamily) <IOThunderboltFamily`IOThunderboltEEPROM::getDROM()> IOThunderboltEEPROM::getDROM - Error...

I confirm this works! Thanks @mango1122 . But I don't need step5.

Those who has the hardware flashing tools could you try to update the TB firmware via the FwUpdateTool V1.0.4 with the patched file ASRock_z390_ITX_Patched_NVM20_try1 ? It seems the FwUpdateTool v1.0.4 did not block the update.

Mine is "DC",too. I noticed the difference from @mango1122 and all of us is RP21@1B,"4".