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
    I'm not understanding why not using RebuilAppleMemoryMap is reducing anything; it just seems like we use one Quirk or another. The OC docs discuss MAT: In the error log created when booting OC Debug, search for "MAT" and you'll find that MAT = 1, meaning our mobos support MAT: Therefore, it would seem that Booter/Quirks, based on MAT, can be set as: ******* UPDATE: With multiple, very slow boots into Monterey ß1, I remembered on InsanelyMac some users on the Intel side commenting that turning on 'auto login' reduces boot time. It does. (This is most likely just early beta hiccups.) Enable it by going into Users & Groups as shown below:
  2. iGPU
    @fabiosun I just finished test booting your EFI v070 from 1st post on this thread. I only substituted my patches (your have 15; mine 18) and my mono-specific MmioWhitelist; otherwise all is from your EFI folder (no updated kexts, etc). When I did this, I could not boot into either Big Sur or Monterey. I think this is due to other settings within OC and has nothing to do with v070 vs v071. My OC settings also include various ACPI and DevProp injections, which, while I understand many here don't like them, I think they help the functionality of Hackintoshes. I'll work on a sampled EFI and attach to this post in a few minutes...
  3. iGPU
    @fabiosun I've updated my above post to show that AMD-SMC kext files run, at least in my setup, with the posted minimal patches in Monterey ß1. Attached is the debug version of a recent OC v071 that I've been using for these tests. No config, ACPI, Kext (in previous post), Utility or Resources folders are included to keep size small. As for temps, if the computer is not touched, the baseline temp is ~46 C. Moving windows about, etc, cause the temp to spike to ~63 C and then rapidly fall.
  4. iGPU
    I'm working on Monterey ß1. While the patch list is not yet reduced, I did, despite reading complaints about BT not working, have Airdrop working just fine as shown in Spoiler below. (See this previous post about how to get Airdrop to work.) All of this is under OC v071. [So far, patches list for Big Sur + Monterey (ß1) is reduced to 24 22 17 + 2 for Aquantia, from the initial 46+2. See next post for file.] When booting, Monterey is slow with the Apple progress stalling about 1/2 way through, requiring some patience. AirDrop is working: First, below are kexts used (note that some are limited to Big Sur by MaxKernel 20.99.99). The AirportBrcmFixup.kext does not need to be loaded for the 4360 as this work OOTB under Monterey, unlike in Big Sur, which requires this kext to be injected for Airdrop to work. While the driver for I211 is loaded: The port is not active (an ethernet cable is plugged in and works under Big Sur) as shown in Spoiler below (along with the active Aquantia port). While the SmallTree kext is apparently loading, it must not be attaching to the correct location. Attached is the log for all kext files loaded. loaded kext log.zip
  5. iGPU
    I tried the PS Poropopo edition patches. It boots into Big Sur, but not into Monterey beta-1. The Quirk settings were:
  6. iGPU
    Yes.
  7. iGPU
    Actually, the idea was not from reading OC documentation. Instead, I found out about using "2F" as a null entry for editing SSDT files a couple of years ago when working on Find/Replace SSDT patching problems going, ironically, from Clover to OC on the Z390 system. And so I thought it might work here too.
  8. iGPU
    Some of the BT stuff I commented upon here. I211 is not working in Monterey (the SmallTreeIntel82576.kext is broken) and if used will crash the system. This is true for both Intel and AMD. To avoid crash, either disable the kext or don't plug anything into the I211 ports. Aquantia ports are working just fine, but do need a different kernel patch that I posted earlier. And no patches are yet working for Monterey beta 2 on AMD.
  9. iGPU
    I answered this already, here. Change your scan policy, yours is 3481 (try to carefully read the thread). And "SecureBootModel" is best left "Disabled". Your should also look at the Quirk settings I posted on same page here. AppleMCEReporterDisabler.kext is not necessary. I still use AppleALC.kext and WEG (but limit with "agdpmod=pikera"on the 6900XT). I've not seen anyone use "RtWlanU.kext" or "RtWlanU1827.kext" on the TRX40 builds, but perhaps you have add-on hardware of which I'm unaware.
  10. iGPU
    As Ploddles was alluding, the timer may be going too fast. Change Timeout to 0 and there will be no auto-boot until you select the drive and press Enter. Also, use the ScanPolicy value below to ensure that all devices are properly seen in the menu for selection.
  11. iGPU
    tomnic , Thanks, the is a very clear explanation of the mask function. *** Now, leading from this is the 'what'? That is, what exactly are we replacing? Does the substituted data make this section inoperable, avoiding the panic and boot failure? The other questions, stemming from the initial link by fabiosun, that is still unclear to me is: how is this location even chosen? Is it found by looking at the error log during a failed boot? In the link fabiosun provided there is a discussion about XCPM and locating ”_xcpm_init:". (I don't what to talk about XCPM in detail but use this as a model of how we're to approach the topic of patch creation.) What wasn't clear in that link was what lead to looking at ”_xcpm_init:" in particular? Again, was there an error code from a log that pointed out this particular section as causing the panic? Next, there is an extraction from the kernel: "xxd -s 0x2283c0 -l 28 -psu /S*/L*/Kernels/kernel”. I'm assuming that without a drive reference, this is doing an extraction of the boot kernel. However, during patch creation, by definition, we are not working on a boot kernel since it won't boot. So we need to reference a drive with the problematic macOS already installed, or can this be extracted from the macOS Installer app? The other confusing issue was the chosen offset of 0x20000. Why this value? (Maybe Piker discussed it elsewhere and it was common knowledge at the time, but I don't understand why this value was chosen.) To summarize: how are the patch locations located, via error logs? how is the value to be substituted determined (the replacement value)? which file is examined for this section, an already installed drive with the new macOS, or the installation app for this new macOS? *** One target for how this is worked out may be the new code needed for Big Sur 11.4.0. There was a change in the "DhinakG - cpuid_set_cpufamily - force CPUFAMILY_INTEL_PENRYN - 11.3b1" after 11.3.0 Maybe this is a good place to start to see how this all is done? (And it seems that Monterey 12.0 broke this and needs a different, but similar value to 11.4.)
  12. iGPU
    I downloaded the patches from the AMD OSX github site and through OC was able to finally finish the Monterey install on an external USB NMVe drive. It did appear to hang during the installation 2nd re-boot with a frozen Apple logo and no progress bar. I turned off computer after waiting ~5 min, re-booted and the install finished without further problems. (I've seen the same odd install behavior with the occasional Big Sur update, so nothing surprising.) I studied each patch; most are the same, but quite a few new ones specific for Monterey. (I want to pursue the patch issue on your other thread, fabiosun.)
  13. iGPU
    Shown are the settings used for Quirks in OC with the minimal Patch list presented earlier. As for BIOS, both Above 4G and ResizableBar are disabled.
  14. iGPU
    This must be enabled for me to boot in 11.5 beta.
  15. iGPU
    Correct, algrey - cpuid_set_generic_info - disable check to allow leaf7 is not needed at least with 11.5 beta (20G5042c). I seem to recall this came from a couple of patches suggested by Pavo, but I may be mistaken. I variably turned it on and off a year ago even with Catalina. I've yet to test to see if required for Mojave.
  16. iGPU
    Supposedly, BlueToolFixup.kext is only needed for Monterey, and with Monterery you are NOT to use BrcmBluetoothInjector.kext. The image below may help to explain if you carefully note the version restrictions that I've prepared in anticipation of Monterey.
  17. iGPU
    On booting with Clover, I decided to look at Memory slot issues before looking at the Patches since the Memory Error pop-up was annoying me. After several re-arrangements and re-boots, I came up with code that seems to almost work. If the code in Spoiler below is copied and pasted into the Text section of Clover, it will produce the Memory window shown below. This is very similar to what is seen under OpenCore (shown below). The above code at least shifts the DIMMs into the correct positions, mimicking what we see under OC. However, under Clover, there is a warning about single modules being too large. I think the problem is with Clover. When booting with Clover, Clover won't accept more than 16GB per DIMM (see the Size pop-up on the SMBIOS pane; it maxes out at 16384), unlike OpenCore. Clover then probably sends the wrong DIMM size data to macOS, leading macOS to generate the Memory error msg. If I try to fool Clover by only entering 16GB instead of 32GB, the computer won't boot (I suppose it knows that 256GB are present, not 128GB). I don't know who the developers are, but I think this should be fixable. If fixed, we could stop memory error flags. [Now, if you have smaller DIMMs, then this may work for you. If you have fewer DIMMs and they're also smaller, you'll have to work out the pattern as I'm not pursuing further.] On a related matter, despite entering a consistent SN and UUID, which can be verified in Clover logs and is properly saved in the Clover config.plist file, Clover in the SysInfo window (Spoiler below), keeps the correct SN, but changes the UUID and enters it own ROM. Weird.
  18. iGPU
    I'm using both of these two, having them both enabled. I don't remember when/where it arose, but I do vaguely remember trying to minimize the number of patches and both were needed. But the last time I checked any of these was maybe in August or September with an older BIOS and the current Big Sur at that time.
  19. iGPU
    fabiosun, While waiting for Monterey patches, I decided to regress and try booting into Mojave as an exercise. But, I can't seem to get it to work. I've tried old settings that I thought worked a year or so ago, including OC v061 as well as v070 with its various updates. In verbose mode, I only see the following on screen and then computer freezes: End SetConsoldeMode Start OpenKernelRootVolume End OpenKernelRootVolume When looking at the debug error code, during the Mojave boot, the stoppage occurs at the XNU hook stage (shown in spoiler with comparison to same area during a successful boot into Big Sur). Once the XNU hook is successful, then the kernel patches are loaded, so this freeze occurs just before the Kernel Patch stage. Any ideas how to fix?
  20. iGPU
    Anche io!
  21. iGPU
    Soon. See this post from today.
  22. iGPU
    Yes, me too. It is related to incorrect Kernel/Patches. We must wait until these are sorted out (I don't know how to create them). But, remember to adjust Patches and Kexts to change any MaxKernel 20.99.99 values to 21.99.99 (20 = Big Sur; 21 = Monterey). Otherwise, nothing will load for Monterey!
  23. iGPU
    I've referred to this site before, but go here and use the pop-up in upper left corner to select the various kexts. Download the latest release versions that will now support macOS 12 without having to use various boot-args. These were all updated by PMHeart. Update: PMHeart now suggesting boot-args (-wegbeta -lilubetaall) are still needed and may not be fixed until the 2021-July release of Monterey.
  24. iGPU
    @Arrakis Maybe look at this post here, esp the idea of manually re-setting Ethernet. (In the subsequent post, it's reported that "the vit9696 Kernel patch" that you tried, is broken in 11.4.)
  25. iGPU
    @Arrakis Maybe post your I210 problem on the OpenCore thread here and see if someone else has any ideas. If you're lucky Vit9696 might weigh in. You'll need to carefully itemize each test/adjustment you performed (esp detailed descriptions of the Force and patch injections) to minimize pointless suggestions which cover something you've already tried.
×
×
  • 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.