Leaderboard

sounds like a very easy way for new people. just paste a bunch of .aml preset and say to world "i have vanilla"

Hey Yes. Work good too, is just one meme for fun . Rehabman, daliansky for example made all work with this way and have a full solution with many renames, inject new devices, etc. is about "don't use dsdt or don't use ssdt", is a non-sense words we can Just Enjoy, guys! Let's back to macos big sur topic.

First, some clarifications are needed: 1. ACPI tables are a way for the hardware manufacturers to tell the OS "how you can safely turn a piece of device on and off, or adjust power to anything in between the 'on' and 'off' statuses". 2. SSDT or DSDT files follows the same logic and uses the same commands, but they have different contents for different tasks. The first is designed as peripherals section (I.e., SATA or TPM or SLIC or eGPU or Thunderbolt), whereas the latter as the motherboard and its embedded components (I.e., power button and GPU and CPU). Note the "or" and "and". 3. You can label your files "DSDT-EC.aml" if you want - that's purely cosmetic. Its contents is what matters. 4. A DSDT or SSDT file is what the manufacturer adds as part of the hardware ACPI tables, and updates during their UEFI/BIOS/microcode upgrades on your computer. A SSDT file has the ability to extend certain sections of your DSDT (or other SSDT), and is more flexible/manageable for changes, since you will end with smaller chunks of code to review, mess or cause errors - and most of the time, these won't affect too much the ability to boot the system, since an ACPI execution error only affects the block you are working on. With that out of the way, item #4 is what we do on the Hackintosh world, except we are making changes for macOS to load on the non-officially supported hardware. And usually by doing so, unless you are adding the necessary check items for use on macOS and keeping those to run on Windows or Linux, you will end up with an OC system that is capable of booting EITHER Linux and Windows OR macOS. And that's why the definition "do not use a DSDT" comes into play: most commonly, the DSDT edits removes the ability of other OS to boot, as they are oriented to macOS, and therefore are not recommended. Note this is different from "you MUST not use". You can, again, use a DSDT edit if you know what you are doing OR if you agree in taking the risks of having a half-baked solution; just don't come up to the forums complaining "why OC doesn't boot Windows". You have been warned

Iam Old school guy; Full patch DSDT

better to refrain from starting windows with OC even at best when it starts it correctly, it still passes values that many motherboard builders utilities do not function properly, not recognizing the system Start windows with function keys or with Clover and use OC to start macOS only my 2 cents

A very custom DSDT for best experience under macOS. Removed all unused devices, injected all Apple devices, essentials, cosmetics, real improvements. -OpenCore Vanilla TUTORIAL- -USB Port Mapping TUTORIAL- -Bios/UEFI Settings- Serial Port = Disable CFG Lock = Disable -Thunderbolt Configuration- Security Level - No Security GPIO3 Force Pwr - Enabled -Hardware- Mobo - Ga Z490 Vision D https://tinyurl.com/y4gajha4 Processor - i7 or i9 10th Intel https://tinyurl.com/y6jlskwz GPU - RX 580, 590, VEGA 56, VEGA64, 5700XT or RADEON VII https://tinyurl.com/y4mxc7t6 Cooler - SCYTHE Ninja 5 https://tinyurl.com/yyrbx5lf NVME - WD Black SN750 NVMe SSD https://tinyurl.com/vnq46yr -EFI folders- Clover - https://tinyurl.com/ybr968w3 OpenCore - https://tinyurl.com/ybr968w3 Just paste EFI folder into EFI partition, reboot and extract one SendMe. Post this dump here for full ACPI solution! Download RunMe.app dumper -If you want to buy me a beer - Donations with PayPalhttps://tinyurl.com/r2bvzm7 -DSDT Patches- -Screenshots- -Credits and thanks to the old and new people in the community who developed patches, kexts and bootloaders! Thx to KGP for SSDT Thunderbolt Slice, Kabyl, usr-sse2, jadran, Blackosx, dmazar, STLVNUB, pcj, apianti, JrCs, pene, FrodoKenny, skoczy, ycr.ru, Oscar09, xsmile, SoThOr, RehabMan, Download-Fritz, Zenit432, cecekpawon, Intel, Apple, Oracle, Chameleon Team, crazybirdy, Mieze, Mirone, Oldnapalm, netkas, Elconiglio, artut-pt, ErmaC, Pavo, Toleda, Master Chief and family, bcc9, The King, PMheart, Sherlocks, Micky1979, vit9696, vandroiy2013, Voodoo Team, Pike R. Alpha, lvs1974, Austere.J, CVad and many, many, many others! We're all here to have fun and learn from each other!

