Jump to content

vit9696

Developers
  • Content Count

    743
  • Joined

  • Last visited

  • Days Won

    41

Everything posted by vit9696

  1. Hello, This is going to be a support/discussion topic of AppleALC on InsanelyMac. AppleALC is a kernel extension allowing you to enable native apple HD audio without any filesystem modifications. It dynamically injects the necessary modifications to AppleHDA (and other kexts) including the layouts, and makes your audio work starting from the OS installation. It should be noted that AppleALC starting with version 1.1.0 requires Lilu.kext to be put in the same folder as AppleALC.kext. See this topic for more details. For quite some time we are trying to obtain the necessary information about AppleALC codec compatibility. If you use something, please, consider checking the compatibility table (do not worry, it is in English), and report (here) on your codec. We are also looking for all the possible revisions of the codec, if we do not have the revisions listed for your codec please report as well. Thanks for understanding. The report is meant to contain: 1. Laptop model/Motherboard model 2. Codec name 3. Layout used with the info what works for you (ideally if you try them all) 4. OS X versions you tried 5. Autogenerated Info.plist made with the help of this utility. All the details including the source code are available on github: https://github.com/vit9696/AppleALC Some short wiki articles explaining the usage are included. As for now the project is relatively immature without practically any codec support. But it should be pretty easy to add more of them, I am hoping for the support of the "community" If you have any issues, better report them on github for structural reasons.
  2. SMC emulator with 2nd generation SMC support. Includes some monitoring plugins as API usage examples. New plugin additions are very welcome, given that they are well-written. Source code: repository. FAQ and documentation: link. Features and configuration: link. I wish to express my deep gratitude to all the people who worked on this project with me.
  3. Base instrument for the interested developers. Implements kext and process patcher interface. Is used as a base in AppleALC and Shiki released earlier. Source code: repository. Usage: existing plugins and SDK. Pros (compared to existing bootloader patchers): Does not depend on a bootloader; Works in Recovery / OS Installer; Supports symbolic patcher; Enables kernel and kext API access; Allows process modifications. Control (via boot-args): -liludbg — enable debug printing (available in DEBUG binaries); -liluoff — disable Lilu; -liluslow — enable legacy user patcher; -lilulowmem — disable kernel unpack (disables Lilu in recovery mode); -lilubeta — enable Lilu on unsupported os versions.
  4. vit9696

    OpenCore Discussion

    Something is wrong with this description I am afraid. You should not be able to build any binary at all without running make -C BaseTools. Maybe you had some older tools compiled in some other directory out of the tree (i.e. outside of edk2 directory), and they were used instead of the ones you checked out?
  5. vit9696

    OpenCore Discussion

    I do not believe SSE is enabled when targeting EFI in Xcode. It is quite a bit complicated to discover it in such a complex piece OVMF is. Basically you have a firmware that is built by a package, which is built from a number of drivers. These drivers consist of libraries. Libraries are built once for the whole package and are then linked into the firmware. So even though you can adjust the compilation flags of the drivers and the libraries separately, one library will always affect all the drivers, and 80% of driver code come from the libraries. The only "working" solution I can think of is building the drivers separately (i.e. their DEBUG versions that are known to work) and then replace their counterparts via binary blobs. Here is an example inf loading the HFS+ driver: https://github.com/acidanthera/OpenCorePkg/blob/master/Legacy/BinDrivers/HfsPlus.inf. You just put the driver relative to this inf file and then include it in the firmware: https://github.com/acidanthera/OpenCorePkg/blob/0.6.2/OpenDuetPkg.fdf#L119. By generating such .inf files with a script you should be able to quickly build the overrides for the whole OVMF DXE volume and put them here one by one: https://github.com/acidanthera/audk/blob/cbccf995920a28071f5403b847f29ebf8b732fa9/OvmfPkg/OvmfPkgX64.fdf#L202. Once you figure out which driver or which set of drivers is at fault (try starting with a simple binary search: try that replacing all the DXE drivers with DEBUG overrides makes the RELEASE version work, then try replacing a half of them, and so on), you should be able to compare the two more precisely. Here we could be of some help I guess.
  6. 1. We have MinKernel/MaxKernel, and you can put kexts to any subfolder you want relative to Kexts directory, so I believe it is already there. 2. There was a request previously, but it is hard to align this with vaulting functionality. Currently we do not have that as a priority (see https://github.com/acidanthera/bugtracker/issues/717).
  7. vit9696

    OpenCore Discussion

    Of course. And not just Apple, but also some virtual machines.
  8. vit9696

    OpenCore Discussion

    Not by AppleALC but by macOS. This is the basics for making macOS work on non-Apple hardware.
  9. vit9696

    OpenCore Discussion

    It is in Microsoft folder for newer OpenCore versions due to bootmgfw.efi being used to boot Windows nowadays.
  10. 2all, we are aware of X99 issues on Big Sur from b1. They are caused by IOPCIFamily device enumeration changes. It is not clear what exactly is causing the issue without the hardware and the new source code release for IOPCIFamily. At the moment we have no plans to investigate this in the near future.
  11. vit9696

    Which boot loader do you prefer?

    Released Macs this year (e.g. iMac20,1) will be supported for at least 7 years from now. So we expect at least 5 more operating systems after 11.0 that will support Intel Macs. We are also interested in making older operating systems work on vintage computers and virtual machines (even on ARM Macs when they are released). So yes, we believe there is some good reason to support a clean thing. The primary reason we started OpenCore was that Clover has many "automatic" actions, which behaviour is not documented anywhere. This caused many issues on various platforms from Macs and virtual machines to even hacks. There also were some design issues like no bless model (operating system discovery that works not like on Macs and often breaks), legacy kext injection, a lot of legacy in the configuration, and so on.
  12. vit9696

    Which boot loader do you prefer?

    @Jief_Machak, @Slice, this may sound a little harsh, but might it be the time to say goodbye to Clover as it is? OpenCore follows rather different design and philosophy and making it work on top of Clover is not the greatest idea, as it replaces 90% of the functionality in Clover except the UI maybe. It is my personal opinion, although shared by a number of developers, but OpenCore code is also a lot cleaner and better documented. Perhaps, a better approach would be to merge the most useful Clover parts into OpenCore if there still are any, as a driver or even to mainline, and continue developing the unified project together? I understand that we have different understanding of how the UI should work, but this thing works via the protocol, which can technically be extended and replaced by a standalone driver with Clover-like UI.
  13. vit9696

    OpenCore Discussion

    There is no real answer. You normally do not need to add any entry to whitelist. But on some older models you need 1-2. You can diagnose this by early kernel panics. @CVFZ, OpenCore is designed in a way it is possible, but currently there are no plans.
  14. vit9696

    OpenCore Discussion

    In your log I do not see the Secure Boot being used, I referred to 0.6.1 issues with NVDA drivers in general. I am not sure of your other issue, and do not have much of an idea, sorry.
  15. vit9696

    OpenCore Discussion

    @fabiosun, it is not possible to use NVIDIA Web Drivers with Apple Secure Boot I believe. Basically this is the reason there are no drivers for 10.14+ You will have to disable it.
  16. vit9696

    OpenCore Discussion

    Right, if you installed Acquantia driver to /Library/Extensions, you will not be able to patch it when SecureBoot is enabled or on 11.0 at all. - For 10.15 either set SecureBootModel to Disabled, or install patched Acquantia driver to OpenCore. - For 11.0 your only option is to inject via OpenCore.
  17. vit9696

    OpenCore Discussion

    Regarding the Acquantia issues. Which commit did it break? Could you provide a hash? Also, if you are trying to patch an injected kext, I do not believe it is expected to work (or has ever expected to to work before). To get the first not working and last working commits please try the versions from here: https://dortania.github.io/builds/?product=OpenCorePkg&viewall=true
  18. vit9696

    OpenCanopy Icons

    The list of mandatory icons is specified in the PDF: https://github.com/acidanthera/OpenCorePkg/blob/0.6.0/Docs/Configuration.tex#L4531-L4534 These are Cursor, Selected, Selector, and HardDrive. Icons that represent a boot entry have flavours: internal and external. So for the HardDrive icon you must make both: HardDrive.icns and ExtHardDrive.icns. All other icons are optional, and that means that you can do Apple.icns, Apple.icns + ExtApple.icns, or none at all. We recommend making at least the icons that are found in OcBinaryData, but this is not a requirement. Providing more icons for other operating systems, like Linux, in order to specify them as a .VolumeIcon.icns is also nice, but is not a requirement as well. There will be technical requirements about the formats. The icons should be created with the builtin icnspack utility (which settles down the format question and makes HiDPI support a requirement), and PNG files used as a source must be as small as possible. You can optimise them with ImageOptim.
  19. vit9696

    OpenCanopy Icons

    Hello, We plan to create a customisation gallery at dortania.github.io. The initial idea is to request everyone to provide the following information from the end-user: - Icon pack name - Icon pack author - Icon pack description - Preview photo, ideally in HiDPI 4K - Link to a github repository containing the icon pack For those, who want to host the icon packs on dortania, there should also be an option. Before we start we will need some information on whether it is enough or whether there is any specific detail that we are unaware. Vit
  20. vit9696

    OpenCore Discussion

    Recovery loading with non-zero ApECID is not yet implemented. Please be patient, the new stuff is in flux at the moment.
  21. vit9696

    OpenCore Discussion

    @beidl, well, you do have the patched tables that Clover generates, so you could always inject them with OpenCore. Unfortunately Clover is very messed up, so it is almost impossible to say what exactly resolves the your issue in it.
  22. vit9696

    OpenCore Discussion

    I do not believe it is ResetHDA that resolves your issue in Clover.
  23. vit9696

    OpenCore Discussion

    OpenCore does not approach the EC anyhow, likely Clover also does not, at least not from what I know.
  24. vit9696

    OpenCore Discussion

    @beidl, AppleACPIPlatform uses ACPICA, so it should return 2. https://github.com/acpica/acpica/blob/fe061f034dcc521f980d8aa00b4139611d3a2ada/documents/changes.txt#L3474-L3476 https://github.com/acpica/acpica/blob/fe061f034dcc521f980d8aa00b4139611d3a2ada/documents/changes.txt#L3551-L3555
  25. vit9696

    OpenCore Discussion

    AppleALC implements TCSEL reset register functionality (named as ResetHDA in Clover) via alctcsel boot argument or alctcsel device property. Just inject alctcsel <01 00 00 00> into HDEF or pass alctcsel=1 via boot-args, and it should work. To debug this you can always check for "updating TCSEL register" line in the joint Lilu/AppleALC log by adding -liludbgall liludump=60 arguments and then inspecting /var/log/Lilu_x.x.x.txt file after booting macOS and waiting for 60 seconds for the file to save.
×