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
    The drivers are being ported from Linux (here) with OpenIntelWireless/itlwm for Wifi drivers and ~/IntelBluetoothFirmware for BT drivers. I've been using the drivers on/off as they've progressed over the past year. BT has been working from the start with a gradual expansion of supported chips (read the site for models). Wifi has become better supported than it was a year ago and is simpler to use. I swapped out the BT/Wifi chip and so do not use these drivers on the TRX40 build. I've used them thru VM (where I made posts some months ago on this forum) and on Mojave, Catalina and Big Sur.
  2. iGPU
    Agreed: no audio from USB. But curiously, the USB Audio interface does light up as if responding to varying audio levels, but nothing is going to the speakers. Meanwhile, Firewire audio is good, but completely out of sync with the video (on YouTube for example). Earlier today, I tried the disabling of UpdateDataHub on both Z390 and X299 systems and found little improvement in speed. But I did not check audio on those systems. (I'll recheck later.) I just read Pavo's post above; this would explain the difference between AMD and Intel when disabling UpdateDataHub. Sigh... back to usual speed.
  3. iGPU
    While this change did not significantly raise the FPS, it increased CPU results by over 20%!!! 😁
  4. iGPU
    Did you get your Firewire card working? I've used many types and so far, all have worked natively in bare metal in Z390, X299 and TRX40 builds with no added kexts or DevProp. If you've added anything (such as a special kext) remove them. If still having problems, upload an IORE file.
  5. iGPU
    I ran these instructions on my clean install and had no problem removing the snapshot in Recovery. Once back in Big Sur ß7, I was then able to change files after executing the "sudo mount -uw /" command. I'm wondering if you had (have) more than one snapshot partition? Did you verify after deleting the first snapshot that none were remaining? The only time I saw the an error something like "no such file or directory", when using the (/System/Library/Filesystems/apfs.fs/Contents/Resources/apfs_systemsnapshot -v /Volumes/BigSur -r "") command, was when I made a typo in the command or file name (esp if there were a space in the name), or, if there are no snapshots to tag. So if not first problem with extra snapshot, then I would guess a typo error. EDIT: The other thing to try is before going into Recovery, add boot-arg (it can later be removed for routine BS bootin): -no_compat_check and amfi_get_out_of_my_way=1 And once in Recovery, run: nvram csr-active-config csr-active-config %7f%08%00%00
  6. iGPU
    Attached is a reduced Patch set that still boots Mojave, Catalina and Big Sur ß7 (but not HS) that I used for the speed improvements above. (It is reduced from Pavo's posting.) No Aquantia patches are present. BS-Min-Patches.plist.zip
  7. iGPU
    You can only run if you remove the Snapshot partition as I wrote about earlier in this thread here. It is possible to make a new Snapshot later, which I can write about. Today I removed the Snapshot in Recovery, did my adjustments and then made a new Snapshot in Recovery. The other option is to carry out all removal and writing of kexts inside ß7 Recovery. See details in this post, and look inside first "Reveal hidden contents".
  8. iGPU
    I reduced some patches and now have speeds about the same as ß6:
  9. iGPU
    I used full set shown by Pavo, and then as noted above, disabled the last. I saw some slight differences between the two lists: more to test tomorrow. I'd like to get the overall speed back to where it was. EDIT: Changes to old list: cpuid_set_cache_info - cpuid 0x8000001D instead 0 (31C031DB 31C931D2 0FA24189 C6000000 00000000 74) was only Catalina, now Catalina and BS. skip cpuid_cores_per_package test (833D0000 0000000F 00000000 008B00BC) was originally only Catalina, now enabled for Catalina and BS. algrey - cpuid_set_generic_info - set microcode=186 was originally only for Catalina, now enabled for HS thru BS.
  10. iGPU
    I did change config slightly. When DisableLinkeditJettison was enabled, ß7 would not boot (as it would into ß6), so I disabled and added keepsysms to boot-arg:
  11. iGPU
    Some testing under BS ß7, not as good as ß6 (several runs all with similar values shown below). With the final patch enabled (algrey - mtrr_update_action - fix PAT): With it disabled (~20% improvement, but still of of the 140 fps on ß6 and old Patches):
  12. iGPU
    I too tested. It boots Mojave, Catalina and Big Sur. Furthermore, it allowed me to download and update ß6 to ß7 in bare metal (it required 4 re-boots for update). So thanks Pavo (and algrey)!
  13. iGPU
    What you've written is important and there are 2 simple ways to go forward to keep the thread tidy, but first some prefacing. Problems will always arise as threads progress: due to new hardware, new macOS updates, changes in OC, and differences between individual builds. These problems are what threads help to resolve; a community effort to help each other. And while it's one thing to help someone who is confused or stuck with a particular problem. It's an entirely different issue if someone has no clue about OC or TRX40 issues and who does not want to expend any effort in learning how to get their system working (lazy), or, is trouble shooting a lousy EFI. The former, can be ignored. It's the latter problem that we should minimize (especially since it's obvious that people do not carefully read threads). So how can we limit problem EFIs? One way to limit lousy EFIs would be for all uploads to be cleared with fabiosun. Snippets could be uploaded, but not whole EFI folders. Only fabiosun would upload EFIs. This would allow greater consistency, but be time-consuming for fabiosun. The other approach would be to continue as is, but request that the individual who wants to upload an EFI have greater self-control. In other words, only upload EFIs if you: a) know what you're doing (truly understand the ins and outs of OpenCore), and b) are willing to support questions regarding it entirely on your own (since you claim to know what you are doing). Further, only upload EFI folders with full explanations (as fabiosun did above), describing which macOS it can boot (have you truly tested your EFI with various macOS versions or just thrown something together with no testing), what hardware it is meant for (a specific mobo or all mobos?), what are its limitations (e.g, 'no MmioWhitelist is included'), and what is unique or helpful about your EFI that warrants its posting (e.g., 'this EFI fixes such and such a problem'). Someone who uploads an EFI must have sufficient perspective to view their EFI in relation to other TRX40 systems (especially important for new-comers will also download it). If such guidelines cannot be followed, then perhaps fabiosun or a moderator can contact the poster to ask them to remove the EFI, or if necessary, the moderator can delete the post. Another suggestion would be to have the latest, or recommended EFIs, posted in a first post of this thread. (This would requires work on fabiosun's part to keep it updated). There may be even more than one EFI, such as one for installation, another for a special mobo, or perhaps one for each mobo commonly discussed in the thread. fabiosun could recruit contributions. There could be a sub-section in this first post of SSDTs, special kext files, and so forth. If there is no consistency, the thread will continually require trouble-shooting problematic EFIs, which to me is a waste of time.
  14. iGPU
    1) You've not read the thread carefully or you'd not have downloaded a config with all of the original patches. We talked about this several days ago and most of us are running only 13 patches. *** EDIT: See this post for better Patches. *** 2) your config file shows that you're using an older version of OC. You should be updated to v061 for best function. When I started using OC in early 2019, I spent days studying all the posts at the Insanelymac thread, reading the docs and looking at the sample.config plist. Now, I'd instead recommend going to the Dortania guide as the best resource to learn OC (here) and how to keep it current. Then on each update, study the Docs section, specifically, the Changelog.md and Differences.pdf files. 3) your config file is a little short on kexts. AppleALC and ethernet kext are usually a good idea on most Hackintoshes. (Do you understand that your boot-arg of "alcid=11" doesn't work if you don't load the AppleALC kext?) In the Kernel/Quirks section should disable the DummyPowerManagement; it's not needed for TRX40 (discussed before). There is also a new addition for v061, specific for Big Sur (discussed before, here). 4) The WEG/RadeonVII DP issues you describe are known to happen when WEG is disabled with Radeon VIIs (and I think 5700XT too) On the Intel side this was found to be necessary (starting with Catalina) to prevent crashes (that is, +WEG with Radeon VII led to crash), so it was rec'd to disable WEG but knowing that you'd lose some ports. ( I've discussed this several times on this and the VM thread.) On Big Sur, I run Radeon VIIs and now keep WEG enabled. My only boot-arg is "-wegbeta". 5) If you don't want the on-board wifi, I uploaded some time ago an SSDT to disable. You need a proper SSDT to re-inject SB.S0D2.D2A0.BYUP.BYD8/XHC (address 0x03) and leave out PRT5 which supplies power to the BT/Wifi device on the Desginare mobo. 6) In your MmioWhitelist, I'd recommend adding Comments, so you know at some later date what the heck you did and how to trouble shoot (as shown below). Commenting in code is always a good idea. I've already seen this section before and you copied someone else's no-comment section instead of deriving your own (a how-to was posted here). Yours: Mine: 7) The FENVI has recently on other forums been found to have various problems. The YOUBO card (here), now seems to be the preferred choice. *** TO ALL: Reading the thread carefully, at least the last 2 or 3 weeks of posts, will avoid us all having to re-address old topics for each new person who comes to work on this build. But part of the problem isn't the new-comer naively downloading files. Instead, it is the fault of posters who don't self-edit their old posts and leave tantalizing files available to new-comers. I would encourage all of us who've upload files to removed those which are no longer valid, or amend some explanation. (I did this with the Mmiowhitelist Instruction, removing an earlier upload and explaining how an easier method was developed and provided links back and forth from the old to new post.) I think if an EFI is faulty or has been superseded, it should be removed. Unless posters self-edit, old EFI's and other uploads will haunt us all, as new-comers download these old uploads, have problems, then request fixes to issues that were previously solved.
  15. iGPU
    PBO is default, I change nothing. I even have fan curves and pump very low to keep noise to a minimum. The only difference in our systems (as I don't know if you did these things) may be that I flushed out the radiators, changing out the stock fluids, and planed the heatsink (as described on the VM thread). I think, esp with high-powered, larger CPUs, all heatsinks should be planed prior to use. I've rarely seen any that are not a bit warped. It took me around an hour to do, but it only needs to be done once. *** As for your NVIDIA GPU, that's great. I didn't think any NVIDA GPUs worked after High Sierra. Could you explain to us how you manage to get the kexts to work and where do you source the kexts? Are other, recent NVIDIA GPUs supported too?
  16. iGPU
    My system's temps run just fine. Idle is shown below. To read about details on how I prepared the cooler for this CPU, do a search in the VM thread on this forum for a couple of my posts on the subject. Many heat blocks are not flat and temperature transfer is adversely affected. I planed my flat; read the posts. When stressed, power/temps jump up; so as not to repeat re-posting images, see this post here; the temps under those conditions are very reasonable.
  17. iGPU
    If you turn off picker, OC is on it's own. I've not tried it, but if Misc/Boot/PollAppleHotKeys is enabled (I always leave on; presently, p 36 Docs) and Misc/Security/AllowNvramReset is enabled, you might be able to CMD+P+R before Apple logo appears to get into NVRAM when ShowPicker is No. I leave ShowPicker on (Yes), and have TimeOut set to 0 (disable) so I can control what happens. The distorted audio has been discussed: turn off Wifi (or try only using 5G). alcid seems to have little effect, but then I use a USB Audio interface (USB-C port) and not the internal audio.
  18. iGPU
    When I want to boot into Windows (or Linux), I simply hold down the F11 (or F12, depending on mobo) key, to directly boot from BIOS into Windows (or Linux). Not very difficult. If you boot from OC, you're potentially running into problems with OC settings fouling up Windows (or Linux). I just don't see the advantage of using OC for booting into anything but macOS. The other thing that is commonly done, which also makes no sense to me, is setting the SMBIOS to MacPro7,1. The latter has no current advantage with respect to performance (I've tested several times over the past year both in VM and bare metal, in both Catalina and BS, and on Intel and AMD platforms) and only leads to various errors in memory and PCIe lanes issues that some add-on kexts don't fully fix. Why bother?
  19. iGPU
    You need to press the Spacebar while the OC menu items are on screen to reveal your Recovery disks as well as Auxillary items. I routinely flag items in the Tool section as Auxillary = Yes, so that they're only visible when pressing the Spacebar. But you first must enable HideAuxillary to keep these items hidden unless you want them always visible during a boot. I don't like seeing them unless I need them. A few iterations ago, OC needed "0" for the Scan Policy to be able to boot into BS Recovery; this is no longer required. I think the ScanPolicy I've shown below is preferable to 0 so as not to see EFI folders and other garbage.
  20. iGPU
    I don't know if anyone else has had this problem, but since switching to the Big Sur betas, the desktop organization does not stay in place between boots. That is, if I place things in a certain order, they return to a disorganized pattern after re-boot. A bit of searching came up with a solution. The problem is due to a corrupted ".DS_Store" file on the Desktop; the fix is to delete this invisible file (a good copy will auto regenerate on re-boot). Organize the Desktop as you like, delete this file, re-boot, and items will remain in the locations on the Desktop where you specified. To remove the ".DS_Store" file, use Terminal, typing the following: 1. cd Desktop 2. sudo ls 3. enter your pw 4. (verify the presence of ".DS_Store" and that you're seeing Desktop items) 5. rm -f .DS_Store
  21. iGPU
    I have successfully used flashed GB TR AICs in Z390, X570 and X299 without TB headers, as long as the pins are rear of card are shorted. So it should be working in TRX40. There was one post from 2 years ago on another forum where the poster had same issues we have (here). I've tried to nmano, asking if or how the issue was resolved, but have not yet gotten a reply.
  22. iGPU
    There are a couple I'm interested in. I moved the process over to my laptop that runs Mojave. I was able to extract two, turning them into *.bin files, but then I could not convert to text files using the "./ifrextract file.bin file.txt" call. I was busy at work today and didn't have time to pursue more. I don't know if the *.bin files are corrupted or the text conversion routine is broken. I will work on more this weekend. *** On another TB front, I had the idea of connecting the TB port to a TB dock. The dock lit up, but did not connect either a USB-C drive nor the TB-drive. This is strange. I must also investigate this more. BTW, last weekend, I moved the GB TR AIC from the TRX40 mobo and swapped it with an identical GB TR AIC in the X299 build. Both worked in the X299, giving correct TB and USB trees. Both AICs are flashed with same firmware:, they are identical. So this means both cards are working well and that the problem is in how the AIC works (or doesn't work) in the MSI TRX40 mobo.
  23. iGPU
    It's simply a sub-routine often called by SSDTs when injecting properties. It is externalized to reduce SSDT size as the single, external DTGP can be called by many SSDTs. DTGP could be could be placed into every SSDT that calls it and you could do away with the external DTGP SSDT file. Initially, I only called it from TB-SSDT. (KGP, the retired X299 guru, used to call it from almost every SSDT.) I'm presently calling DTGP for two SSDTs: FireWire and TB. It's typically called when injecting properties : Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method { Local0 = Package (0x06) { { Inject #1 } { Inject #2 } { Inject #3 } } DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0)) Return (Local0) } You can avoid by re-structuring the SSDT; the following is same as above without a DTGP call: Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method { Return (Package (0x06) { { Inject #1 } { Inject #2 } { Inject #3 } }) }
  24. iGPU
    The help is already in this thread to construct a functional EFI. You should study it to learn how to set up your own EFI, rather than ask to be handed a fully functional one. Because no matter where you derive the EFI, some customization will be still be required. And when you study a thread, look and see who is using either the same, or a similar, mobo, and then follow their posts (rather than immediately asking for their EFI) to see how they solved issues you wish to solve. (So far, you've asked for EFIs from people who have different mobos than you.) If you've already carefully done this, then ask specific questions rather than requesting an EFI. Otherwise, you learn nothing.
  25. iGPU
    That's a possibility. Pursuing the BIOS approach, the BIOS for MSI Creator has a number of sections devoted to TB, found when doing a search for "thunderbolt" or "TBT". This is typical of AMI bios. (Note, I'm not probing the active BIOS on the mobo, but simply looking at a copy of the downloaded BIOS ROM file.) Unfortunately, the tool crashes when trying to extract data running under Big Sur. I'll need to transfer things over to another machine running Mojave to sort it 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.