I'm sorry I have to disagree with you. OC has a fairly good boot selector. It has a simple text based builtin boot selector and it has an API to add an external boot selector. And there's an example of an External boot selector called OpenCanopy that was added by the OC team. Yes OpenCanopy is still in-developent and will improve further when it's complete. That boot selector works almost like a native Mac boot selector. You can even use Mac like hot keys e.g. OPT key during boot to display the boot picker - just like a real Mac Here's what OpenCanopy displays on my system (Hack 4): I have not had a problem booting Windows from OC. My Windows version is Retail and was fully activated BEFORE OC was ever installed. It is still activated after booting it via OC. On that system, I don't even have a DSDT and Windows boots fine. Here's another system I have that is LEGACY system that does NOT even have UEFI but with OC's Duet Legacy boot, I can still use OpenCanopy and boot Windows 10 (Hack 2): OK, on this legacy system I could NOT initially boot Windows because it would fail with the ACPI_BIOS_ERROR blue screen of death. That's because the DSDT that I had which was being injected to Windows by OC did not allow for Windows booting (e.g. _OSI checks). I have completely modified that DSDT with liberal use of _OSI guarding and I can now boot Windows 10 without any issues and no problem with Activation. That version of Windows has OEM (DELL) Licensing. I'll get around writing a guide on how I modified that DSDT to enable Windows booting via OC hopefully. I can even use macOS's Start-up Disk selector from System Preferences to select an OS to boot and OC takes care of booting that OS (both on UEFI & Legacy BIOS systems). So I am failing to understand your issue is with OC's boot selection. EDIT: If you have an issue with booting Windows, then it has nothing to do with the Boot Selector but with the core function of OC - which was by design. That design choice the Devs made to boot macOS just like a Mac and allow other OS's to boot the way a Mac does.

Clover 5120 tested with the latest commits: Z68: high sierra, mojave, catalina Z97: sierra, high sierra, mojave, catalina Z170: high sierra, catalina . (I had to change layouts for AppleALC) Z370: high sierra, mojave, catalina

I'm trying to understand why Dortania says over and over NOT to use a DSDT, and many do use DSDT in opencore, including you and MaLd0n

This method works, I did install Intel Power gadget and the name changed to Big Sur after reboot. Thnaks SavageAUS

Your SSDT-USB-EC needs work. Make sure you are using latest OpenCore

