Leaderboard

I created 2x version of metal theme. But now I see new bugs in Clover related to GUI. Download https://www.dropbox.com/s/mnnot7j5jgrp5jn/metal%402x.7z?dl=0

Hello guys, how are you? I don't know if you had notice, but we have some changes in our Forum. 1 - The double space line are gone, now are not necessary to use Shift+Enter to ignore double line. 2 - The Wiki are back - In the navbar. 3 - The Forum Rules are in the navbar again. 4 - Now to use emojis, you just need type it (e.g =D) and the emoji will appear instantanealy. The Emoticon icon are disabled - Temporary error. 5 - The log in/sign out orange bar has been removed. Now we only have the Log/Sing button at the top menu bar. 6 - Now we have CAPTCHA tool to avoid Spammers All thanks goes to @Jonnie99 and @Fubra Support

Hi @vector sigma, I made the follow change compared to rev 121 public func temperature(_ unit: TemperatureUnit = .celsius) -> Double { var temperature: Double? if let prop = IORegistryEntryCreateCFProperty(service, Key.Temperature.rawValue as CFString!, kCFAllocatorDefault, 0) { temperature = prop.takeUnretainedValue() as! Double / 100.0 } else { temperature = 0 } switch unit { case .celsius: // Do nothing - in Celsius by default // Must have complete switch though with executed command break case .fahrenheit: temperature = Battery.toFahrenheit(temperature!) case .kelvin: temperature = Battery.toKelvin(temperature!) } return ceil(temperature!) } That way if prop=nil then temperature=0 It is not good way but the way there is no crash at as! unwrap. The better will be to keep temperature to be optional Double.

Yes it might , but there are various other settings that are configured by the SSDT and loaded at startup. At this point we are trying with @lelet , @Matthew82 and others to improve and perform Hot-plug on all ports.

Rev 4443 - 4444 Clover correctly recognized the name of all Mac OS series Mac OS X/OS X/macOS and type of macOS installation too.

good welcome enjoy

looks good what not work?

https://www65.zippyshare.com/v/OBeVbKYx/file.html new send me after reboot

Here it is https://www115.zippyshare.com/v/lptaYWhv/file.html Sorry the first not good, this one is good https://www115.zippyshare.com/v/3ZonDtQZ/file.html

AptioMemoryFix.efi.zip

Clover installer has the newest version. But here: Archive.zip

The GUID/etc stuff is not a meaningful difference - the second is just a simplified form of the same device property injection (by Pike IIRC, which skips the Apple _DSM GUID check and not using the DTGP method, which does another check). But the PCIHotplugCapable value does differ; this is merely using PCI hotplugging instead of true OS-level TB hotplugging (e.g. see the NHI in IOReg, there aren't any Tx/Rx packets, while there are many on a real Mac with TB3).

Sources on their way. Seems like not much request for PS2 filevault anymore. Let's give it some time. I'm leaving in 3 hours for a month. I'll have my newly encrypted PS2 laptop with me, so I'll be the first tester of what I did. I'll be able to answer email, but not doing all what I can do on my desktop with a 4K screen and 56GB of memory !. If there is some interest in that, will see when I'm back. @Slice Thanks for having pointed me in the right direction in November. I tried Ps2MouseDxe-64.efi, but trackpad not working. I remember to have correct VoodooPS2Controller for my hackintosh 3 years ago. Looking into that I was able to correct Ps2MouseDxe-64.efi, but mouse pointer is moving very very very slow. Enough to click on the filevault user though. An other thing that will be finalize when I'll be back to my desktop computer. Just for information : I spent quite some time to setup source level debugging with eclipse and VMWare (see picture, when I was looking for a crash in Clover launched in VMWare. It's linux because of a bug in gdb mac.). That is so much easier than putting trace log everywhere ! So, if anyone interested I'll be happy to share to knowledge. The bug I found is : in smbios.c GetTableType16(), at the end, add : // VMWare report 64 memory slots !!! MAX_RAM_SLOTS is currently 24. Crash is PatchTable17. if ( TotalCount > MAX_RAM_SLOTS ) TotalCount = MAX_RAM_SLOTS;

@lelet and everyone, this is amazing! I have been struggling to get anything to hotplug with my Asus Prime x299 deluxe and Asus tbex3 card even though so many people have claimed it to be working. After trying every sort of arbitrary entry, and variation, nothing worked. I have been following this thread for a while and now I just copied the PCI-Thunderbolt section to DSB1 in my SSDt from SSDTv2 as you mentioned, and now I can reconnect only my Apollo, but not my satellite. So exciting! I am fairly new to SSDTs so I am not sure if this means anything, but upon investigating my IOReg vs the iMac Pro IOReg, I noticed this difference. Can this IOPCITunnelL1 be the tunnel that allows subsequent devices to also reconnect? And if so, how can we edit this value? Hoping we can solve this completely! Thanks

Per allegare usa un servizio cloud, dropbox, mega o altro

Hi I try new prerelease and I love it. Good news for future Tinu version: especially possibility to add my own kexts, perhaps in drag and drop.... Thanks. Have a nice day

@onejay09 - Thank you! Your AppleBacklightInjector.kext fixed backlight on my Thinkpad T61 / Sierra. Previously, I was able to control my backlight with Bergdesign's Brightness (annoying, since I had to restore backlight levels after sleep and after boot) and now with your solution my native SysPrefs->Display control works! Nice work! The complete solution for me was Follow your directions to create AppleBacklightInjector.kext and install in S/L/E Apply your PNLF patch Insert my desired default BacklightLevel value in config.plist Reboot Now, everything works except I lose my Ethernet connection when I wake from sleep. To restore, I need to toggle en0 down and up. I'm using AppleIntelE1000e.kext version 3.3.6 which I think has this known issue. My system is as follows: Lenovo Thinkpad T61 Dual-boot Windows 7x64 / OSX Sierra Clover (Legacy) 4439 Penryn T9300 8GB DDR2-800 256GB SSD

We are very close to WWDC 18, so the expeculations are very high. Look at this graphics: One of the big expectations for macOS is be a cross-platform system, to help developers bring their iOS apps to the Mac platform. Let's see... View full article

Mr.Cook doesn't like our post: Tim Cook Insists Merging Mac and iPad Would Result in Compromises

I am starting to think about the versions after TINU 2.0 they will have the clover support, so which are the settings that should i use by default to install clover? of course i will offer dirrent settings options to accomodate different kind of machines and also a manual settings mode which makes you able to choose the settings to install clover manually, the last issue is settings of the clover config and kexts, for that i was thinking about using some pre-made config files and a pre-made kext selection which sould work on most machines (i will mainly use fake smc, null cpu power management and unsolid) but you will have always the option to chosse everthing manually and to edit usingh clover configurator, yor config

and here is the new pre-release: https://dl.dropboxusercontent.com/s/nvzss51qcieynve/TINU.zip Edit: i have reuploaded the source code and the pre-build binaries because of a bug, links are the same

Hello, I wonder if you can have a look into my RunMe files. https://www.dropbox.com/s/1ij6f3jpwdn61kb/Send me MacBook-Pro.zip?dl=1 It's an Acer Aspire S3 laptop, i5-2467M, 4 GB RAM. My biggest headache: Computer cannot sleep. Other things: not sound, no wifi. Thank you very much in advance, EDIT - Details about it: To create this hackintosh, I cloned High Sierra from another S3, i5-3317M, but I couldn't use its CLOVER folder, neither its wifi and audio kexts, it didn't boot. It finally booted, thanks to you, using your CLOVER Install.zip, and now I'm stuck in the DSDT patches section, because this S3 is very different from the other one (the 3rd gen S3 was UEFI, this 2nd gen S3 has BIOS...) and I don't know how to patch it all. EDIT 2: Installing High Sierra 10.13.0 EDIT 3: Done! I got it! Thank you!

Rev 4442 All Clover utility and prePane will be 64 bits since now. We are waiting 10.14 without 32 bit support.

@Alpha22, thanks, your looks fine now. Can be and also due to a wrong logic. Please test this: [removed] I'm working on. running it in Xcode you should see where is crashing. P.S. some code commented and moved, needs a clean up.

as per attached for my savage pc with maybe incompatible processor Archive.zip

XenForo 2.0. Great choice!

Rev 4378-4382 New set of memory fix drivers. OsxAptioFixDrv and OsxAptioFix2Drv reverted to rev before 4368 so without NVRAM support. Let them stay here for history. And sometimes OsxAptioFixDrv is only working version for high warped memory map. OsxAptioFix2Drv is a reduced version without relocation blocks and may not works on some hardware or with older OS version. But this version supported Hibernation while first one no. OsxAptioFix3Drv is a OsxAptioFix2Drv rev 4369 renamed to be different. This version supported NVRAM. More runtime fixes in 4379. This version can be improved by clover crew in future. AptioMemoryFix included in the package is third-party memory fix driver used as is. It is probably better then OsxAptioFix*. Choose it for a first attempt. OsxLowMemFixDrv is also memory fix driver, not improved since rev608. SIC! These 5 drivers should not be used simultaneously! Choose one of them! Clover will be updated for mutually exclusion. AptioInputFix is included in the package now. It is keyboard driver to support FileVault2 for those who have AMI UEFI BIOS.

In case there were some language misunderstandings, I meant that it was not maintained, while remained within clover. For me personally it is much easier to compile drivers with the native edk2 build system, not clover's scripts, since they perform a lot of tuning due to various specialties and edk2 patches required for the rest of the project. It is understandable, but for me it means that whenever I need to build clover I use a vm, so that it does not mess my environment. This was certainly not a best decision when you need to compile and test things every few minutes. So the point of having a separate package is definitely not because I had no write access to the clover's codebase, but because it was more convenient. Also, when AptioFix was developed Clover was pretty much the only UEFI bootloader, i.e. the only project that really needed AptioFix. Now that changed, and even your upcoming CloverV3 would need AptioFix, and as you know, sharing the codebase among multiple projects is done via shared dependencies =)

Ok gentlemen, after some reasonably extensive research we were able to mostly understand several problems preventing the users of AMI APTIO have working NVRAM in macOS. As a result we have a reasonably reliable yet dirty solution. As a side issue we suppose we may have discovered a terrible memory corruption issue due to a of AMI APTIO and boot.efi, which we suppose we also fixed. Some of the information was mentioned in this topic and/or on applelife, we consider it important to give a summary that covers all the details. Especially because during the research the information obtained was very confusing, which led to certain misunderstandings . 1. ASUS APTIO IV Z97 Motherboards Described here: http://www.insanelymac.com/forum/topic/317802-efi-variable-store-on-aptio-v-haswell-e-and-up/page-6?do=findComment&comment=2535040 After the disassembling it was discovered that several APTIO IV drivers including the presented one implement a variable whitelist, and disallow writing anything but the variables from the list. It is unclear whether it was intentional or just an logical mistake, but a most reasonable solution will be to just replace the NvramSmi driver with the working one from a previous firmware and reflash. EFI_GLOBAL_VARIABLE_GUID: Lang, Timeout, PlatformLang, ConIn, ConOut, ErrOut, BootOrder, BootNext, DriverOrder, HwErrRecSupport, OsIndications, PK, KEK, FTMActiveFlag EFI_IMAGE_SECURITY_DATABASE_GUID: db, dbx 2. APTIO V firmwares with working NVRAM Some APTIO V firmwares (pre-KabyLake at least) do not use a new NVRAM driver implementation, but rely on a driver that can be found on older Z87 or Z77 APTIO IV motherboards. For this reason NVRAM works fine on them. Notably the extensive changelog of the NVRAM driver covers a lot of issues that arose during the development. Yet it should be noted that once the firmware was upgraded it is no longer possible to use the older driver, like on Z97 motherboards, due to a completely new stack. 3. APTIO V firmwares with not working NVRAM a) Before explaining the details of the new bugs we have to go back to describing NVRAM issues on APTIO IV. As everyone knows during the loading process: - boot.efi discards all the memory that is not EFI_MEMORY_RUNTIME - boot.efi physically moves EfiRuntimeServicesCode and EfiRuntimeServicesData regions regions to go one by one and zeroes the original area - boot.efi assigns virtual addresses to EFI_MEMORY_RUNTIME regions - XNU maps EfiRuntimeServicesCode as RX memory and everything else supplied as RW memory However, AMI SMM drivers preserve the original physical address of EfiRuntimeServicesData, and use this memory for communication. Since SMM drivers cannot be easily changed, the AptioFix driver prohibits EfiRuntimeServicesData from being moved by marking it as a EfiMemoryMappedIO region. To our surprise the AptioFix driver does not revert "temporarily" changed types back to EfiRuntimeServicesData before starting XNU, which undesirably leads to VM_MEM_NOT_CACHEABLE | VM_MEM_GUARDED flags being used in the XNU mapping, yet it not known to cause practical issues. What did the original solution not care about? There exists a certain FlashDriver that exposes AMI_FLASH_PROTOCOL (755B6596-6896-4ba3-B3DD-1C629FD1EA88). On APTIO IV this protocol is not used after ExitBootServices (if not earlier) by any EFI_RUNTIME_SERVICES, which was proven by RW mapping it without the X bit, yet is part of the EfiRuntimeServicesCode. It was discovered that on APTIO IV AMI SMM drivers have a physical address of one of the static variables of this driver, and they use this variable for write access during all the three calls to NVRAM-related EFI_RUNTIME_SERVICES (GetVariable/SetVariable/GetNextVariableName). Therefore it effectively leads to arbitrary memory corruptions (which happen to be used for RW access by XNU and thus do not trigger a kernel panic with a page fault) when invoking any NVRAM procedures. c) What did APTIO V do? On APTIO V they appear to have additionally changed the implementation to work via a shared SMM/DXE buffer. However, unlike APTIO IV, which used EfiRuntimeServicesData, this shared buffer become a static variable in some driver too. Once again since SMM uses physical addresses to the buffer, after boot.efi moves the problematic driver, it will no longer is able to communicate with SMM. For quite some time (probably due to the lack of the hardware) we thought that the problematic driver was the same FlashDriver just like on APTIO IV. However, this is not the case, and on APTIO V it is some other unknown driver. For this reason we prevented the whole EfiRuntimeServicesCode area from being moved just like with EfiRuntimeServicesData. After we mapped all the EfiRuntimeServicesCode memory as RWX in XNU NVRAM started to work fine. As a result we discovered the memory corruption mentioned in ( due to WP page faults. Summary follows. APTIO IV: FlashDriver RW EfiRuntimeServicesData & force same address → nvram works FlashDriver R X EfiRuntimeServicesCode & force same address → write page fault FlashDriver RWX EfiRuntimeServicesCode & force same address → nvram works FlashDriver RWX EfiRuntimeServicesData & force same address → nvram works RTCode RWX EfiRuntimeServicesCode & force same address → nvram works APTIO V: FlashDriver RW EfiRuntimeServicesData & force same address → nvram does not work FlashDriver R X EfiRuntimeServicesCode & force same address → write page fault FlashDriver RWX EfiRuntimeServicesCode & force same address → nvram does not work FlashDriver RWX EfiRuntimeServicesData & force same address → nvram does not work RTCode RWX EfiRuntimeServicesCode & force same address → nvram worksd) What did we do? Firstly, we prohibited all the EfiRuntimeServicesCode from being moved by boot.efi. It was a tough decision whether to try researching the exact driver not move just it or the entire code area. The choice was made for the latter, because -1- the NVRAM bugs clearly show that AMI APTIO does not support this and -2- if there exist any more write accesses from SMM to DXE we will discover them by triggering a kernel panic (with a WP page fault) instead of just silently corrupting arbitrary memory area. Secondly, we created dedicated shims for GetVariable/SetVariable/GetNextVariableName which unset the WP bit during the execution of the UEFI code. This is safe to do in an SMP environment, because AppleEFIRuntime kext performs a lock call during any UEFI code calls, and thus effectively disables CPU preemption. On the contrary patching the kernel to map all the UEFI memory as RWX is an unnecessary risk, which is furthermore prone to errors due to instruction changes. It should be noted, that it is not possible to perform memory region protection upgrade from a kext either (vm_protect fails due to maximum protection being set to a too low value). The relevant changes for OsxAptioFix2 driver and a prebuilt OsxAptioFix2 driver version, which contains the fix: OsxAptioFix2Drv-WTF.zip Signed off: Download-Fritz, vit9696, and everyone who shared their wisdom and helped to test 06.01.17 4:30 MSK