Jump to content
Welcome to InsanelyMac.com - No more ads! And some exciting news... Read more... ×


Popular Content

Showing content with the highest reputation on 06/12/2020 in all areas

  1. 2 points
    WTF! Are you sure you've not got me mixed up with someone else cos I'm confused as to where your agression is coming from. I'm not argueing with you or anyone else I'm mearly pointing out that I seem to have a fairly niche use case when using an Intel 750 pcie SSD because my board can not detect it in the bios. Is my knowledge poor??? Probably but I'm still learning but I know enough to get by and when to look for help. But I didn't make any claims about my knowledge either though, and no I'm not confusing bioses with bootloaders. Also my EFI is fine thank you very much, it isn't fubared in any way shape of form, unless you'd care to explain to the contrary in a civilised tone.
  2. 2 points
    @jimborae Ignore his rudeness. He's a bit of an a*hole. I have exactly the same board and honestly, you really need to wipe everything clear and just use @AudioGod EFI (whether Clover or OpenCore) as is except for adding your serial number, etc. It's like two lines. Unlocking your MSR is dead simple and has been covered a hundred times on this board. I can boot from NVMe, and Windows I have installed on a separate SSD. I can do this using Clover or F12 at boot. I can even switch back and forth from Clover to OC (installed on a USB, although I wouldn't recommend doing that regularly). AudioGod has made creating a hack using an AORUS board (several versions) the simplest thing i have ever experienced in my 10+ years of hacking. EDIT: Oh sorry, I thought you had the WiFi version.
  3. 2 points
    Please try the attached version of the kext and tell me whether it makes a difference. LucyRTL8125Ethernet.kext.zip
  4. 1 point
    Or instead of messing up with your Windows EFI partition, you could drop your EFI into a very small footprint usb stick and boot from it.
  5. 1 point
    Thanks, Brumbaer! This did the trick. Setting the link speed manually is still required, though, but in reality this presents little to no issue at all. If Mieze accepts Pull Requests, this should go into the next release
  6. 1 point

    Clover General discussion

    [Solved] To get 10.15.4~10.15.6 beta2 stably working I need Enabled AddDTGP & FixShutdown in my config.plist as shown here: config-Clover-5119.plist
  7. 1 point
    Thanks man, I'll be back to the office in a bit and will test it out Asus WS C621-64L SAGE/10G 1001 BIOS
  8. 1 point


    Since working from home during coronavirus lockdown I looked to update DarwinDumper as it hadn't been touched since 2017. It is an old program and is showing it's age, and if I were to do it all again today then it would be a different beast, but of course that's not going to happen. Anyway, lockdown is easing here and my workload is increasing so after 8 weeks of slowly updating, patching and testing I've finally pushed v3.1.0 to hope it can at least stay relevant for a while longer. Download Changelog - Update RadeonDump and RadeonPCI.kext to 64bit version - Update ioregwv to 64bit version - Update nvram to 64bit version and include more vars to check - Update gfxutil binary to latest v1.80b from acidanthera repo - Update dmidecode binary to latest v3.2c from acidanthera repo - Update Sparkle framework to v1.23.0 - Update lzma to v15.14 - Replace SMC_util3 with 64bit SMC_util_FansOnly for decoding fans - Update iasl to version 20200110 and re-work ACPI dump process - Update list of ACPI table descriptions for HTML report - Add AppleIntelInfo.kext as a separate option - Updated pci.ids - Include extra version of smcutil for listing keys, not fans - Add Mojave and Catalina detection - Fixed config files & drivers dump bug when ESP is already mounted - Changed date format in dump folder name (Thanks IronManJFF) - Replace DirectHW.kext with signed version from Slice - Removed older drivers for pre 10.9 - Updated VoodooHDA.kext to version 292 - Updated getdump to version 109 - Added 64bit version of x86info (Thanks Slice) - Moved CPU dump to section not requiring root privileges - DirectHW.framework will be copied to ~/Library/Frameworks (if required) - Updated info pages and html report sub titles and links - Fix incorrect reporting of SIP protected dtrace restriction in html report - Fix missing Unique partition GUID in Disk partition UIDs.txt file - Read disk device UUID from ioreg IOService plane rather than IODeviceTree - Fix missing Disks dir when running disk dumps - Add preliminary APFS detection for improved disk report(s) - Remove deprecated dumpXuid's option from command line - Fix bdisk script block size detection - Add AppleKernelCoreDump to disk partition image in html report - Add notes regarding disk partition dump being affected by SIP filesystem protection - Add detection for OpenCore, it's log and config files - Only include ACPI tables in HTML report if total size of decompiled files is <= 2MB - Fix missing ESP volume from Bootloader Configs scan. - Rename HTML report section from BootloaderConfigs to Bootloader Configuration Files - Add appleRAID option to diskutil list dumps - Include diskutil lists in HTML report - Add dump of 'simple list' of kexts in prelinked kernel - Add a dump status to the UI for some of the dumps that take time - Update privatise option. - Move 'Disk Partition Tables' in to alphabetical order in HTML report - Revise output of Bootloader Detect & Boot Sectors dump - Improve identification of config.plist - Widen scan for bootloader .efi files - Include SMC RSSN key in privatise option - Add extra command line options for pre-configured dumps using lmza compression - Remove audio codec dump from pre-configured dump options not requiring root-privileges - Remove SIP notification from CPU section of HTML dump when AppleIntelInfo was not run - Don't print empty lines to stdout when converting to html - Add warnings that current SIP settings will prevent memory dump from running - Don't attempt to read MBR and PBR of APFS containers - Don't attempt to read MBR and PBR of APFS physical stores when SIP File Protection is enabled - Print hex bytes as single bytes in disk dumps (Thanks slice) - Change writeable path check from command line - Remove old acpiFromMem option - No longer attempt to run Clover genconfig tool as it's bundled with Clover.app - Cleaned output of Kernel boot messages dump - Extended Kernel boot messages dump to show individual processes - Include bootargs in darwindumper log and head of html report
  9. 1 point

    OpenCore Discussion

    @makk, SSDT-PNLF is unrelated here. And "64-bit" here has nothing to do to 64-bit, it is just that some address calculation overflowed and changed sign. What it likely means is that your DSDT that apparently needs reextraction and/or region fixup (there is a quirk for it). However you approach this, make sure that you extract DSDT via SysReport functionality.
  10. 1 point
    Btw, i got extracted Vega and Radeon 540 VBIOSes, might be possible to do something with them?
  11. 1 point

    Is OSX86 doomed?

    I think this is more about breaking away from intel than even acknowledging hackintoshes. Apple could have put a lot more effort into locking down their OS, but they didn't. However, they have the technology to make their own cpus, and are already using it for their mobile devices. Why not have more vertical integration, and just cut intel out of the stack?
  12. 1 point
    Hi, I have added 4 new patches to UEFIPatch which add support for several C422 and C621/C622 based motherboards running a Skylake or Cascade Lake HEDT+ CPU(s). These motherboards are either Socket LGA2066 (Xeon W2xxx and Core i9 CPUs) in the case of the C422, or LGA3647 (Xeon 3xxxW/Xeon Scalable 1st and 2nd gen) with the C620 series. I do not know if these patches will unlock all of the motherboards based on these chipsets, but they certainly work on several different BIOS images that I tried, specifically ASUS C422 motherboards. They also work on Supermicro motherboards with either chipset. And, to my surprise, they even worked on an X299 based motherboard from Asus. I would be surprised if they work on every motherboard with these chipsets, but they are generalized enough that they could potentially work a fairly long list of motherboards. These patches patch the BIOS so it does not lock the 0xE2 MSR as well as the 0x1AA MSR. If your motherboard is supported, at a minimum you should see UEFIPatch say it applied a patch that 'replaced 24 bytes'. This is the E2 unlock patch. You should also see a patch that 'replaced 28 bytes', which is the 1AA unlock patch. However, not every motherboard actually locks 1AA, so if this patch is missing, it doesn't necessarily mean that your motherboard is unsupported, but simply that it doesn't need the second patch. Of course, if your 1AA register is locked despite this (requiring kernel patches to boot as a result), then it unfortunately means my 1AA patch will not work for your motherboard. Anyway, I've attached the updated UEFIPatch patches.txt file, to use it you simply replace the patches.txt file in the same directory as UEFIPatch with the file attached to this post. Then from the terminal, run: ./UEFIPatch <ROM/CAP/Bios Image file for your motherboard> -o <patched bios file name, can be whatever you want> and if all goes well, it should find patches that work for your BIOS. Sometimes, there will be other parts of the BIOS that older UEFIPatch patches will patch, which is fine. So you might see 3 patches applied in some cases. Don't worry if you see this message: "parseFile: non-empty pad-file contents will be destroyed after volume modifications". This is normal and not an issue here, as none of these patches change the total size of the volume/image being patched. If you see "parseImageFile: Aptio capsule signature may become invalid after image modifications", then you won't be able to flash the modified BIOS if your motherboard verifies the signature of the file before flashing it. Fortunately, all that will happen if you try to flash the modded BIOS is that it will refuse to flash it. Depending on your motherboard, there may be ways around the signature verification (BIOS unlock), or to use an external hardware programmer, but that is well beyond the scope of this post. Do your research though, there may be solutions to such problems! I've created a pull request to add these patches officially to UEFIPatch, but until or if they're accepted, you'll have to use the attached patch.txt file, the one included with UEFIPatch does not include my new patches. Please, let me know if these work or don't work for your motherboard. It would be nice to start a list of supported BIOSes/motherboards, and if yours isn't supported, let me know and I'll see if there is a good way to add support for it. My own free time permitting, of course. This is by no means an exhaustive list, but I believe it will work for the following motherboards (at least): Asus WS C422 PRO/SE Asus PRIME X299-A Asus WS C422 SAGE/10G Supermicro X11 Series LGA2011 & LGA3647 single and multisocket motherboards Maybe your motherboard? Enjoy! patches.txt
  13. 1 point
    BIOSes needing a generalized unlocking solution: 1. Supermicro motherboards 2. Asus Cxxx motherboards 3. Asus X299 motherboards (or at least, one of them) 4. All Cxxx & X299 motherboards if possible? 3 down, 1 to go. https://www.insanelymac.com/forum/topic/343024-uefipatch-bios-patches-for-c422-c621c622-x299-based-motherboards-vanilla-unpatched-kernel-native-power-management/ Get the patches.txt file from that link, and you can use UEFIPatch to unlock the 0xE2 and 0x1AA MSRs (which allows you to boot macOS without any kernel patches and permits total, native power management in macOS) for the following motherboards (at least. My hope is the patches are generalized enough that they will work for a large number of motherboards across multiple brands - but that remains to be seen): Asus WS C422 PRO/SE Asus PRIME X299-A Asus WS C422 SAGE/10G Supermicro X11 Series LGA2011 & LGA3647 single and multisocket motherboards Maybe your motherboard? Also I'm working towards getting my OpenCore folder and config up on github soon for people to use as an example, though I need to figure out what is preventing macOS from booting if I use my latest BIOS's DSDT instead of blocking it and using a DSDT table from an older version of my BIOS. I've done a diff of the working and non-working DSDT, and I can't find anything that would cause this problem... unless macOS needs processors to be processors and not devices? That seems unlikely but I might try that. Stay tuned.
  14. 1 point
    Well, this is (or at least, originally was) a thread for the C422, so its kind of the fault of all us C621 people invading the thread for the confusion. Sorry about that, but I figure it is better to pool our resources :). @yapan4 (and anyone else having sleep/wake panics), can you upload the panic log (or just the top part plus the crashed thread stack trace)? Even when waking up from sleep, usually it gets far enough to still make a panic log. You all might have one in your /Library/Logs/DiagnosticReports folder. It will probably be called 'kernel', and of course have a .panic suffix. It might be under pmutil or something like that as well, not sure. Oh, and anyone with a dual socket motherboard, if you have both sockets populated, you will not be able to get sleep working. The last version of macOS that correctly handled wake/sleep on dual-socket systems was 10.12. The functionality to correctly sleep/wake dual socket systems simply doesn't exist in the macOS kernel anymore, and until or if Apple makes another Mac with more than one CPU socket, I don't think there is any way to get sleep working on dual socket hackintoshes. Sad, but its a small price to pay for an entire second CPU IMO :).
  15. 1 point

    OpenCore Discussion

    Over the weekend, I managed to successfully boot all my systems (Skylake NUC6i5SYH with UEFI, and legacy GA-P55aUD3 desktop & Dell XPS M1530 laptop in my signature) with OC ver 0.0.3 on a GUID HFS+ formatted USB drive. Still testing and tweaking my configs but just about everything works as before . While it currently lacks many of the bells and whistles found in Clover, booting to macOS with OC is very, very fast! Some notes on migrating to OC in legacy machines already booting with Clover Generate config_imprint.plist for currently working Clover installation with clover-genconfig utility. Device properties can then be imported into OC config.plist/DeviceProperties/Add later Prepare OC folder, referring to reference configuration.pdf. Only needed ApfsDriverLoader.efi, HfsPlus.efi, and EmuVariable.efi drivers for my legacy machines. WhateverGreen.kext basically does all the heavy work that Clover's Graphics Inject function used to do so I kept it for all my systems. Use /Docs/Sample.plist provided as template for config.plist Prepare config.plist with XCODE plist editor -Syntax very important, sometimes order of kext loading or kext anomaly prevents loading (eg most Kozlek sensors refuse to load but Slice versions seem ok) <----- Fixed in OC 0.0.4 with this commit so FakeSMC plugins now load OK -Kernel/Patch/RTC patches recommend to enable ---> prevent BIOS resets. Leave MatchKernel blank to apply to all macOS -Kernel/Patch/ALPM IO Error AppleAHCIPort patch enable ---> prevent missing SATA drives on legacy SATA controllers eg ICH10 -Kernel/Quirks/AppleCpuPmCfgLock ---> Yes to prevent AppleIntelCPUPowerManagement kps -ACPI/Quirks/FadtEnableReset ---> Yes to enable shutdown on some legacy machines -Misc/Security/ScanPolicy set to 0 to scan all disks and volumes -Misc/Security/RequireSignature & RequireVault set to 0 if not using FileVault -Misc/Boot/Timeout to 30s better for beginners to see scanned volumes -Misc/Debug/Target =69 enables boot logging to file in EFI and Data Hub -NVRAM/Add/7C436110-AB2A-4BBB-A880-FE41995C9F82/boot-args ---> for adding boot arguments -NVRAM/Add/7C436110-AB2A-4BBB-A880-FE41995C9F82/csr-active-config to enable/disable SIP. I found setting to <30783637> (0x67) disabled SIP on my UEFI Skylake NUC with working NVRAM but not for my legacy machines without hardware NVRAM -PlatformInfo/Automatic set to YES, filled out just Generic values (MLB, ROM, SystemProductName, SystemSerialNumber, SystemUUID from Clover's config.plist) Install Clover first in legacy mode to GUID formatted USB (custom install into FAT32 EFI System Partition). Delete boot file + EFI folder, replacing with OC boot file & EFI folder prepared above - Extra: @RodionS provides a number of different duet boot files for legacy BIOS systems in the Applelife forum - link post#176. Boot_BIOS_BlockIO can be preferable in some systems ---> faster boot to OpenCore.efi. Change name of entry in OC volume list by making hidden text file ".disk_label.contentDetails" with desired name eg "Linux Mint" or "Windows 10"---> place file in OS loader folder eg /EFI/BOOT, /com.apple.recovery.boot or /System/Library/CoreServices For linux on legacy machines, replace /EFI/BOOT/BOOTX64.efi with grubx64.efi. BOOTX64.efi installed by the UEFI linux installer is the shim file for secure booting ---> hang for legacy machines when you reach desktop. OC has weakness for multi boot systems: OC needs separate EFI for each OS loader. If multiple OS loaders installed in single EFI, it will only boot the one installed as /EFI/BOOT/BOOTX64.efi Since Mac ACPI properties are also injected when booting Windows (unlike for Clover), Windows activation may fail if activation is OEM based. Sample OC config for Legacy BIOS system with drivers and kexts: XPS M1530 OC config.zip (Debug ver 0.0.3) Good Hack/Luck!
  • Newsletter

    Want to keep up to date with all our latest news and information?

    Sign Up