This project is dedicated to the memory of Mausi, the cat I loved more than anybody else. A few days before Christmas I started my latest project, a new driver for recent Intel onboard LAN controllers. My intention was not to replace hnak's AppleIntelE1000e.kext completely but to deliver best performance and stability on recent hardware. That's why I dropped support for a number of older NICs. Currently the driver supports: 5 Series 82578LM 82578LC 82578DM 82578DC 6 and 7 Series 82579LM 82579V 8 and 9 Series I217LM I217V I218LM I218V I218LM2 I218V2 I218LM3 100 Series (since V2.1.0d0) I219LM I219V 200 Series (since V2.3.0d0) I219LM I219V 300 Series (since V2.4.0d0) I219LM I219V 400 Series (since V2.5.1d1) I219LM I219V Key Features of the Driver Support for multisegment packets relieving the network stack of unnecessary copy operations when assembling packets for transmission. No-copy receive and transmit. Only small packets are copied on reception because creating a copy is more efficient than allocating a new buffer. TCP, UDP and IPv4 checksum offload (receive and transmit). Support for TCP/IPv6 and UDP/IPv6 checksum offload. Makes use of the chip's TCP Segmentation Offload (TSO) feature with IPv4 and IPv6 in order to reduce CPU load while sending large amounts of data (disabled due to hardware bugs). Fully optimized for Sierra (64bit architecture) but should work with older 64bit versions of macOS too, provided you build from source with the appropriate SDK for the target OS. Support for Energy Efficient Ethernet (EEE). VLAN support is implemented but untested as I have no need for it. The driver is published under GPLv2. Current Status The driver has been tested successfully with I217V, I218V, I219V and 82579V under 10.9.5 and above. The attached archive includes source code as well as a prebuilt binary (debug version) for Mavericks and newer versions of macOS. Known Issues There seem to be problems while using VMware with version 1.x.x of the driver. In case you are affected use version 2.0.0 or newer. FAQ Could you add support of for...? Well, you are probably asking me to add support for one of the older NICs like the 82571/2/3/4L or 82583 and the answer will be no as I dropped support for these chips intentionally. They are broken and I lost more than 2 weeks trying to make it work on the 82574L without success. I was asked to add support for I210, I211 and I350 but as these chips have a completely different architecture, which isn't supported by the underlying Linux driver, this is impossible, sorry. Does it work with Snow Leopard or 32 bit kernels? No and I have no plans to make a version for 32 bit kernels or anything older than Lion. WoL from S5 doesn't work with this driver but under Windows it's working. Is this a driver bug? No it isn't, the driver is working as it should because OS X doesn't support WoL from S5. Installation Goto /S/L/E and delete AppleIntelE1000e.kext. Recreate the kernel cache. Open System Preferences and delete the corresponding network interface, e. g. en0. Reboot. Install the new driver and recreate the kernel cache. I recommend to use Kext Wizard or a similar utility for the installation. Reboot Open System Preferences again, select Network and check if the new network interface has been created automatically or create it manually now. Configure the interface. Help - I'm getting kernel panics! Well, before you start complaining about bugs after you upgraded macOS and ask me to publish a driver update, you should first try to resolve the issue on your own by cleaning the system caches. As the driver uses macOS's private network driver interface, which is supposed to be used by Apple provided drivers only, you might run into problems after an OS update because the linker may fail to recognize that IONetworking.kext has been updated and that the driver needs to be linked against the new version (Apple provided drivers avoid this problem because they are always updated together with IONetworking.kext). As a result, the linking process produces garbage and the driver may call arbitrary code when trying to call functions from IONetworking.kext. This usually results in unpredicted behavior or a kernel panic. In order to recover from such a situation, you should clean the System Caches forcing the linker to recreate it's caches: Delete all the files in /System/Library/Caches and it's subdirectories but leave the directories and the symbolic links intact. This is very important! Reboot. Recreate the kernel cache. Reboot again. Troubleshooting Make sure you have followed the installation instructions especially when you have issues with certain domains while the others are working fine. Use the debug version to collect log data when trying to track down problems. The kernel log messages can be retrieved with "grep kernel /var/log/system.log" in Terminal. Starting from Sierra use "log show --predicate "processID == 0" --debug" in order to retrieve kernel logs. Include the log data when asking for support or giving feedback. I'm an engineer, not a clairvoyant. Don't copy and paste large amounts of log data to your post. Create an archive with the log data and attach it to your post. In case you don't want to make your log data publicly accessible, contact me via PM and I will provide you a mail address to send it directly to me. Check your BIOS settings. You might want to disable Network Boot and the UEFI Network Stack as these can interfere with the driver. Double check that you have removed any AppleIntelE1000e.kext from your system because it could prevent the driver from working properly. Delete the following files: /Library/Preferences/SystemConfiguration/NetworkInterfaces.plist /Library/Preferences/SystemConfiguration/preferences.plist Verify your bootloader configuration, in particular the kernel flags. Avoid using npci=0x2000 or npci=0x3000. In Terminal run netstat -s in order to display network statistics. Carefully examine the data for any unusual activity like a high number of packets with bad IP header checksums, etc. In case auto-configuration of the link layer connection doesn't work it might be necessary to select the medium manually in System Preferences under Network for the interface. Use Wireshark to create a packet dump in order to collect diagnostic information. Keep in mind that there are many manufacturers of network equipment. Although Ethernet is an IEEE standard, different implementations may show different behavior causing incompatibilities. In case you are having trouble try a different switch or a different cable. Changelog Version 2.5.0 (2019-10-15) Reworked interrupt throttling code and added new configuration parameters. Version 2.4.0 (2018-04-14) Added support for 300 series versions of I219LM and I219V. Updated underlying Linux source code. Version 2.3.0 (2017-06-20) Added support for 200 series versions of I219LM and I219V. Version 2.2.0 (2016-09-23) Disabled TSO to work around a hardware bug. Version 2.1.0 (2016-05-24) Added support for I219LM and I219V Version 2.0.0 (2015-04-22) First official release which is identical to 2.0.0d2 (only the version number has been changed). Version 2.0.0d2 (2015-04-04) Changed the tx descriptor write back policy for 82579, I217 and I218 to prevent random tx deadlocks. Version 2.0.0d1 (2015-03-14) Uses Apple's private driver interface introduced with 10.8. Supports packet scheduling with QFQ Solves the VMware issue. Version 1.0.0d6 (2015-03-04) Reworked TSO6 support to avoid problems with VMware. Wake-on-LAN now working. Version 1.0.0d5 (2015-02-27) Reworked TSO4 support to eliminate the bug of 1.0.0d4. Added some debug code in order to collect information about the VMware related issue. Version 1.0.0d4 (2015-02-25) Set total length field of the IP-header to zero for TSO4 operations. Report EEE activation state in kernel log message when the link has been established. Version 1.0.0d3 (2015-02-11) Reworked media selection and EEE support (EEE is now activated when both link partners support it. It can be disabled selecting the medium manually). Duplex setting for 10/100 MBit connections is now reported correctly. The number of tx descriptors has been reduced from 2048 to 1024. The code has been cleaned up and obsolete files have been removed. Version 1.0.0d2 (2015-01-31) First development release. Getting the Driver The source code can be found on GitHub: https://github.com/Mieze/IntelMausiEthernet There is also a prebuilt binary for 10.11 and above in the download section: http://www.insanelymac.com/forum/files/file/396-intelmausiethernet/ Build from Source for 10.8 Register as a developer on Apple's developer website. A free membership is sufficient. Download a copy of Xcode 5.1.1 and install it on your machine. In the project select 10.8 as the "Base SDK" and the "Deployment Target". Call "Archive" from the menu "Product" and save the built driver. Credits Thanks to RehabMan and Yung Raj for running tests and pointing me in the right direction while I was trying to fix TSO. Special thanks to Yung Raj for motivating me when I was about to give up.

