iGPU
-
Posts
573 -
Joined
-
Last visited
-
Days Won
17
Content Type
Profiles
Forums
Events
Downloads
Everything posted by iGPU
-
Don't worry about " my CPU is displayed as an i5 3.7GHz -" it's only cosmetic. As for Hackintool, I was referring to the address/path: "PciRoot(0x1)/Pci(0x10,0x1)/Pci(0x0,0x0)" (not the id "BA430000"). You can find in Hackintool. Export, then copy from txt file and paste in place of what I'd uploaded earlier.
-
I've not had any issues with BT/Wifi and Big Sur, and have not had to resort to using Terminal commands to get it working. Some people have had problems with Big Sur and AirportBrcmFixup.kext. The attached fix has help some of them. You might try adding this for DeviceProperties (changing the address based on your Hackintool results for the Broadcom card in your mobo: Also, just to clarify, I use the following kexts for BT/WiFi (AirPortBrcmNIC_Injector is in a plug-in folder inside AirportBrcmFixup):
-
I think fabiosun is referring to your EFI partition. The EFI partition should contain an EFI folder, inside of which are BOOT and OC folders. Occasionally, you'll also find an Apple folder along with those two folders inside the EFI folder. You can delete the Apple folder if present. But until you boot in macOS, you can't adjust the EFI folder. You should change "cores: 24" to "cores: 48", leaving "socket: 1". And set the memory to "memory: 32768" (that will show up as 32GB on the Mac side; the memory intervals I use are 32768 / 65536 / 131072).
-
Usually when I've seen this, it's OpenCore settings. If the config.plist file is corrupted or inconsistent parts from different builds (such as OpenCore.efi and BOOTx64.efi not from same commit) or settings within OC are off or a problem with the VM. For the first, I only use PlistEdit Pro (I've created corrupted config files using OpenCore Configurator; I avoid it except for using as a tool to update SMBIOS data). The second problem is fixed by running Pavo's OpenCore Builder and using the latest v060 (or v061) commit to have a uniform build. The third issue varies a bit with mobo, but most TRX40 are pretty similar. Shown in Spoiler are the basic settings I'm using. You also need to ensure that you have the correct Kernel Patches enabled. Finally, make sure you have a proper 'args' setting in your VM. If you do a sloppy cut and paste, you can find that maybe only a partial 'args' statement was actually pasted (I've made this error).
-
If anyone is having issues seeing the latest Big Sur beta update, see this page for instructions how to manually download (which reference and give instructions for this corpnewt page).
-
So far, the 5.8 kernel seems stable on my set up. I've now left computer running for 24 hours with a couple of re-boots (to test the BT "SSDT-NoAX200" discussed above): no problems. I'm still on BS ß2 as ß3 was unstable for me. (I may install ß4 on another drive this weekend; work keeps getting in the way. 😉)
-
Do you have another Hackintosh to verify that the card works? Based on what I'm seeing, the PCIe holder is probably ok, but perhaps the actual Broadcom PCB is bad. I've read about bad Broadcom PCBs on other threads. You could try adding this code to DeviceProperties in OpenCore (changing first line to the address you find in Hackintool): Finally, did you try adding brcmfx-driver=2 to OpenCore boot argument? It might help.
-
Usually BT is the trickier of the two to get working. What may be happening is related to a pci-bridge problem like the TB AIC that isn't allowing the WiFi portion to work (or maybe you have interference from the built-in WiFi)? Can you show us the results of lspci -nnk ? While it may not have a major effect, I would comment out all blacklisted entries (then run update-initramfs -u -k all and reboot). I'd also remove/disable some of the kext files: Finally, what are your entries for System Info / Network?
-
I removed shrouds on TRX40 Designare and MSI mobos, but I did before assembly: not difficult, just a few screws. Once mobo is inside a case, it's a lot more work. If you only want to disable BT, you can cut the power to the AX200. In fact, when I was using special kexts (early in this thread), I had to specifically pass USB power to get the AX200 working (that earlier post references the TRX40 Designare mobo if you look it up). BT from the AX200 worked really well; I think it had greater range than the macOS compatible pcb. But at the time there was no WiFi; I think the hackers have got that working now (but I haven't kept up with their progress). On my current MSI mobo, the USB power is 0489:e07a, which comes from 48.00,3. When I look inside IORegistryExplorer, the swapped BT/Wifi card is appearing under AMD Matisse USB 3 (149c) at address 10,5. (On the Intel side, native BT/Wifi cards are inactivated with SSDT files; this might be another approach.) *** UPDATE I worked on an SSDT that will inactive BT/WiFi. You just have to determine the device address using IORegistryExplorer (IORE) and adjust the address inside the SSDT. Simple. To use, complete the address check described below and adjust the address inside the file SSDT-NoAX200.aml, enable the file in OpenCore and reboot. (To restore function: disable the SSDT in OpenCore and reboot.) First the normal IORE. Locate the address where you find the BT/WiFi card under a USB device. (I've used another SSDT to rename addresses to RP0x.) Next, adjust the SSDT so that its address matches your address in IORE from above step: Now to show how it works... the above device @10,5 gets collapsed. Normal: Inactivated: no BT. Hackintool, normal: Hackintool after inactivation (the actual BT/WiFi card still shows up; but has no power): Hackintool after inactivation (BT entry is gone): SSDT-NoAX200.aml.zip
-
I've had same issue many times with Proxmox and even on their forum, they could not help. Solution is never blacklist GPU, otherwise command line disappears from host monitor and if any thing goes wrong with GUI, the only solution is to re-install Proxmox (which I've had to do so many times, I've lost count...). I've had GUI disappear after simply changing the Proxmox NVMe drive to a different slot. For ethernet, I leave one port (Aquantia) for host and the other I transfer to macOS. I don't VM any other ethernet ports. To manually adjust the ethernet, I ran "nano /etc/network/interfaces" and entered the following code (and after changing, ran the command: /etc/init.d/networking restart): As for BT/Wifi, I never got a PCIe card to work. I eventually swapped out the built-in card for macOS compatible card.
-
If you're adding GPU functions via the SSDT or DeviceProperties, you could adversely impact GPU function. I have some mods for Vega 56 and Vega 64 that I can share, but I'm not familiar with Vega FE. MCEReporterDisabler was supposedly needed for booting Catalina, but doesn't seem to be necessary for our VM approach. The memory warning is a problem when using SMBIOS of MacPro7,1. I think safer to use iMacPro1,1 SMBIOS. I'll look over TB files later tonight after work. I don't think writing custom SSDT for our build will be a problem and I'll happily share it here. The problem that I addressed in this post and others is passing through the complete device (esp the pci-bridge sections of the TB). This is also a problem with other 'bridged' devices (USB and FireWire cards for example), which I've previously posted. *** BTW, I just did the 5.8 kernel update and the TB device still splits into 2 parts without passing through the pci-bridge sections (although I did not specifically try and pass them through; normally passing those parts gives and VM error, preventing the VM from running). I'll test more later.
-
I also updated the Proxmox system using "pve-edge-kernel-5.8" folder. When running uname -r, I got the same result as fabiosun. System seems to have booted into Big Sur just fine. 😁 (I downgraded to ß2 several days ago and ß3 was not stable to me.)
-
DTGP is a routine often called by other SSDTs. On the X299 platform, many SSDTs developed by KGP, call this method. The only dependencies I have in my list that call DTGP is the TB-SSDT, which no one is actually yet using. So the DTGP SSDT can be disabled or removed or the DTGP method could be placed in the TB-SSDT if this is the only SSDT calling it. Snippet of TB-SSDT showing a DTGP call: As for kexts, I do not enable VirtualSMC, WEG or MCEReporterDisabler. And use: Cpuid1Mask = FFFFFFFF 00000000 00000000 00000000 with these Patches enabled: algrey - cpu_topology_sort -disable _x86_validate_topology algrey - cpuid_set_generic_info - disable check to allow leaf7 I do use other SSDTs, but basically only for cosmetic issues in IORegistryExplorer (my OCD). The SSDTs, which on other builds are important (and that I use, but have not tested as to their importance on TRX40 build) are: SSDT-PLUG and SSDT-EC-USBX.
-
fabiosun, thanks for sharing. Here are your two trees. I've condensed and re-structured the trees for better clarity. Note how the TB items (NHI at 0x15eb and USB at 0x15ec) fall under the SF0 device, but in parallel with other devices, such as USB Audio and SATA drives. This is not good: SFO is not a good attachment site for TB (but we seem to have no control over this). And, as I've mentioned previously, I've never gotten an SSDT to re-name or inject properties into any device contained within SF0. fabiosun's v23 (left) and v50 (right): Below is a detail from v23 to better describe what we're seeing. While the NHI and USB devices are present, the associated pci-bridges are not. Obviously missing is the essential UPSB, the pci-bridge that contains all of the TB nodes. This is the same problem I described months ago. Until we can get the entire PCI device passed-through, we cannot get functionality from that PCI device. This holds true for USB, BT/Wifi, FireWire and TB PCI devices. This is a Linux problem. So while you're seeing portions of the TB tree, it is not cohesive and most likely will not function (in this latter aspect, I hope I am wrong). fabiosun's v23 (detail): *** Shown for more clarity (below) is the TB tree I see on my GB Z390 Aorus Xtreme Waterforce mobo, where I flashed the chip on the mobo. To review, DSB0 is the main TB device, NHI and its associated ports. DSB1 and DSB4 are for attached external devices connected to the TB AIC, such as external TB drives, TB hubs or TB audio devices. DSB2 is for USB devices; here you'll see USB-C attached devices. In the image below, DSB4 is expanded (as compared to DSB1, which is not expanded) since there is a TB drive ("OWC Aura P12 2TB") connected to it. This drive has several partitions, two of which are mounted ("MBA-500" and "ExtStorage"). Note how all TB branches fall under UPSB (DSB0-DSB4). The UPSB node (bridge) is missing on the above 'mini-trees'. UPSB in turn falls under the main device, here labelled RP01 (RP01 is equivalent to SF0). UPSB is a critical pci-bridge that is not being passed. DSB1 and DSB4 are also not present in the above 'mini-trees', and so no external TB devices or hub can connect to the TB AIC. Proper TB tree GB Z390 Aorus Xtreme Waterforce build:
-
I too use on X299. Writing SSDT is not the hard part. fabiosun, I'd like to see more complete IORegistryExporer TB tree of your best firmware flash (I think your best is #2, TitanRidgeNVM23-Elias64Fr-Mod.bin ?). In my previous flashing, this has been the best firmware to date for TR TB3 cards. Do not enter a search criteria in order to see whole tree, but do click on triangles to collapse the tree at major nodes. This will allow the screen shot can show details of whole tree. The other option is to simply upload the IORegistryExplorer file so I can study. Thanks.
-
If jumper on AIC is placed, then TB AIC can usually be used on mobo without TB header, but you need to flash firmware for macOS. These steps are never condoned, nor discussed, by manufacturers.
-
@fabiosun I got ahold of an unflashed ASUS TR AIC. I placed this native card in slot 2 and added SSDT for a re-boot test. This card, like the Alpine Ridge, splits into the same two sections for NHI and USB. The NHI device (0x15eb) is located at pci,bridge10,7; the TB USB device (0x15ec) is located at S88@11 (not shown). It's not clear why on this MSI Creator mobo, it shows up split, while on your MSI mobo, fabiosun, it does not. Curious. (I will flash the card later this week and re-test.) The location of the NHI device was at pci,bridge10,7; an SSDT injected here using this code snippet: becomes this entry in IORegistryExplorer (but is non-functional): And, when looking at the PCI section of SystemInfo below, the SSDT file injected "Slot-2" for the NHI section. The remainder of the SSDT injected descriptions, such as "Titan Ridge Thunderbolt Controller", do not appear because there is no proper TB tree. Not surprisingly, no driver is working. Meanwhile, both the NHI and USB sections, in the PCI pane below, have entries that say "JHL6540". This is a purposeful error to 'tag' NHI and USB from another direction. Devices can be labelled from either SSDT files or from the DeviceProperties section inside the config.plist file. Here, labels from Alpine Ridge were used, so as to know that the label was from DeviceProperties and not the SSDT. The USB device, while it does have a driver, nevertheless shows up under the SystemInfo/USB pane. Unfortunately, there is no USB function. *** @meina222 I originally had a GB TRX40 Designare but ended up returning it for faults (which in retrospect was probably due to a bad CPU). Anyhow, my earlier TB experiments were unsuccessful on that mobo too, despite it being designed for TB with a proper header and BIOS entries for TB.
-
Why I ask is that I do not see any built-in ALC1220 device despite using AppleALC kext, and I was wondering what I'm missing. In my /usr/share/qemu-server/pve-q35-4.0.cfg file, only the following are active (the rest were commented out): These items were commented out:
-
I did as you showed and got the exact results you show here. Thanks!
-
Can you show your "/usr/share/qemu-server/pve-q35-4.0.cfg" file? I'd like to compare with mine. Thanks.
-
Yes, I saw, but I still don't understand how to patch linux and re-compile it.
-
I'm not on zen2. I don't know how to change to zen2 settings. (If this zen2 is from a patch; I don't know how to patch things.) I ran "apt update" and "apt dist-upgrade", and that led to the latest update shown in Spoiler below. Command: "pveversion -v"
-
If the mobo does not have a TB header, you must jumper 2 pins on the TB AIC for proper power. (I can supply photos or links on how to do this, if you'd like.) But since you have good appearance on IORegistryExplorer, I would not change whatever you've done to your AIC. Mobos that have header also have BIOS settings for TB, so this is ideal. However, even without headers and BIOS support, TB function is seen with flashed firmware. As for the USB2 connector on TB AIC, this is not necessary for TB function. When connected, it is to provide more power for charging devices connected to TB ports. So this connection can be ignored. *** I must make a correction for above post showing the attachment on my MSI mobo of TB at SF0. It is not; it was late and I was not carefully studying IORegistryExplorer. On review this morning, I found the NHI section (15d2 on AR) is attaching at 10,7 and the USB section (15d4 on AR) is attaching at S88. So these are not grouped together and cannot be treated with an SSDT (and certainly explains why the SSDTs I tried for SF0 didn't work). I will move the AR AIC from slot 4 to slot 2 and see if this will group the TB device differently (the water cooled GPUs only take up 1 slot, so room next to slot 1). Moving to slot 2 didn't help; it gave the exact same results with NHI and USB being split over 2 locations as shown below.
-
Once you flash a TB card, it won't work in Windows.
-
I don't have a free Titan Ridge card to test, but I do have an available, flashed Alpine Ridge TB3 card. Placing it in slot 4 (farthest from CPU), gives an entry in to SF0, but very incomplete. I provided an SSDT which loaded (see other image), but it did not affect the AR card. I'll try some variations of the SSDT file. Pathetic TB tree and how it should be labelled with SSDT (but SF0 should be a device like RP21, not UPSB): Display loaded ACPIs (command: log show --last boot | grep ACPI )
