Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 08/20/2020 in all areas

  1. @fabiosun - I spent a good majority of yesterday investigating software compatibility, including compiling several libraries such as Tensorflow (if you want to really benchmark your CPU - try compiling Tensorflow. It'll run your CPU at 100% for a good 20-30 mins. Peaked at around 178F for me.) I think I may have come close to having core AMD compatibility with macOS for applications. Most macos applications (from what I researched) use Intel's MKL library for CPU acceleration for graphics. This includes Adobe suite software. Previously, MKL was an Intel-only feature, but because of some trouble/pressure, they've since open-sourced it. Now it's called oneAPI. It can be compiled with amd64 CPU architecture, which I was able to do, and installed it successfully on my bare metal Catalina. (compiled folder attached via link - it's over 50mb) Some more information related to MKL and AMD/Intel CPU architectures by Puget Systems - MKL was basically a feature that intentionally crippled AMD CPUs that most developers just ended up using. It's likely safe to run Big Sur/Catalina echo -n 'export MKL_DEBUG_CPU_TYPE=5' >> ~/.zshrc Mojave/Previous echo -n 'export MKL_DEBUG_CPU_TYPE=5' >> ~/.profile Now, what I'm currently unsure of, as I haven't yet tested it is: a) whether or not this new MKL library actually replaces the existing MKL b) whether the MKL libraries are universally linked to the host or have existing MKL libraries within their own app c) whether this new MKL is compatible with macOS apps d) do we need the other MKL libraries as well? Installation Logs Download Link to precompiled MKL-Dnn
    4 points
  2. @iGPU please find attached requested IOReg file for the Gigabyte Xtreme motherboard. We also need a different network kext as we have dual intel 10GB chipset. The (modified) kext is attached. @Jaidy, sound for me is working. I have not tested the onboard headphone jacks etc as I use a Dell AC511 USB Soundbar (it matches my Dell monitors and is designed to clip onto one of them. You could try changing from alcid=1 to alcid=11 or alcid=16 in the boot-args of your config.plist file. My previous Gigabyte boards (Z370 Gaming Ultra, Z390 Designare and Z390 Master all worked with either 11 or 16. As for your keyboard, have you tried going to System Preferences - Keyboard and clicking "Change Keyboard Type..." It should then get you to press a key or two to verify it. I don't use a trackpad so can suggest anything for that. Gigabyte-Xtreme.zip SmallTreeIntel8259x.kext.zip
    2 points
  3. Ok, I've updated the EFI to add the kext and take into account your IORE. You need to do something different from the Designare mobo besides the kext file (which is off by default). In the ACPI section, you mostly want to use the MSI and not the SSDT for the Designare as that will cancel your BT. Instead use the sections shown below. The two new entries for the GB Xtreme are #24 and 25 (and correct to Xtreme rather than Extreme as in image below). I don't think you want to enable the SSDT-GFX's.
    1 point
  4. per chi serve compilato OC 061 comprensivo di kext beta, resources popolata e audio IT https://www.macos86.it/files/file/20-opencore-efi-maker/?do=findReview&review=32
    1 point
  5. Ah, I didn't know you were using OC Configurator. I don't use it (I only use to generate SMBIOS data). I had too many weird things happen in past and spent hours trouble shooting more than one corrupted config.plist file (you can find the problems, but you need to study the file in text mode which is laborious). The developers of OpenCore do NOT recommend using OC Configurator. Truly, the one I prefer is PlistEdit Pro. (Even Xcode can foul up the config file by substituting 'real' values for 'integer' values, leading to boot errors.) I've uploaded more changes this morning to the EFI folder on GitHub with the latest OC commit. It boots just fine. After using it, do a re-set of your NVRAM. Also, remember you'll need to adjust the ACPI section as I've extensively renamed SSDT files to allow us all to use them, no matter the mobo manufacturer, in what I think is a more coherent fashion.
    1 point
  6. mi par strano che con una sbirocciata di kexts arrivi a desktop e solo con gli essenziali, si blocca... scarica le release piΓΉ recenti dei kexts, anche beta, ho uppato ieri sera LILU e plugins in download poi vedi un po' nche dicono le guide, la nostra e quella di dortiana, magari basta una impostazione nel config per cambiare dal giorno alla notte
    1 point
  7. non saprei... vai di update BSbeta5 se poi haio problemi, aggiorni OC e kexts trovi tutto nella sezione downloads
    1 point
  8. ok i figured out my problem same refi same bios settings Catalina is working perfect also with my patched Nvidia web driver So I have to try a different way (maybe) in High Sierra
    1 point
  9. Preboot dopo un po' torna a posto da solo magari installa intel power gadget e va a posto subito
    1 point
  10. fabiosun, On bare metal, the CPU scores are the same as under Proxmox with Geekbench or Cinebench 20. With Luxmark, the scores for Radeon VII are the same under bare metal and Promox (and only Luxmark uses both GPUs). only with Cinebench 15 do I see a decrease of 50%. So maybe a problem with Cinebench 15?
    1 point
  11. Se vuoi cambiare il nome a PREBOT, leggi questo. Ciao
    1 point
  12. This weekend when working up a config.plist file to boot into Big Sur, I would see this if WEG is active. It is okay to leave WEG active, but add -wegbeta to boot arg. I've stressed adding npc-0x2000 several times on this thread whether or not "Above 4G decoding" is enabled or not. The kexts I've loaded with the EFI on GitHub should cause no problems. Overall stability and random reboots will occur if Energy Saver is not disabled. I posted this earlier in this thread and on the GitHub site, Section 7.
    1 point
  13. OC 061 appena termina la compilazione, lo trovi nelle reply qui https://www.macos86.it/files/file/20-opencore-efi-maker/ LILU e plugins sono giΓ  in download beta https://www.macos86.it/files/file/7-pacchetto-lilu-plugins/ PS: attenzione a certe nuove impostazioni di OC 061 beta https://www.macos86.it/topic/3109-pre-release-macos-big-sur/?do=findComment&comment=82445
    1 point
  14. For everyone else recently posting - bear in mind that the bare metal is still not 100% stable. My installation suffered falling into an inexplicable state where the initial EFI (which I used as a rescue reference) and on-disk EFI became severely unstable - random reboots or even failure to load. Something in the OS main disk state changed. Haven't had time to debug - I think I will do a clean reinstall, but I would not trust the bare metal for a production environment (even though so far I am the only one with this issue). On the other hand Proxmox is 100% solid. Also, I am yet to see any performance benefit other than a 3% edge in Geekbench multicore, but 5% lower single core for that matter (I don't trust at Geekbench as the best app to measure with). I just ran a Cinebench out of my Proxmox - matched bare metal with a score 21468. Anecdotally, Proxmox is also more stable with apps. If you do a TRX40 hack, I would definitely keep Proxmox as a production base and bare metal as experimental until the community (and @iGPU as an active member) figure how to make it a bit less cumbersome and maybe stable.
    1 point
  15. OC 060 Z370 BigFart missione compiuta
    1 point
  16. 1 point
  17. @Jaidy I've just checked the USB on my key ring and I have a copy of my EFI on that - I think it is the latest but if not I believe it does work on our MBs. Let me know if you try it and it doesn't but here it is anyway. As I said, it still needs optimising and some kexts etc removing. EFI.zip
    1 point
  18. Attached are 2 SSDT for cancelling what I've renamed to XHC1 and XHC2. They don't help, but I'm posting if you want to learn how to cancel devices. If you were to use, you want to remove the re-naming sections for XHC1 and XHC2 from the other SSDT file. As for stability, I've left the computer running all day and night and it seems fine. I'll recheck today and if okay, provide a list of settings, but what I'd updated in the uploaded config.plist file that will boot into Catalina or BS has what seems to be stable settings; but I'll re-visit the settings later. As for BIOS, I've left: ErP Ready, disabled; Above 4G decoding, disabled; and both IOMMU and SVM, enabled. EDIT: Above is obsolete: a proper MmioWhitelist is necessary for Shutdown (and being aware of attached USB devices which can force a re-boot).
    1 point
  19. se non Γ¨ presente -radvesa Γ¨ flaggato radeondeinit e hai 8GB di vram dovrebbe essere OK oramai sono anni che hai hack.. sempre al primo giorno di scuola? metti AppleALC nei kext in other ed inserisci il boot-arg alcid=7 dove 7 Γ¨ uno dei layout da provare la mappatura era giΓ  fatta, basta fare copia e incolla, hai le vecchie EFI, devi solo fare uguale mettere ssdt in patched aggiungere il suo nome in sortedorder aggiungere in drop tables ssdt lengt come ti ho detto, basta vedi vecchio config...
    1 point
  20. Was able to install Catalina 10.15.6 (iMacPro1,1) bare metal with a new NVMe drive, and the stock EFI folder. One minor issue that some might run into if you're not writing over Proxmox is that after the first stage of the installer that goes back into the "Install OSX" reboot, if your config isn't mapped to your other storage devices, the installer will fail. In my case, I ended up just unplugging them. What works now in Bare Metal: WiFi from the PCIe Adapter (BRCM4360 - which confirms it was a Big Sur issue) RAM Modules set and registered properly. What doesn't work now: Ironically the Bluetooth, as I also have AX200 showing up, despite disabling it in BIOS. Minor benchmarking shows a slight dip in performance, but I'm willing to take that performance dip in exchange for system stability.
    1 point
  21. fabiosun, I got all SSDT working! I'll update all SSDT shortly. Here is result of proper TB, Alpine Ridge: After hot-plugging an external TB drive: Hackintool:
    1 point
  22. Wanted to give back, so I worked on a python script to simplify how we can get all the information on our Proxmox configs. https://gist.github.com/trisongz/05c0681583a97d442538c8737c74b8b5 It's not the cleanest, but it works for me, and hopefully makes our lives a bit easier with debugging. You can copy that file or create a new file in your Proxmox and call it with python3 vmcheck.py --vmid [your VM ID] It should produce results like the following:
    1 point
  23. in this weekend I have flashed many firmware found on the net (GitHub) I will put here the exact name of these files but not the direct link that you can find easily googling 1) TitanRidgeMacOSFirmware.bin (DSM2 firmware I think) 2) TitanRidgeNVM23-Elias64Fr-Mod.bin (Eliasfr caseSj firmware I think) 3) TitanRidgeNVM43-Elias64Fr-Mod.bin (Eliasfr caseSj firmware I think) 4) original v43 firmware (stock in my board) 5) original v50 firmware (updated via Gigabyte windows updater utility) fast analysis : with all firmware I have the same driver loaded in windows, but with all of these I can't see any device connected to TB output, I have no thunderbolt devices and I have tried only with two different USB type c devices with 1) in OSX I see only 15eb if I do not boot before in windows and I have a pretty full ioreg with all we need..with bad naming with 2) I have the best result in OSX, no need to boot in windows before and I have the pretty same IOREG (full of stuff) with always bad naming with 3) I have a minimal ioreg similar to original not patched version (identical, and this le me think it is an original firmware) with 4) and 5) the same minimal ioreg in OSX I have verified thanks to @thenightflyer for this that I have the same his ioreg in many parts except for naming and some voices, I think because he is on x299 system which support better ssdt part Any idea to how solve this puzzle will be accepted πŸ™‚ attached 2 images for clarification, on the right x299 working ones
    1 point
  24. Hi people.. I will show some basic informations to start configuring OpenCore bootloader. This is EFI's structure EFI β”œβ”€β”€ BOOT β”‚ └── BOOTx64.efi └── OC β”œβ”€β”€ ACPI β”‚ └── Custom β”œβ”€β”€ Drivers β”œβ”€β”€ Kexts β”œβ”€β”€ OpenCore.efi └── Config.plist As you can see inside EFI folder we have two nested folders BOOT and OC ... This is a structure very similar to Clover bootloader one, inside BOOT we have BOOTx64.efi, this file is mandatory to have a working boot. Inside OC we have all necessary folders like ACPI,Drivers,Kexts inside ACPI we cand find Custom folder, this will be the place where we have to put our patched ACPI if our hack needs them. In Drivers folder we have to put all drivers we need to boot. Important NOTE:No x64 extension is needed for them You DO NOT use Clover's drivers , in OpenCore they are different (vBox is an exception alternative to HFS.plus Main Drivers are: AptioMemoryFix ApfsDriverLoader (mandatory if you have a disk in apfs format, otherwise you do not need of it HFS.plus or vBox Kexts: Obviously , here we will put extra kexts Open config.plist with a PlistEditor or with Xcode if installed in your system for good English translation.
    1 point
  25. provo con OC 060 e kext stable.... vediamo che succede 🀞🏻
    0 points
  26. ritorni bambino quando la mamma ti portava al luna park e ti comprava lo zucchero filato πŸ€— non installare piΓΉ IPG! nelle tue mani, Γ¨ uno strumento di distruzione di massa 😱
    0 points
  27. No, I've not tried. I have performed an update for Catalina and that went well. I'll attempt an install later on a spare drive.
    0 points
  28. urca la peppa! ci andiamo leggeri con gli aggiornamenti.. 7Gb
    0 points
×
×
  • 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.