And now, a commit that restore the icon order. The 2nd pass in ScanLoader() is removed. All menu entries, hidden or not, are created and stored in the entries array of the menu. ATTENTION : there is a slight change of behavior with F3. Because all menu entries including the hidden are created, F3 just toogle a "display hidden entries" flag and redraw the menu. It does not rescan volume like ESC does anymore. Advantage is that it's instantaneous. C++ NOTE : the way I've implemented that is to subclass the REFIT_MENU_SCREEN.Entries class. Then, I just to override the size() method to return the number of non-hidden entries, and override operator [] to return the nth non=hidden entry. In fact, there is also a boolean in that subclass called "includeHidden". You go it. Depending of that boolean, size() return the number of entries (I just have to call the superclass size()), or the number of non-hidden entries. operator [] also call the superclass operator [] if 'includeHidden' is true, or it's own implementation if it's false. That way, I didn't have to touch at all at the code that display the menu. Nice, isn't it ?

I only use SSDT and my brightness keys work, I can send my EFI if it helps

@yapan4 All fans knows: Clover is no ready yet for BS

Ok, build bc04c86a9, Big Sur beta4: - no progress in my case, still the same stop on apfs_module_start: 2411 Build_bc04c86a9.zip

from haswell onwards, nowadays with the evolution of the hack world, just targeted SSDT for old hardware and notebooks then you might also need DSDT

