Jump to content
You are a guest user Click to join the site

iGPU

Donator
  • Content Count

    163
  • Joined

  • Last visited

  • Days Won

    1

iGPU last won the day on June 20

iGPU had the most liked content!

Community Reputation

65 Excellent

About iGPU

  • Rank
    Senior Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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).
  2. 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).
  3. 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. 😉)
  4. 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.
  5. 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?
  6. 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
  7. 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.
  8. 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.
  9. 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.)
  10. 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.
  11. 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:
  12. 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.
  13. 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.
  14. @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.
  15. 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:
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.