iGPU
Moderators-
Posts
573 -
Joined
-
Last visited
-
Days Won
17
Content Type
Profiles
Forums
Events
Downloads
Everything posted by iGPU
-
You hardly need to buy anything to test. Just looking at Hackintool will tell you if the USB ports are active. Marking up meina222's image above (low res so not much detail) as compared to our MSI. When TB-USB is working, the top section, which shows the available USB devices is same for both mobos. The bottom section, which are the active ports, is populated on the GB mobo by TB USB (XHC5), but is empty on our MSI mobos. The GB mobo properly shows the ports as TypeC+Sw, which are the high speed USB3/C ports. So the SSDT is properly injecting both TB and USB properties on the GB mobo. The 33 firmware is just fine; don't change it. We need to study the meina222's GB DDST file to determine what is different from our MSI DDST file with respect to power for USB. GB mobo: MSI mobo:
- 145 replies
-
- 1
-
Some users have reported that TB header not needed. USB-2 connection and the power connections are optional (the latter for supplying charging, so maybe connecting iPhone not a good idea as it will require over 1A). A better thing to connect to test is a USB-C SSD. In reading your posts, it said you initially flashed NVM23 and implied you flashed NVM33 over that. I've used NVM33 for Titan Ridge cards. I don't think from tests (I've been involved with CaseySJ's work since he started), that 23 or 33 will adversely affect USB function. In looking over your DSDT file, it is very similar to the MSI DSDT. I've not yet located anything in it that would suggest a more robust USB response to our SSDTs.
- 145 replies
-
I think it's because GB Designare is made to support TB. I think it has to do with power being injected, which is an area I've been studying. It might be possible using a custom DSDT.
- 145 replies
-
Hey, this is NOT fair!! You've got USB-C activated!! If you now load up Hackintool, you'll see XHC5 (I re-named it so that it will be distinguished from other XHCx devices).
- 145 replies
-
Really? I thought the range is contiguous, so that min 17.00 and max 20.99 would be as fabiosun said (HS, Mojave, Catalina and Big Sur). The only way to isolate a patch is to duplicate. Example, this will exclude Catalina, and only be active for HS, Mojave and Big Sur (if both enabled): one patch set to: : min 17.00, max 18.99 duplicate patch set: min 20.00, max 20.99.
- 3,970 replies
-
- 1
-
- amd vanilla patches
- amd kernel patches
- (and 3 more)
-
I see the error and didn't notice first time when reviewing your SSDT: you have typos. Replace the "O" (ohs) with "0" (zeros). Notice how D0CA is correct: zeros have a slash through the symbol; the capital letter "O" does not. So SOD2 --> S0D2. (This seems to be an American problem: people here say for 405: "four-oh-five", instead of saying "four-zero-five". I believe that this leads to such typos.)
- 145 replies
-
- 1
-
I'll look this over.
- 145 replies
-
FYI. I have worked for hours trying to sort out why I could not get Shutdown to properly work. I won't even list all of the things I investigated (but they involved BIOS, ACPI, kexts, DevProp, MMIO and other OC settings). Shutdown would work perhaps 1/10 times; just enough to tease and lead me in one direction and then another. I finally found the source of the problem. It was my keyboard (here). It was triggering the panic reboots. Once the keyboard was removed, Shutdown began working well (Sleep is also working). Bottom line: remember to check hardware issues when things aren't working as expected.
- 3,970 replies
-
- 4
-
- amd vanilla patches
- amd kernel patches
- (and 3 more)
-
Try this one and let me know what happens. As I've said, USB does not presently work on this build. I'm in contact with people (such as CaseySJ) and it will take time. In the meantime, the TB functionality is excellent and this is the main point of the TB card. (After all, we do have many USB ports on the main mobo, so we're not exactly suffering from USB shortages.) SSDT-TBOLT3-v3.aml.zip
- 145 replies
-
- 1
-
You are correct on this point: C15 VM test was in Mojave, not BS. But with tests other than C15 (which I often do not run), I've seen no difference amongst Mojave, Catalina or Big Sur. The small variations I've seen on-line, I believe, are simply statistical variations due to uncontrolled testing situations. Example: on my computers, 've seen variations in test results with how long the computer has been turned on, what background apps were running, and if the computer was left un-touched during tests. This says nothing of BIOS settings, DDR4 speeds, mobo variations, etc. So unless a standardized approach is taken (which is not practical) most results are probably not significantly different even in a range of ±5%.
- 3,970 replies
-
- amd vanilla patches
- amd kernel patches
- (and 3 more)
-
Yes, what I presented above is BS ß6 (public release 2), released this past week. I've seen no difference from BS ß2 thru ß6.
- 3,970 replies
-
- amd vanilla patches
- amd kernel patches
- (and 3 more)
-
Here are C15 results for both bare metal and VM on AMD. Both are lower than Intel side. Based on what I'm seeing, I don't think C15 uses both Radeon VIIs. Meanwhile, MarkLux does, as the scores below are consistent with Intel side where I have one Radeon VII on that system and it gets 54,000 on LuxMark. Also, LuxMark gives same scores for dual Radeon VII in VM and bare metal. Big Sur ß6 bare metal, dual Radeon VII (XMP was on, 4G enabled and only 13 kernel patches--sourced from Pavo) : C15 Test using Proxmox VM, dual Radeon VII (Mojave): SMBIOS Comparison (LuxMark): dual Radeon VII, BS ß5 (iMacPro1,1 vs MacPro7,1):
- 3,970 replies
-
- 1
-
- amd vanilla patches
- amd kernel patches
- (and 3 more)
-
I've re-installed a Firewire card and ordered an RME Fireface 800 off eBay. In reading about the RME 800, some touted how no extra RME drivers were needed for macOS, which means using the "class compliant mode". With the RME 800, when using Firewire, you either have to use this mode, or the "stand-alone" mode (and this mode is required for Total Mix). My question is how does the "stand-alone" mode (requiring RME drivers) compare with the "class compliant mode"?
- 3,970 replies
-
- amd vanilla patches
- amd kernel patches
- (and 3 more)
-
I've been using an Audient EVO 4 from the start on VM and now, bare metal. Periodically, there is audio dropout which seems to be helped by disabling Wifi (BT stays enabled).
- 3,970 replies
-
- 1
-
- amd vanilla patches
- amd kernel patches
- (and 3 more)
-
I had same issue. Turn off csr-active-config blocking (use 00000000) and this should work with previous EFI.
- 3,970 replies
-
- 1
-
- amd vanilla patches
- amd kernel patches
- (and 3 more)
-
Pavo, agreed. At least with the MSI mobo, there is no difference in HPET with or without DummyPowerManagement. Either setting gives this result: On a peripheral note, if the highlighted contents of the Spoiler is added to NVRAM, SBRG is populated as shown below, otherwise nothing is attached to SBRG. This was used on the X570 build (modified NVRAM SSDT is attached). SSDT-TRX40-NVRAM.aml.zip
- 3,970 replies
-
- amd vanilla patches
- amd kernel patches
- (and 3 more)
-
fabiosun, I was reading on some thread (forget which one, prob InsanelyMac) that to get proper SIP, one needs to first have native NVRAM working (which we do), then delete the csr-active-config entry in OC. Only then will the SIP set in Recovery maintain over a boot. Otherwise, the values set in csr-active-config will over-write Recovery SIP. I've not tried this.
- 3,970 replies
-
- amd vanilla patches
- amd kernel patches
- (and 3 more)
-
Mine were shifted and looks like your set up (here). This suggests that the PCIe make up of our builds does not influence the MMio list (aside from multiple GPUs when 4G is enabled). (Pavo and I have identical builds with same GPU, but he is using one and I two.)
- 3,970 replies
-
- amd vanilla patches
- amd kernel patches
- (and 3 more)
-
In my original work, in the 0x10400 range, I had to enable the last one, and disable those above it, in order to boot. When I did that, I mostly was getting shutdown in Big Sur (but not Catalina).
- 3,970 replies
-
- amd vanilla patches
- amd kernel patches
- (and 3 more)
-
Pavo, Just to be clear, from my post that you reference, you are only enabling in MmioWhitelist, the values in red? That is, you are not including the top 4 that are green (or the top 2 in your list)? And if true, then all of the TRX40 mobos will use the same list regardless of Above 4G settings, and have proper functioning shutdown, etc.
- 3,970 replies
-
- 1
-
- amd vanilla patches
- amd kernel patches
- (and 3 more)
-
When I enable 4G, all match Driftwood's who also has 4G enabled. They only differ in the bottom 4, which according to vit9696 are un-important. And we both have dual Radeon VIIs in slots 1 & 3. 0xCB100000 0xD7180000 0xE3180000 0xE3300000 0xEF100000 0xFEA00000 0xFEC00000 0xFEC10000 0xFED00000 0xFED40000 0xFED80000 0xFEDC2000 0xFEDD4000 0xFEE00000 0xFF000000 0x4040000000 0x6F70000000 0x9EA0000000 0xCDD0000000
- 3,970 replies
-
- 1
-
- amd vanilla patches
- amd kernel patches
- (and 3 more)
-
I've stuck with iMacPro1,1. When I did a battery of tests in each system, there was no difference with the two Radeon VIIs or the CPU in either. So I kept on iMacPro1,1. Apple may target some of their software to perform differently on newer machines, but I think for the vast majority of things, it won't matter. It probably means nothing, and I don't know what Apple tracks, but I figure the older SMBIOS will more likely fly under the Apple radar than newer machines that may not be selling in the same volume as the older ones.
- 3,970 replies
-
- 1
-
- amd vanilla patches
- amd kernel patches
- (and 3 more)
-
Thanks! v034 is the latest one that works with Big Sur: here Use this kext and this app (the latest app v064 won't work with the older kext).
- 3,970 replies
-
- 1
-
- amd vanilla patches
- amd kernel patches
- (and 3 more)
-
There were a few posts above discussing built in audio and the AppleALC kext. I took a different approach to examine the issue, not by listening, but from looking at loaded drivers (in Big Sur). What happens to the audio drivers when AppleALC is disabled: the Audio Control drivers are not loaded. This is shown in the first image below. Also shown is a parallel example of a driver not loading for BT/Wifi. I disabled the BT/Wifi kexts (which were included in the EFI's that I uploaded). (I'm using a swapped macOS compatible card.) If these BT/Wifi kexts are disabled, the BCM4352 drivers are not loaded and there is no BT (top image). If they're enabled, the driver is loaded and BT is working (bottom image). Now the only reason you can even see what's happening in this PCI section is because I've entered many devices into OC/DeviceProperties section (which I did not upload in previous EFIs). See the Spoiler below for the Audio example. A few of the PCI entries are also supplied by SSDT files. DeviceProperties Example: I realize that many don't like using SSDT and DeviceProperties, but if these are not used, you'll miss out on some interesting information. This information is normally seen in Macs and if not entered into OpenCore, it won't be seen in our Hackintoshes. So what really is more Vanilla? A more significant example applies to Thunderbolt. If there is not a proper SSDT, no drivers are loaded and you'll get no Thunderbolt functionality. The first image is SystemInfo/PCI when the AppleALC and BT kexts are disabled: Now, AppleALC and BT kexts are enabled:
- 3,970 replies
-
- 2
-
- amd vanilla patches
- amd kernel patches
- (and 3 more)
-
Thanks for feedback. Originally, I had 4G and CSM disabled, but only tried as fabiosun was discussing. I'm don't know if I see advantage one way or the other. And for disabling LAN wake-up, we don't seem to have this option on the MSI Creator. (I usually keep disabled on Intel Hackintoshes.)
- 3,970 replies
-
- amd vanilla patches
- amd kernel patches
- (and 3 more)