I find it very comfortable and easy to use, bob the builder https://www.insanelymac.com/forum/files/file/1003-bobthebuilder/

@yapan4 If I remember well: you need to create src folder (under user account) and copy cloverbootloader directory in it, like this: ~/src/cloverbootloader. After Option 1 (Build Clover) et Option 3 make pkg. For updating with this vector sigma's script Option 10, of course

error messages are related to git. So I imagine some script is expecting that the clover folder is also a git repo. Try a "git clone https://github.com/CloverHackyColor/CloverBootloader.git" What's nice about that, is, each time you want to update, just "git fetch" and "git pull"

Looks like compilation was successful but then something happend. Did you get clover with a "git clone" or from a zip ?

I am trying to understand and wrap my head around the problem here, In my system I dual boot BS with windows10 with OC using just the one EFI Folder On the BS drive to boot all, I also Hot Plug Catalina on an external disk using the same EFI Folder without the hint of a problem. I can cold boot any one of the OSs at any given time. In saying all of that my system is a Gigabyte Z390 Pro wifi board, not exactly the easiest board to configure for OS X given the amount of faffing one has to do to install OS X with OC. Clover was relatively easier in my opinion (maybe it's because I was more familiar with Clover) compared to OC on this board but once I figured what was needed, any problem now is only small and easily solved. Getting into the BIOS from Windows is also mentioned, I can't see the significance of this, does it really matter which OS allows you to get into the BIOS as long as you can get in there and are we talking about a Legacy or UEFI system? Forgive me if I am missing the gist of the whole conversation but like I said I am somewhat perplexed by the post and what the poster of the query is trying to achieve.

If your DSDT.aml is not create by the utility you can try different SMBIos on the USB Installer then booting with this usb and finally try the utility If that's not work you will see right away because NO DSDT So remove EFI of the SSD change SMBIOS on USB , Reboot and retry

Thank you @Mieze for the official release! Have a nice rest of summer, stay safe MERGED POST Hi again @Mieze apologies to bother, the GitHub Release page is still pointing to v2.2.2: https://github.com/Mieze/RTL8111_driver_for_OS_X/releases Are you no longer updating the GitHub project pages? Just to be sure that I get from YOU the official 2.3.0 release and not some other pre-built kext... there are many pre-compiled kexts in general and I prefer the official ones. Many thanks.

Kinda noob question... Is there a way to unseal Big Sur after it has been sealed by the initial installation?

Welcome. I hope you managed to boot into Big Sur. 90% of boot problems here are related to EC SSDT. Big Sure is more finicky about ACPI. Most motherboard manufacturers are breaking ACPI spec and this is the root cause. Compiling SSDT is as simple as opening SSDT.dsl file in MaciASL, editing the required lines and saving it as SSDT.aml. It is compiled at the time of save.

Thx, Chris!!! My pleasure!

Very nice! Good to see you still pumping the themes out

Hi, a theme named "BigSur" version 1.0 is now available at my CloverThemes repo. Enjoy and stay safe guys!

As version 1.0.0d6 has been working very stable, I decided to make it the first official release 1.0.0 and uploaded a prebuilt binary with debug and release builds to the download section. Mieze

Hello everyone, I activated the Intel HD 4400 on my full profile notebook, the only problem that I have low brightness as it once did, even using dsdt and ssdt that I use with Catalina, I ask if I have to put a command line on the config to solve the problem, or Other solution. Thank you

macOS Catalina 10.15.6 (19G2021)

To update Big Sur volume label from PreBoot to what ever you named it (if you named it) install something that updates the preboot volume like intel power gadget (then remove if unwanted) reboot, success! Sent from my iPhone using Tapatalk

Disassembling BigSur Beta4 kernel I found that old Clover's method to inject kexts should work. There are just new offsets and conditions preventing success.

Clover & OpenCore EFI Updates (10.15.6 Ready), 4th August 2020 (Use With Bios Revision F12d) The EFIs and DSDTs have now been updated to the my latest versions. Changes made include, AppleALC 1.5.1 Lilu 1.4.6 WhateverGreen 1.4.1 VirtualSMC 1.1.5 AirportBrcmFixup 2.0.8 IntelMausi 1.0.3 New DSDTs For Clover For firmware F12d OCQuirks Revision 23 (Clover) Clover Updated to Revision 5120 OpenCore Updated to Revision 0.6.0 (Big Sur Beta 4 Ready) OpenCanopy is now Enabled as Standard Plus other major tweaks and changes to all of the configs Clover EFI Update - 04/08/2020 - Use with Bios revision F12d Only or Replace with the older F11 DSDT if you don't want to update the bios Clover Z390 Pro Navi Vega EFI 040820.zip - Vega, Navi (5700, 5700XT etc), Radeon VII DSDT EFI Clover Z390 Pro Polaris EFI 040820.zip - RX500 Polaris Series (RX590, 580, 570 etc) DSDT EFI Note - If your not using a 5700 XT or any other Navi GPU then remove agdpmod=pikera from the boot arguments. Please Note - I have now set KernelPM to No as standard so if you don’t have a unlocked MSR or not using my MSR Unlocked Bios Profile then go into the Clover Config.plist and set KernelPM to Yes or you won’t be able to boot up. An even better fix would be to unlock your MSR using my profile method. OpenCore EFI Update - 04/08/2020 Myself and @texem have now created a OpenCore EFI done the way the OpenCore Devs intended it to be made, There is no DSDT in use so you can use this EFI on any supported GPU and the SSDTs have been made so they will not be used in any other Operating System apart from MacOS. OpenCore 060 Z390 Pro 19,1 030820.zip - OpenCore v0.6.0, SMBios iMac19,1 OpenCore 060 Z390 Pro 1,1 030820.zip - OpenCore v0.6.0, SMBios iMacPro1,1 (IGPU Disabled) Note - If your not using a 5700 XT or any other Navi GPU then remove agdpmod=pikera from the boot arguments. Note 2 - Do not try to carry across your old OpenCore Config.plist to the new EFI as to many changes have occurred in 0.6.0. Use the new Config.plist instead. For OpenCore Using PlistEdit Pro add your details by modifying the following PLEASE NOTE - These EFIs are setup to be used with your msr Unlocked so make sure you use the F12d Unlocked Profile but if for any reason you can not unlock MSR then just modify following in the OpenCore config.plist :  Additional Downloads mb_bios_z390-aorus-pro_f12d.zip - Aorus Z390 PRO Firmware F12d PlistEdit Pro.zip - PlistEdit Pro (use to edit OpenCore) CFG Unlock (MSR) F12d (F12c Pro WIFI) BIOS Profile - The Easy Way  I have made this bios profile for you all to use that will unlock CFG on your motherboard making it play alot more friendly with the NVRam. It also has all the bios settings listed on this guide pre done and saved onto the profile.  F12d_UNLOCK.zip - Use with Z390 Pro Bios Revision F12d ONLY F12c Unlock.zip - Use with Z390 Pro WIFI Bios Revision F12c ONLY 1 - Download the profile and save it to a USB Key 2 - Go into the bios, 3 - Load the profile, 4 - Save and exit 5 - Go straight back into the bios and save your bios to a new profile and name it Default CFG Unlocked or something like that. 6 - Boot back into Catalina go into your clover config and under Kernal and Kext Patches Uncheck KernalPM 7 - Save the changes and then restart and your done, your motherboard will now be CFG (MSR) Unlocked PLEASE NOTE - If you reset the bios or load bios defaults it will clear the Unlock making CFG Locked again.

If it wasn't for Mald0n this thread would be staying closed so thank him not me for talking me around. A certain person (you know who you are) nearly spoilt it for everybody but the needs of the many outweigh the needs of the Few or the One. New EFIs for OC and Clover with new DSDTs today or tomorrow. Im just doing the master thread first then il turn over to here and do the same