Jump to content

iGPU

Moderators
 View Profile  See their activity

  • Posts

    573

  • Joined

  • Last visited

  • Days Won

    17

 Content Type 

Everything posted by iGPU

  1. iGPU
    fabiosun, 1) I could not boot with Above 4G enabled unless I also enabled CSM. Even with 4G enabled, if npc=0x2000 is present as boot-arg, it still boots. I'm not certain I see the downside of leaving npc=0x2000 present; are there problems in the log that I'm missing? 2) From reading recent posts, I don't quite understand what you're recommending for MmioWhitelist. a) Are you saying it should be the same for all TRX40 mobos? b) And that you found something different with Pavo from the list I'd originally posted for the MSI Creator? 3) Were you able to get AMDRyzenCPUPowerManagement.kext to work in Big Sur?
  2. iGPU
    TB Update. I've spent hours working on the TB USB-C issue: so far no luck. So I contacted some people way smarter than me and they've kindly included me in their PM loop as they've been working on the same issue. It seems that TB USB-C is flaky on other systems too. The main difference is that they get USB-C functionality if the device is connected before boot, but not if hot-plugged after boot. While I get no USB-C either way. Bottom line, people are working on it, but it will take some time.
  3. iGPU
    This is simply not true. My pattern is totally different. Each mobo, BIOS ver and who knows what else will be different. I wouldn't give recommendations unless you truly know by having tested it, which, of course, is impossible due to our different mobos.
  4. iGPU
    The EFI works for installation. I've installed from both USB and applications folder. Original here. But you have same EFI with extra SSDTs, so no advantage re-downloading. If you want to remove Snapshot partition see here. For removal of seal during install, see here. (Remove seal during install, then remove Snapshot.)
  5. iGPU
    Let me know how it works. I've certainly enjoyed using your software, so a pleasure if I can return a favor. If you were to read through the old posts, I initially used a calculated slide value (slide=128 as boot arg), but saw no advantage and stopped using. The MmioWhitelist, WriteFlash=Yes, and other Quirk settings are all that seem to be needed for native NVRAM on our TRX40.
  6. iGPU
    Here I whipped this up for you just now. Only need to fill-in SSN stuff. I included my SSDTs for this board, only changing the fact that you use 1 Radeon VII and I have 2. This could change some DevProp stuff I left in place as I don't know your exact NVMe set up. So please re-check those. I removed TB references since I think you're not using. (EFI deleted after download.)
  7. iGPU
    I'm not certain why you're not seeing a SATA drive. I do nothing special for SATA drives. I only use the basic EFI I've previously uploaded with some customized SSDTs. However, none of the SSDT or anything I've done to the EFI or config.plist file specifically address SATA drives. I can see the 1 of the 3 SATA drives I presently have running (there is a 4th 10TB drive I use for backup but it's a bit noisy and I only connect when backing up things). I have a Catalina back on a SATA drive as shown below. The "Untitled" drive is a Win10 NVMe drive (and Win10 is somehow corrupted and and won't boot... annoying but I dislike Windows so expect nothing less). The bottom drive is Cat-Bkup, the SATA drive (ignore the fact that it's yellow suggesting an external drive; it is not external). The other 2 SATA drives contain Linux. They're described in bottom image. All of my SATA drives appear under BYD8 (below XHC and XHCI). Since the bottom two are Linux. they don't appear on the macOS desktop (unless you add some extra software, but not worth the effort as it is risky to edit from a Mac). PAVO: Yes, I got it working several days ago. It required setting up MmWhitelist. Since you and I have same set up, I'll send you my EFI for a trial run.
  8. iGPU
    OK, I changed a few things, re-arranging SSDTs. I also commented out 2 DevProp entries. If DevProp are wrong, they'll mess up a boot; better none than wrong. (I'd need a PCI.txt output from Hackintool to verify. In fact, when I work up stuff I use that file and IORE to work on config.plist entries.) The newer SSDTs are more streamlined than what I'd uploaded earlier (now removed) in this thread (the 'renaming' SSDT is no longer required). and I disabled the Aquantia patch since it's not applicable to your mobo: I also removed un-used kext entries and swapped out the I211, replacing it with the I210 kext (IntelMausi). EFI deleted.
  9. iGPU
    This is a follow up on how to remove HS02 from XHCI. You cannot remove HS02 until you define something. The attached SSDT (8-SSDT-TRX40-BYD8-XHC-XHCI-complete.aml) defines all ports in both XHC and XHCI located at S0D2/DYB8. Again, the SSDT defines all of the ports. If you need to remove any other port, such as for BT/Wifi, be my guest. I would suggest duplicating this SSDT and not actually using it. That is, delete whatever you wish from the duplicate and re-name the modified duplicate to something like 8-SSDT-TRX40-BYD8-XHC-XHCI.aml Needless to say, only load the modified SSDT (not the *-complete version). The "8-" in the file name is because I have others SSDTs to load and like to define an order of loading. This is a holdover from Clover, which loads files based on file name; OpenCore forces you to specify the order of ACPI and Kext file loading based on file entry order in the ACPI/Add and Kernel/Add sections. So the "8-" is superfluous. Shown below is an excerpt from the attached SSDT. Only the XHCI section is shown (the XHC section extends above with only the last PR10 port revealed). Highlighted is the HS02 port that needs removing (based on my post above; your requirement may differ!). Simply delete the entire HS02 definition (or whatever other port on your system that needs removal). Re-save the file as described above and load that SSDT in OpenCore. On re-boot HS02 will no longer be displayed in IORE. Please note that this is reversible: if you add HS02 back to the SSDT and re-boot, HS02 will re-appear as these mods are non-destructive to hardware. 8-SSDT-TRX40-BYD8-XHC-XHCI-complete.aml.zip
  10. iGPU
    As I mentioned, I'm not using any Slide value. Look at post above, maybe you have a similar USB issue. On a related issue, I think all desktop Hackintoshers should disable Energy Saver as shown below. This can reduce oddball crashes and reboots in many systems (Intel or AMD).
  11. iGPU
    While working on the TB USB problem, I'd left IORE open for some time on my desktop. I noticed that. one USB device in particular had a lot of activity: something was repeatedly attaching and de-attaching to XHCI/HS02 (the spoiler below shows how it goes on and on; if left to itself, the cycle would repeat dozens of times). Now why I think this important is that I found an error when shutting down in both Catalina and Big Sur that said "Restart waiting on HS02". At the time, I didn't know which HS02 it was referring and put the idea in the back of my mind. But now seeing this failed attachment attempt and knowing that USB problems can affect sleep and shutdown I thought it worthwhile to pursue. I do not yet know if will will affect Shutdown. To see if you have such a problem, open IORE and left run for a few minutes then study the USB ports, primarily those under S0D2/BYD8 that is common to all of our TRX40 mobos. I can help you generate an SSDT should you have a similar problem: below is posted a generic SSDT (here) with instructions on how to modify it. On inspecting further down IORE, I saw that it was a problem of AppleUSBInterface trying to interact with ASMedia (ASMedia has a bit of bad reputation on the Intel side). See spoiler below showing AppleUSBXHCI (this list too went on hundreds of times, so what's shown is just a few cycles). The fix was to re-define the USB ports within the XHC-XHCI SSDT, similar to how I showed earlier to delete the BT/Wifi port (as I recall it was XHC/Prt5). After re-booting with this new SSDT, the following was seen with no more failed attachment attempts by AppleUSBInterface. Spoiler shows AppleUSBXHCI is free of AppleUSBInterface.
  12. iGPU
    Yes, I routinely copy EFI folders all over the place. I use the EFI Agent app. I never mention as I thought all Hackintoshers use it! (attached below). All of this can be done without any sealing issues. Even if on a old macOS you can still see all EFI partitions. Click on triangle to mount EFI partition (and I disallow notifications). The arrow is pointing to the triangle I'd just clicked which, after entering my pw, mounted the EFI partition at the end of the arrow. This EFI partition is for the MacHD, which contains BS and is on the Sabrent Rocket NVMe drive. Once the EFI partition has mounted, copy and paste to your delight. I add it to auto start on boot, by using the gear pop-up: You can move column (I wish a moved column would 'stick' between boots). To move, hold mouse arrow on column top for triangles and slide adjacent to Device names as shown below. This helps in locating which drive has which EFI you might want. As mentioned in a previous post, I keep a 'safety' EFI that I know will boot on one of the drives. EFI Agent.zip
  13. iGPU
    Your slide values are different than what I'd found (posted some days ago) for my MSI mobo. But, I've temporarily stopped using a slide value, but I do keep MmioWhitelist active. I've tested my list and I must a different sequence as No vs Yes than you find with your mobo, or I cannot boot. Unfortunately, we cannot share this info due to our different set-ups. Yes, I'm actively working on TB USB. I've spent hours on it, but I've not given up. I'm working on It now.
  14. iGPU
    That's a little strange. Normally, you'll only see bootstrap issues if you've set BootProtect to "Bootstrap". I don't use and set to "None". Did you change this value? In the sample plist you uploaded early it was "None" (and everyhing else looked okay). If you enable by entering "Bootstrap" instead of "None", this will place an OpenCore entry in the boot menu of your BIOS, setting it as the first entry to boot. Since I want to use different EFI's that all contain OpenCore, but different versions in case the one I'm testing is corrupt, I wouldn't know which EFI was then booting. Therefore, I keep BootProtect as "None" and select the EFI partition from which I wish to boot. (See ~ p 38 of OC Docs/Configuration/Misc/Security/BootProtect for description.) If you've still got it as "None", then I'd check your BIOS. Boot into BIOS and look at your bootable partitions. If you see an OpenCore entry, it is a holdover from whenever you'd left BootProtect as "Bootstrap". Delete or Hide this entry (or re-flash BIOS) to remove from the boot sequence. *** As for WEG, this is what I found early on: BS does not like current WEG. I left in kext folder and partially disabled to allow people to be able to boot into both BS and Catalina. I normally don't even use WEG as it does not often play nicely with Radeon VII and Navi AMD GPUs and does not seem to be very necessary for our builds which have no iGPU on the CPU. The only thing I've noticed when WEG is completely turned off (the boot arg "-wegoff" completely disables if you wish to leave in kext folder vs disabling inside config file Kernel/Add/WEG), is that you'll see pink/purple lines at top of screen. This has been a GPU artifact since mid-Mojave and WEG added some code to suppress these artifacts. Without WEG, the artifacts simply show through; they're no big deal.
  15. iGPU
    Nothing jumps out. Have you turned off most ACPI and kexts? Any changes to any Quirks? (I'm signing off for the night~)
  16. iGPU
    Is it a 3990X thing? I have no experience but do too many cores have impact on boot or install?
  17. iGPU
    WEG must be disabled to boot Big Sur. Disable one of 3 ways: by setting Kexts/Add to No, or adding -wegoff or -wegbeta to OC boot arg. I've been using -wegbeta.
  18. iGPU
    Sealed volume only important if you wish to access Big Sur drive from older macOS. I don't think if affects any other functionality. But it cannot be done at a later date, only during the installation step. I wouldn't sweat it. Removing the Snapshot partition in more interesting to me and can be done at any time. Good luck!
  19. iGPU
    So main issue is KP due to NVIDA/kexts, High Sierra (HS) or other devices. (If you've already performed the following, please excuse me as I may have loss track over the various posts.) In HS + NVIDIA, have you booted without any externally connected USB devices (noUSB; except keyboard/mouse) and no PCI cards (noPCI)? If so, does KP stop? This might show if there's an interaction with USB and NVIDIA-HS. Do you have any AMD GPU to try (like an inexpensive, used RX580)? If you do, you can test HS ± (noUSB noPCI) vs Mojave ± (noUSB noPCI) for KP. This helps to remove NVIDIA as culprit and also compares HS vs newer macOS. If you go through all of these permutations, it may systematically show whether issue is a complex interaction of macOS, NVIDIA and other devices.
  20. iGPU
    From my readings, I wouldn't be surprised if MmioWhitelist needs adjustments if one changes BIOS versions, changes BIOS settings, or changes AICs. If true, more reasons why none of us can share MMioWhitelist data unless everything is exactly the same. I don't know about getting Shutdown on Catalina. I only had it happen sporadically, while Shutdown on Big Sur is very consistent, but rather drawn out. I don't understand the fascination with MacPro7,1. The hardware similarities are greater between the iMacPro1,1 and our builds; there are less memory and PCI issues without resorting to kext kludges. (I found on the X570 builds more instability issues which users only resolved once they returned to using the iMacPro1,1 SMBIOS.) Testing on TRX40 with CPU and GPU speeds showed no difference. , But to each their own.
  21. iGPU
    fabiosun, Are you enabling "Above 4G decoding"? While researching TB issues, I came across a recommendation for a user of NVIDA card to enable it, esp with the TB card in place to avoid KP. If you do keep it enabled, the SSDT-TB will possibly need adjustment as it could shift the device location. Let me know.
  22. iGPU
    FYI As of yesterday, OpenCore has with latest commits made some notable structural changes to the config file. So unless one studies it carefully there'll be errors in the config file if one simply adds in the latest commit without adjusting the config.plist file. These changes are primarily architectural indicating strings ("Arch") being stored in the Kext section in many locations as well as adding a "Scheme" to the Kext section. #33 below is a Kext patch entry. Each Add, Block and Patch entry within the Kext section now has an "Arch" element. The choices for this string are Any, i386, x86_64. I can imagine an Apple kernel architecture being an option in the future, which is why I'm setting them all to "Any" (the only other choice for our machines would be "x86_64"). I adjusted the config file, tested last night and it's working. However, the changes presently offer nothing for the TRX40, so no need to update any EFIs.
  23. iGPU
    Yes, I tried the Titan Ridge card a couple of weeks ago. Same response: good TB behavior, no USB functionality. I know that this card works well in other builds, so the problem is now the TRX40 is interacting with the TB AIC. I tried many variations of SSDT without success in activating the USB ports. The only thing I can think to do next is look at modifying the DSDT. That's going to take me some time... I can fix your SSDT (for TB function), just show me your IORE file.
  24. iGPU
    PREVENT SEALING DURING BIG SUR INSTALLATION This is part 2 of the 'subsequent' post on preventing a Big Sur drive being 'sealed'. Presently, this step can only be done during Big Sur installation. Up until BS ß4, there was a technique for avoiding the sealing step that involved stopping the installation of Big Sur during the 3rd re-start (literally pressing the power button and shutting off the computer). However, with BS ß5, this technique reportedly does not work (I did not try it to verify). Instead, it is recommended (again by fusion71au on the InsanelyMac forum here) to use the app Hax2 (attached below), which was derived from ASentientBot's post on MacRumors. This app, along with it's associated files are to be placed on the root section of your macOS drive (ex: MacHD/User/myName/Hax2/) used to run the installation. While it reportedly can use an installer placed on a mounted USB thumb drive, I could only get Hax2 to work by placing the BS ß Installer in the applications folder where it normally is located. Prior to using, as mentioned in part 1 of this 'subsequent' post (here), you need to have the following in the OC boot arg section: -no_compat_check and amfi_get_out_of_my_way=1 as well as 77080000 for car-active-config. I also when into Recovery on the drive containing the Hax2 and ran csrutil disable and csrutil authenticated-root disable and then rebooted into the drive containing Hax2. At this point, the drive destined for the Big Sur installation should be erased using Disk Utility. Next, run Hax2 (you'll need to give permission by <Control> clicking on Hax2 and selecting Open. Hax2 will do some processing and then open the BS Installer. However, if you have not properly used the boot arguments noted above, Hax2 will give you an error window as shown in Spoiler below; select Stop, fix the boot issue in your EFI, re-boot the computer and try again. Once Hax2 is running without an error window, and after the Big Sur Installation window has opened, do not yet run the Installer. Instead, look at the Installer icon in the menu bar and make certain that it's the ß5 and not some other BS Installer you may have inadvertently left on another drive by opening it in the Finder (Spoiler below): If it's the correction version, run the Installer and select the proper destination drive. I re-ran all of this tonight and repeated the installation: At each re-boot do make certain that the booting EFI contains those same boot arguments noted above ( -no_compat_check and amfi_get_out_of_my_way=1 ) After the Installation is complete and you've finally logged into Big Sur, re-start the computer and log into the Big Sur Recovery 11.0. At this point, you'll want to run the first part of this post to remove the Snapshot partition (see a synopsis in the Spoiler below). Once the Snapshot partition was removed, re-boot back onto the desktop. When you're back on the Big Sur desktop, you can now run in Terminal: sudo mount -uw / and then diskutil info / (mentioned in the first post) and you'll see the following, showing that the Big Sur installation is not sealed: The main advantage of removing the seal is that the Big Sur drive will now be visible when the computer is booted into an older macOS. The image below was booted into Catalina and shows one Catalina drive and two Big Sur drives. One Big Sur drive has had the seal removed and is visible as "MacHD". The other Big Sur drive is only visible as "Update" since this drive is still sealed. Hax2.zip
  25. iGPU
    I'm sorry to hear about your problems, but it's not related to my uploaded EFI, but a result of whatever you did with MmioWhitelist. The process I went through for MmioWhitelist was documented earlier in this thread, but was simply a more fleshed-out version of what's on Dortania's OC guide. I didn't invent any of those things. It was tedious to go through, but uneventful for me. While it's obvious there was a problem in how you processed MmioWhitelist, as I've mentioned several times, since every mobo's MmioWhitelist is different, few of us can help you. (And this is why I didn't activate mine in the EFI, but only left as a reference.) Once you get your system back up running, I think you should stay away from using MmioWhitelist. Things will work without it. Or, if you definitely want NVRAM, use NVRAM.plist following Dortania's guilde and OC documentation. The EFI I uploaded was to help for BS Installation and debugging. I view it as a tool, not necessarily a daily driver: this is why I uploaded a basic, stripped down version without fancy SSDTs. I mentioned in the upload post, that Shutdown only seemed to be working in BS, not Catalina. All kexts and drivers were latest commits (drivers and other OC efi files must match for current commit; any substitution of a different commit dated efi file could crash a system: this is esp important for BOOTx64.efi, OpenCore.efi, and OpenRuntime.efi). A few Hackintosh caveats: 1. Hackintoshes are fun to experiment with; they can be changed unlike a real Mac; but they're not real Macs. 2. And since these are Hackintoshes, they're guaranteed not to be as stable as a real Mac. If you want reliable and stable, buy a real Mac from Apple. 3. If your system is working and you have a relatively stable machine and it's needed for your work, don't update anything (this includes BIOS, boot-loader, kexts/SSDTs, drivers, and esp a beta OS). 4. Always have a back of your main drive. (I use CCC to keep a clone of everything I work on. If something fouls up, I clone the backup to the main drive.) 5. Have back up EFI's ready for alternative access booting. 6. If things seem unstable, re-flash BIOS. BIOS can become corrupted with crashes and hard reboots. This is not uncommon on Hackintoshes (even on the Intel side). It only takes a few minutes (and if you have a saved configuration, only seconds to re-load all settings as long as the BIOS is the same version.) 7. AMD is the most unstable Hackintosh platform and the TRX40 platform the least supported of all.
×
×
  • 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.