Jump to content

iGPU

Moderators
  • Posts

    573
  • Joined

  • Last visited

  • Days Won

    17

Everything posted by iGPU

  1. To get a listing (and then download), the latest macOS installer, enter the following into Terminal. As of today, BS 11.4ß is listed as option 13 and is 11.5G in size. (The listing will show you the latest for High Sierra thru Big Sur.) curl -O https://raw.githubusercontent.com/munki/macadmin-scripts/main/installinstallmacos.py && sudo /usr/bin/python installinstallmacos.py --raw --seedprogram DeveloperSeed The download will be listed for BS 11.4ß as "/Install_macOS_11.4-20F5046g.sparseimage" under your boot drive's name/Users/<user name>/Install_macOS_11.4-20F5046g.sparseimage. For example, as "Macintosh HD/Users/<myUserName>/Install_macOS_11.4-20F5046g.sparseimage". Double-click on this *.sparseimage file and open the Application folder. There, you'll find the "Install macOS Big Sur Beta.app", which you can run as usual (maybe you will want to move it to your actual Application folder first). This file is 12.43G.
  2. @valmeida, You've listed an "AMD Series VII"; I'm assuming this means a Radeon VII, same as I'm using. The 5700 and VIIs have had issues with WEG, even on the Intel side of things. Such problems led me to add a boot argument: "-wegbeta". Try adding this to your "boot-args" section to see if this stops the freezes. Another test is simply to disable WEG and see if this stops the freezes.
  3. I haven't seen exactly this issue, but did have freezing with some GPUs and WEG. You might try the following (keep a backup of your current config.plist file): 1. Comment out both DeviceProperties/Add (use "#" in front of each entry). 2. Delete the entire "Memory" item under PlatformInfo (it's not needed). 3. Add "-wegbeta" to boot-args section (I only use: keepsyms=1 -wegbeta) 4. Comment out your Kexts/Add section to save it and use the one I edited from your config file. I don't declare any USB port kexts; it really isn't needed for the TRX40 mobo, and I disabled the AMDRyzen kexts which may be interfering, and removed some extra BT kexts. Hope this helps. kexts-add.plist.zip
  4. I've found that updates don't install properly unless car-active-config is set to 00000000 as shown below. After changing, you must re-boot, then re-try the OS update. (I keep a set of alternative settings inactivated with a "#" symbol shown as the top of this section.)
  5. You need to fix bad config file. The error file tells you where the mistakes are located. (I don't use Bootstrap as it messes with BIOS.) Study OC docs and every line of the sample plist file, as I do. Both usually change with each incremental update. This is the only way you'll learn how to use OC, rather than waiting for someone to hand you the fix.
  6. Earlier in this thread, there was some issues with log-in screen being changed after a Big Sur update. This post describes how to fix that issue. First, a written description and then some images that try to illustrate the words. Attached is a folder containing a Big Sur log-in image; download it and then you must change the UUID to be specific for your system. Description: 1) Open System Preferences. 2) Select "Users & Groups" --> unlock the padlock --> right click on user --> select 'Advanced' --> copy user UUID from next screen and cancel out of dialog box. 3) Place downloaded folder (Desktop Pictures/UUID/lockscreen.png) into /Library/Caches/ 4) Replace folder UUID ("my-UUID") with your UUID copied in step 2. 5) Assign proper writing permission to that folder, using "Get Info", making it Read & Write. 6) After re-booting, you'll now see the BS log-in screen rather than the multi-colored screen (or you can use another image; just re-name as "lock screen.png"). Get your UUID: Copy your UUID: Place folder and re-name UUID: Desktop Pictures.zip
  7. At this late date, why the issue over these Quirks? None of those are necessary. (This is where newbies muddy the waters for no good reason.) This works and has not changed for months:
  8. Updated without issue. My sequence was BS ß9 to 11.01 a few days ago, and then today to 11.01 RC (I skipped ß10). I use the latest OC compile (release v064; now 6a81462) run daily with, of course, the latest, correct, config settings. Kexts are always latest versions.
  9. Delete the red square entry and your error pos 17 msg will be gone. No longer needed after v062.
  10. Hi all. I got COVID two weeks ago. I self-treated at home and did well until this past weekend when the "cytokine storm" hit me (I was too conservative with steroid use). A 3-day hospital admission tuned me up and excluded some really serious stuff that I fortunately did not have (DVT/PE). I left hospital today; now back at home and reading this thread on my laptop with supplemental oxygen (and lots of steroids and blood thinners). BTW, I sero-converted, meaning I now have antibodies to COVID. This means I now have natural immunity with no need for a vaccine. (The idea of herd immunity is to either naturally develop antibodies from COVID directly, or, develop antibodies by receiving a vaccine.) Hopefully this week I'll get to use the TRX40 again. (Actually, it's been on for past 2 weeks as I was editing a video-documentary on it when I got sick and was unable to easily turn it off. Very stable machine!)
  11. @fojerhar is correct, we would have really cluttered the thread last weekend. It took many emails and various file exchanges to solve. Once in the correct slots (when we trouble-shoot, we rarely think to try a single GPU in anything other than slot 1), and with an adjusted DSDT, the Firewire card now works well.
  12. Yes, disabling these 4 patches, still allows booting into Big Sur ß6 and ß9 (I have no ß7 or 8 to test), as well as Catalina.
  13. I initially tried booting TRX40 with Clover (both VM and bare metal) and had no success. OpenCore works so well, I don't see why to use Clover any longer (except for nostalgia). A couple of weeks ago, I spent time converting other builds (X299 and Z390) completely over to latest OpenCore from Clover. I only go forward with OpenCore.
  14. I would concentrate on getting the Firewire drive to mount in macOS (before working on the UAD device). Have you tested booting into macOS with the Firewire drive already connected before turning on computer?
  15. I've spent some time trying to investigate our BIOS for Thunderbolt locations. For the MSI TRX40 Creator, using a combination of UEFITool and ifrextract, I could localize Thunderbolt sites and extract a text file. Locate sites: Extract bin file: The resulting text file (extraction from above "THUNDRBOLT" search): If this file is searched for "THUNDERBOLT", excerpted and re-arranged, the following is seen (included are proposed actions for each site, such as 0x0 to turn off or 0x1 to turn on; some are values for size): Next, using this data and running a special modified GRUB in an EFI, one should be able to check out these sites and adjust. (I used this tool to modify CFG Lock on Intel BIOS, so it does work.) However, this is where everything fails on this TRX40 BIOS. I get an error when simply trying to verify the status of the sites in GRUB. I think everything is accurate up to using the modified GRUB tool. (As I could not load nor verify a site, I could change nothing as proposed in the above text file.) I can only assume we need a different modified GRUB. *** I also studied the BIOS from GB TRX40 Designare. This was decidedly different from the MSI TRX40 Creator, not only in address location, but also the variables. For example, it allows selection between Alpine and Titan Ridge cards. Detailed extraction from GB TRX40 Designare:
  16. Firewire is natively loaded with macOS (at least through Big Sur); there are no extra kexts to load and there is no impact by usual SMBIOS that we use (I'd recommend iMacPro1,1 as any SMBIOS with an internal GPU is not a good idea with the TRX40 build). I've used Firewire AIC on each of my builds without issue (Intel X99, Z390, X299 and AMD X570, TRX40 with macOS ranging from Mtn Lion to Big Sur). In other words, Firewire just works with macOS. Further, the OC boot loader has little influence aside from injecting properties via an SSDT or DevProp (well, if you want to boot from a Firewire device, then you must re-calculate the ScanPolicy; but you shouldn't try this until the Firewire port is actually working). Further, an inoperable Firewire device will have nothing to do with AMD or patches. As long as you're booting into macOS, your patches are fine. I think your problem is related to the type of device you're trying to connect to the Firewire port. And what exactly is/are the Firewire device(s) that you're trying to connect? (Testing with a Firewire hard drive is the most certain method to verify the Firewire connection.) To clarify so that I understand you, when you boot into Windows, you can connect a Firewire device and use it? If the Windows response is 'yes, I can connect a device to the Firewire port and it works', then it should work in macOS, but with some caveats. Again, I would suggest connecting an external Firewire hard drive to test. However, If you don't have a hard drive and you're using an audio device, it will require a software driver, supplied by the manufacturer of the audio device, to interface between macOS and the Firewire audio device. If the software driver is not present or not working, then this device will not work under macOS (despite working under Windows because the proper Windows driver was installed). This is why I'd trouble shoot with an external Firewire hard drive, not a complicated audio device. If you insist on testing with an audio device, and you're certain that the driver was installed and the Firewire device won't connect, then it must be a problem with that macOS and the manufacturer's driver. At that point, you'd need to contact the manufacturer of the audio device. If the driver cannot work with Catalina or later, you might have to revert to Mojave or an earlier macOS for compatibility.
  17. D0A1...D1B1 are devices seen in the DSDT file: I don't see such a listing of devices. When I run the same command, after running Sleep, then awakening again, I see the following (sleep was enabled for about 15 sec, which is what is shown in an excerpt of the results, below).
  18. I don't think an SSDT will help. It sounds more like a Logitech, macOS driver problem. I'd try a powered hub as a work-around; this is the one I use.
  19. I too installed ß9 bare metal, but over ß6 (I never installed ß8). Since I'd removed the Snapshot partition, it is not possible to install the partial update (only a full installer can do this). So, I booted into Recovery, re-installed ß6, then updated with the partial ß9 installer downloaded from Apple. I have 2 Big Sur drives, the other one I'm leaving at ß7 (Snapshot was removed on this drive too).
  20. I'm using the Logitech C920 without issues. I do have it and most things on my desktop connected to an USB Hub which has it's own power. Your OS (whether Mojave, Catalina or BS) should have no bearing on this issue. I don't even think your EFI should much matter on this build, esp if you're using few SSDTs. Can you plug your old C920 into the same port to verify that it works? Next, I'd look at Logitech driver issues: are there any special drivers required by Logitech for the BRIO (and did you need to uninstall old drivers for the C920)?
  21. The DeviceProperties injection is working. I would expect functionality since drivers are loaded in yours as well as mine: What does it show when you select Firewire in same SystemInfo section? Mine shown below: The above image changes to the following after a Firewire device is connected and turned on (in this case an RME Fireface 800):
  22. Your card looks like it should be fine. The one I'm using is here. I've attached an OpenCore DevProp that may help inject some function for your Firewire card (copy and paste it into your DevProp section; then reboot). You'll need to adjust the address using Hackintool as I shown below (I'm including the instructions as I don't know if you've used Hackintool before). Based on your IORE file, it looks like you're using the card in slot-3. I'm using in slot-2 (but I'm using water-cooled GPUs that expose slot-2, which would otherwise be obscured by the GPU in slot-1). I don't recall whether you tried in different slots, but if slot 2 (D0A2/D0A9) is not available, perhaps try in slot-4, repeating the instructions below to re-calculate the address for slot-4. In slot-4, it will probably appear at D2A2 in IORE. *** 1) Use Hackintool to extract PCIe data into a text file: 2) From pcidevices.txt, look for and copy the address for your Firewire card: 3) Use this data to adjust the DevProp address in OpenCore for your build (replacing the high-lighted blue section with the correct address; once done, re-boot and see if it works): DevProp-FireWire.plist.zip
×
×
  • 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.