Ryzen 7000 Testing
- Thread starter PoMpIs
- Start date
- Joined
- Dec 15, 2022
- Messages
- 25
I little bit of topic but hopefully someone might be able to help.
// how to compare configs
What do you guys use to compare between different config.plist files? I am currently using Webstorm to git compare (my config on one branch and another config on different branch) but I get a lot of difference in order of listing for example - is there maybe a tool for config.plist formatting (order props by name or something) ?
// fan control
Is it possible to control fans from MACOS on AM5? Looks like AMD POWER GADGET has fan control section but I am getting no SMC driver error.
// how to compare configs
What do you guys use to compare between different config.plist files? I am currently using Webstorm to git compare (my config on one branch and another config on different branch) but I get a lot of difference in order of listing for example - is there maybe a tool for config.plist formatting (order props by name or something) ?
// fan control
Is it possible to control fans from MACOS on AM5? Looks like AMD POWER GADGET has fan control section but I am getting no SMC driver error.
I compare config.plist files quite frequently, but I do it simply by opening them in OpenCore Configurator and paging through each section. Oftentimes I know what kind of differences I'm looking for, so I simply click the relevant sections of OpenCore Configurator.I little bit of topic but hopefully someone might be able to help.
// how to compare configs
What do you guys use to compare between different config.plist files? I am currently using Webstorm to git compare (my config on one branch and another config on different branch) but I get a lot of difference in order of listing for example - is there maybe a tool for config.plist formatting (order props by name or something) ?
I haven't tinkered with fan control on any of my Intel and AMD systems. I set fan curves in BIOS and that has been sufficient.
Last edited:
Hi Casey, what was the fix for your Thunderbolt SSDTs resetting bios? If I enable SSDT DTPG, the bios would reset on every reboot or shutdown. The only solution to start the computer again was to clear CMOS. I tried this on both Bios 705 and 805.
Because Thunderbolt hot plug does not work at this time, I have disabled both the hot plug SSDT and DTPG. This allows Thunderbolt devices to work if connected before boot. It also prevents the BiOS reset problem. And even sleep/wake works with Thunderbolt devices connected.
I tried this, but the BIOS reset problem happens if we inject these properties using any method:
- PCI-Thunderbolt on root port
- PCIHotplugCapable on downstream bridge 0
Last edited:
- Joined
- Aug 7, 2022
- Messages
- 843
The BIOS reset is probably caused by AppleRTC writing into the wrong places which can also break sleep.
I have no bios reset, but if we touch here tb related part with a SSDT I have a boot loop also in a cold boot (no bios post at all)
to solve:
clear cmos and disable the problematic TB SSDT
After a couple week of intense use of this platform I have only a couple of issues (unsolved)
1) Thunderbolt hot plug
2) Asmedia USB controller which inhibits the wake option from USB keyboard or mouse touch
Solved problem in this particular configuration:
1) HDMI/DP audio lost on my two monitors if they are connected one in HDMI and the others in DP
to solve I have used a HDMI to DP converter
in trx40 rig this problem wasn't present with the same monitors
in others features it is perfect
ps I hate led on my Kingston Ram
to solve:
clear cmos and disable the problematic TB SSDT
After a couple week of intense use of this platform I have only a couple of issues (unsolved)
1) Thunderbolt hot plug
2) Asmedia USB controller which inhibits the wake option from USB keyboard or mouse touch
Solved problem in this particular configuration:
1) HDMI/DP audio lost on my two monitors if they are connected one in HDMI and the others in DP
to solve I have used a HDMI to DP converter
in trx40 rig this problem wasn't present with the same monitors
in others features it is perfect
ps I hate led on my Kingston Ram
I spent an hour or so on this just moments ago, as follows:
- Enabled FixRtcChecksum kernel quirk by itself -> BIOS reset occurs on reboot
- Disabled FixRtcChecksum and enabled RtcMemoryFixup.kext
- Used boot argument rtcfx_exclude to exclude these ranges:
- 00-7F -> BIOS reset occurs on reboot and "clock has invalid time" (hard boot needed; "Reboot" from macOS hangs)
- 40-7F -> Same as above
- 00-3F -> BIOS reset occurs on reboot, but no clock warning
- The other split:
- 80-FF -> BIOS reset occurs on reboot (hard boot needed; "Reboot" from macOS hangs)
- PCI-Thunderbolt on root port
- PCIHotplugCapable on downstream bridge 0
When PC is sleeping, RGB LEDs on DIMMs stay powered on. I've always found this helpful as a Sleep Indicator when all other lights and fans are turned off....
ps I hate led on my Kingston Ram
in my previous MSI board I could off also power blinking button (it was blu led and MSImobo allow to say to blink or to blink in color, blink in color set led off)
this four dimm plus blinking blu power button led is a bit annoying..but these dimm was a good buy 2/3 weeks ago so I can't complain too much)
What kind of devices are you guys using for Thunderbolt testing?
I have an ACASIS NVME enclosure but it was until recently being used as a TimeMachine backup drive for my X570 Creator build. I've already shown that it is recognized by my X670E Hero build but I haven't actually read or written anything to it on the Hero build. my X570 Creator build is presently in storage until I move it to a more permanent home so I will probably format the NVME in the enclosure for proper testing. but I am torn.
I'm just curious what are the other use cases for Thunderbolt circa 2023.
does anyone use their hackintosh with a mac studio display or the crazy 6K monitor from 2019?
I have this enclosure with a samsung 960 pro 1tb disk inside :
OWC Envoy Express TB3, CAJA EXTERNA SSD M.2
Even with Thunderbolt Hot Plug not working, I am incredibly grateful for your help. With your help, I now have an almost perfect working Hackintosh.
The only thing missing is Thunderbolt Hot Plug, which is not a necessity.
Everything else works.
For those that have problems with your Asus ProArt Creator X670E, PM me and I will walk you through your setup.
- Joined
- Dec 16, 2022
- Messages
- 183
Have you tried to turn off DP20 and recreate DPXX and recreate UPSB and related paths and dsm inside?
I tried this with several variations, but I haven’t tried this method along with RTC Fixup. I can do that soon.
One of the standard SSDTs (SSDT-4) contains a very interesting method. If I remember correctly, the method name is TBFF (not 100% sure). This is a very common method in nearly all standard Thunderbolt SSDTs, but in this case the method contains detailed register definitions of UPSB, DSB0, DSB1, DSB2, DSB3, and NHI0.
I have never seen such detail in a PC. Apple’s own firmware contains this level of detail because it’s necessary for switching the Thunderbolt controller from Internal Connection Manager (ICM) to OS Connection Manager (OSCM).
Windows and Linux work best in ICM. Mac works in either mode, but Thunderbolt Bus requires OSCM. Apple’s SSDT in combination with their PEI/DXE drivers is able to switch between these modes. When Boot Camp is launched, the mode changes to ICM.
I tried modifying our SSDT-4 to switch to OSCM by copying and modifying Apple’s ICMS method, which we have done successfully on Alpine Ridge, but the modification did not work. As time permits I’ll look into the Linux code to see if I’m using the correct command register and the correct command sequence.
This effort is not likely to succeed, but it can yield some insights that could be helpful in other ways.
Last edited:
Follow-up to previous post...
Then we have the definition for DSB0:
Similarly, we have DSB1:
We also have the following, which I believe is the Thunderbolt root port:
And this looks like the Native Host Interface (NHI):
Other notes:
- The method I referred to earlier is indeed TBFF
- This post lists the register definitions from that method
- The first line calls MMTB() to return the base address of the register
- The field unit object VEDI is the VEndor and Device ID (16 bits for vendor, 16 bits for device)
- Each of the subsequent field names includes a number that represents the offset from base address
- So UP04 is 4 bytes down from the base
- The prefix UP refers to UPSB (Upstream Bridge)
- Offset statements simply offset the next field by the given number of bytes from base address
- Some of these UPxx field entries are command registers and others are status registers
C:
Local0 = MMTB ()
OperationRegion (PXVD, SystemMemory, Local0, 0x0600)
Field (PXVD, ByteAcc, NoLock, Preserve)
{
VEDI, 32,
UP04, 8,
Offset (0x08),
UP08, 32,
UP0C, 8,
Offset (0x18),
UP18, 8,
UP19, 8,
UP1A, 8,
Offset (0x1C),
UP1C, 8,
UP1D, 8,
Offset (0x20),
UP20, 16,
UP22, 16,
UP24, 16,
UP26, 16,
UP28, 32,
UP2C, 32,
Offset (0x50),
UP50, 8,
Offset (0x5F8),
U5F8, 32
}Then we have the definition for DSB0:
- Notice that field unit entries begin with D0 for DSB0 (Downstream Bridge)
- Again, some of these field unit entries are command registers and others are status registers
- MMTC returns base address of Downstream Bridge
C:
Local1 = MMTC ()
OperationRegion (D0FG, SystemMemory, Local1, 0x0600)
Field (D0FG, ByteAcc, NoLock, Preserve)
{
Offset (0x04),
D004, 8,
Offset (0x0C),
D00C, 8,
Offset (0x18),
D018, 8,
D019, 8,
D01A, 8,
Offset (0x1C),
D01C, 8,
D01D, 8,
Offset (0x20),
D020, 16,
D022, 16,
D024, 16,
D026, 16,
D028, 32,
D02C, 32,
Offset (0x50),
D050, 8,
Offset (0x5F8),
D5F8, 32
}- Notice that field unit entries begin with D1 for DSB1
- DSB2 and DSB4 are defined next and look similar to this
- Local1 is the base address of DSB0 (above), and (Local1 + 0x8000) is the base address of DSB1
C:
Local2 = (Local1 + 0x8000)
OperationRegion (D1FG, SystemMemory, Local2, 0x0600)
Field (D1FG, ByteAcc, NoLock, Preserve)
{
Offset (0x04),
D104, 8,
Offset (0x0C),
D10C, 8,
Offset (0x18),
D118, 8,
D119, 8,
D11A, 8,
Offset (0x1C),
D11C, 8,
D11D, 8,
Offset (0x20),
D120, 16,
D122, 16,
D124, 16,
D126, 16,
D128, 32,
D12C, 32,
Offset (0x50),
D150, 8,
Offset (0x5F8),
E5F8, 32
}- Field unit names start with GP
- Method MMTA returns base address of root port
C:
Local1 = \_GPE.MMTA ()
OperationRegion (GPFG, SystemMemory, Local1, 0x30)
Field (GPFG, ByteAcc, NoLock, Preserve)
{
Offset (0x04),
GP04, 8,
Offset (0x0C),
GP0C, 8,
Offset (0x18),
GP18, 8,
GP19, 8,
GP1A, 8,
Offset (0x1C),
GP1C, 8,
GP1D, 8,
Offset (0x20),
GP20, 16,
GP22, 16,
GP24, 16,
GP26, 16,
GP28, 32,
GP2C, 32
}- The prefix HS could mean Host
C:
OperationRegion (HSFG, SystemMemory, Local6, 0x30)
Field (HSFG, ByteAcc, NoLock, Preserve)
{
Offset (0x04),
HS04, 8,
Offset (0x0C),
HS0C, 8,
Offset (0x10),
HS10, 32,
HS14, 32
}- Method XL11 looks like the hot plug event handler
- Method XL11 calls Method EE1B
- Method EE1B calls Method GNIS to determine if the Thunderbolt controller is already configured, otherwise it calls Method TBFF to set it up
Last edited:
What are you using to test Thunderbolt?
are you using the Hero motherboard or the Creator? (or both, like me?)
