安装好黑苹果后有许多要完善的地方以及使用中会遇到各种问题，这里记录一些偶然解决的问题的方案以及过程。
USB问题以及睡眠自动唤醒【2018.5.2】
起因是插了U盘后发现提示需要为USB配件提供电源而导致USB设备无法使用，在远景搜索后有提示说吧USBInjectAll这个驱动删掉，删掉后重启发现问题解决但USB3.0达不到5G而且摄像头也不能加载，于是这并不能当做解决方案，后来就在想是不是因为DSDT的原因（因为用的是论坛大神帮忙修改的解决自动唤醒的DSDT），可是发现换回原来的DSDT也是不行，于是就回想在USB正常之前做了哪些改动：
- 修改了CPUfriend和CPUprovider。
- 升级了Clover版本。
- clover勾选了
change EC0 to EC、change H_EC to EC两个补丁
于是一步一步复原，复原第一步时，发现删除了两个驱动后变频并没有受到改变，和删之前是一样的，之前误认为修改生效，事实证明这两个驱动对本电脑是有负面影响的。复原第二步发现依然提示需要为USB配件提供电源，于是复原第三步，重启发现问题解决了。而令人意外的是，晚上睡觉之前睡眠第二天早上也没有自动唤醒，说明自动唤醒的问题也解决了。
总结：
- 变频是原生加载了的，虽然原因未知
自动唤醒是受两个CPU驱动的影响（后测试是因为电源管理的唤醒以供以太网访问选项引起的）- USB配件需要电源时因为误勾选了那两个clover补丁
睡眠唤醒无声【2018.5.3】
睡眠唤醒无声，看到了这样一篇帖子：Realtek ALC282使用applealc applehda原生声卡并解决睡眠唤醒无声问题，于是从AppleALC的github项目主页上下载了最新版本（1.2.6），而当前用的是1.2.3版本，看了更新日志，在1.2.5就已经在ALC驱动当中加入了解决睡眠唤醒无声的CC以及EAPD的驱动，于是把clover的ALC驱动更新到了最新版，经测试，不删除原有的CC会导致唤醒依旧无声，在帖子当中也看到了，要想利用CC解决唤醒无声的问题还需要修改CC的参数。
总结：
- AppleALC驱动在1.2.5后更新了CC驱动，可以直接解决睡眠唤醒无声的问题而不需要也不可以同时存在CC驱动。
- CC驱动需要配合自身声卡的参数才可以生效。
变频问题【2018.5.5】
- 由于原来的X86PlatformPlugin签名验证失败，所以更换了原版的IOPlatformPluginFamily.kext，修复权限后解决。
- 先更换了7.2的机型使用ssdtPrGen.sh生成了变频ssdt，然后换回了9.1的机型（只有9.1的机型开机不卡顿）
- ssdtPrGen生成的ssdt和XCPM.ssdt（设置PluginType=1）的效果相同，都是为了加载两个x86以及完善电源管理面板。
- 测试中发现只有配合CPUFriend和CpuDateProvider才可以正确加载x86，而变频效果受后者驱动的影响。
- 目前采用的变频方法为
- SSDT-XCPM.ssdt和CpuFriend.kext以及CPUDateprovider.kext的配合。
- 通过使用不同的机型plist生成不同变频效果的CpuDateprovider.kext。
- 目前采用修改过最低频率为800MHz的12.1的变频数据。
- 更新：测试MBA7.2并修改最低频率为800的变频数据更合适。
亮度最大值问题【2018.5.15】
之前在搞10.13的亮度调节时参照了这个帖子移动版Intel核显使用hotpatch实现亮度调节的方法，后更新了第二版。再详细看过教程以后，发现1.大部分笔记本无需注入EDID于是删掉，2.之前放入AppleBacklightInjector亮度不能够最大的原因和ig-platform-id有关，于是想到当前显卡驱动的方式是SSDT-IGPU自动注入的，查了FB数据发现用的是0x16260004，于是删掉了这个ssdt，并在注入了clover推荐的id：0x16260006.重启，亮度达到了最大值，之前采用的方法是删除AppleBacklightInjector驱动，但亮度调节档位不均匀。
总结：使用ABI驱动来调节亮度的话一定要使用正确的ig-platform-id，否则会影响最大亮度值。驱动要安装到S/L/E或者L/E，安装在clover需要将inject kexts设置为Yes。
更新10.14.4【2019.4.4】
在10.13.6下稳定体验了将近一年的时间了，今天忍不住更新了10.14.4（MacOS Mojave）。虽说更新内容并没有什么吸引我的地方，但是作为强迫症的我一向习惯保持软件为最新状态。
在U盘都没有的情况下，我真不知道我哪来的勇气去直接更新。但是令我没想到是，整个过程竟是如此顺利：
- 更新clover到最新版本（直接下载了driver64.efi替换旧版本即可）。
- 更新驱动到最新版。
- 到应用商店下载macOS Mojave，点击安装，一路next。
- 很幸运一路没有五国。
- 开机显卡正常，WiFi正常，修复权限重建缓存后声卡正常。
- 变频无法最低800，后提取了新的MacBook7.2的变频文件，更新了CPUFriend.kext，并按照以前的帖子重新制作了CPUDateProvider.kext，开机后恢复最低800频率。
更换显卡驱动方式以及亮度调节方式【2019.4.8】
目前各种显卡大多都依赖者WhatEverGreen这个驱动，今天也想通过这种方式来驱动我的HD5500。于是就仔细浏览了WEG的官方使用说明，结合黑果小兵关于Hackintool的教程成功驱动了显卡，并应用了最新的亮度调节方法。
以下只是概述，具体操作还要按照上边两个帖子一步一步来。
以前的驱动方法：
- 注入合适的ig-plateform-id，对于HD5500就是0x16260006（HD6000的id）
- 使用ssdt-IGPU自动注入（后测试此方法不完美，影响亮度调节的档位及最大值）
现在的驱动方法：
- 配合WEG驱动，使用Hackintool在clover的Device中打补丁，实际上就是注入显卡的各种数据，目前用到的有：ig-plateform-id、修改显存2048M、修改DVMT值、禁用eGPU。
对于BIOS的DVMT Pre-Allocated值大小32M而又无法调节的机型， 需要采用一些方法：最早是通过clover的kexttopatch打补丁，每次更新需要换补丁；后来通过InterGraphicDVMTfixup驱动来防止内核崩溃；现在采用的方式是Hackintool在clover的Device中打补丁解决。
以前的亮度调节方法：
- 安装AppleBacklightInjector.kext驱动。
- kexttopatch打补丁。
- 放入SSDT-PNLF。
现在的亮度调节方法：
- WhatEverGreen.kext。
- 勾选AddPNLF的DSDT补丁与SetIntelBacklight, SetIntelMaxBacklight两项，无需为其赋值，Clover 会根据相应的处理器型号自动适配。要想亮度调节完美，同样需要选择好最合适的ig-Plateform-id。
终于对我的ar9565蓝牙死了心【2019.4.9】
算一算折腾黑苹果也已有两年的时间了，在不断完善黑苹果的路上也算是经历了众多坎坷，一次一次的尝试，一次一次的失败，不断从失败中寻找经验，从而使我在这个过程中学到了不少Hackintosh的经验和技巧，虽说目前大部分硬性要求已经达到，可是有一个问题一直困扰着我，那就是—-蓝牙，下面就说一下我关于折腾蓝牙的部分经历吧。
说起蓝牙，那必须得先说一下无线网卡了。我这无线网卡折腾过程可谓是一波三折。
记得第一次接触黑苹果的时候是2017年5月份，那时候是10.12.2的系统。安装过程就不说了，那时候了解到我自带的RTL8723BE无线在黑果上无解，如果想用无线那就必须得更换无线网卡，可就在我考虑要换什么无线网卡的时候，又了解到了惠普电脑的BIOS有白名单限制这回事，也就是说如果我想换无线还得刷BIOS，本身风险就很大，再加上网上有没有我这个机型刷BIOS的相关教程，所以我就没再尝试了。直到后来听说有USB无线网卡这个东西，就立马在某宝上定了一个支持黑苹果的，买回来确实可以用，这是我第一次在macOS上用到WiFi，但是各方面都不尽人意，尤其是网速，离得稍微远一点就特别慢，比内置的效果差太多，可是也没别的办法啊，所以就将就了。
第二次安装黑苹果是在2018年的5月份，安装的版本是10.13.6.中间也是折腾了好久，这是我无线网卡的第二次进展，起因是帮室友的华硕安装黑苹果后发现他的无线网卡居然可以驱动，在论坛上搜了几篇教程后成功把他的AR9565网卡驱动了，WiFi没问题，蓝牙可以检测到硬件，不过搜不到设备（这个问题是可以解决的），因为他不用蓝牙，所以也就没再帮他折腾了。这个时候我突发奇想，想亲眼见识一下惠普的白名单限制到底是怎么一回事，于是把室友的无线网卡拆了装在我电脑上，可是奇迹发生了，电脑竟然顺利的开机了，并且在Windows下WiFi蓝牙一切正常，再进macOS，WiFi同样可以驱动，但是蓝牙却检测不到设备。经过一系列的努力最终以失败而告终，但是有WiFi用了岂不也算是一个很大的进展了，于是在某宝购买了全新的AR9565······（日后更新）
修复开机登录界面鼠标卡顿【2019.4.12】
今天又是值得纪念的一天，因为刚刚解决了从10.3到10.14一直困扰着我的问题————只能用MacBook Pro 9.1的机型，别的机型开机登录界面卡的不行，体验极差，但是我的显卡最合适的机型是MacBook Air 7.1/7.2 Macbook Pro 12.1；
起因是听说机型的设置会影响到USB的完善，所以想着一定要先把机型设置的问题解决了，于是我就又回到论坛看看有没有新的解决方案，经过对多个帖子的分析，确定了是HDMI port的锅，其中一篇帖子说的非常详细，http://bbs.pcbeta.com/viewthread-1751631-1-1.html，原因就是Framebuffer里定义的接口数大于实际接口数，系统就会不断去扫描不存在的接口，导致卡顿。于是我就去找屏蔽接口的方法，论坛里的方法基本上都是通过clover打补丁来限制HDMI接口数，可问题是这些补丁都是10.14之前的，突然又感到绝望了。而这个时候脑子想到了port limit这个词，感觉特别熟悉，然后打开了Hackintool，去补丁里一看，还真有个Framebuffer port limit，但是不知道有没有用，管他呢先试试再说。于是备份config，更换机型，打上补丁，开机······流畅的登录界面又回来了哈哈哈！成功换回了我的MacBook Air 7.2机型。
解决EC0 to EC补丁打上就无法开机的情况【2019.4.12】
在定制USB的过程中有个步骤是打rename EC0 to EC的补丁，但是我只要打上这个补丁，就会开不开机。后来想明白了hotpatch的原理，其实也就是从原始dsdt中找到某个字符的hex值，通过替换数值来改变某个变量的名字。于是我打开了我的DSDT，搜索EC0，发现有51个结果，而其中有50个都是正常的变量名，只有一个是一串16进制的数值中所包含的EC0，于是我点击replace all发现这个数值也被改变了，而数值的变动影响是非常严重的，于是我把这个数值中的EC0排除，替换其他EC0为EC，保存重启，顺利进入系统。因此，hotpatch一定要避免“误伤”。
后不再采用手动修改dsdt的方法了，因为找到了rehabman的一个hotpatch，同样是EC0 to EC的补丁，但是和Hackintool的补丁并不一样，Hackintool的补丁仅仅是字符串完全的翻译，而rehabman的补丁是EC0_ to EC_ ,仅仅是了个下划线，效果就完全不同了，很好的避免了误伤的情况。但是很显然在dsdt中并不能搜索到EC0_,可为什么这个补丁可以找到EC0呢？看以后能否找打答案吧。
关于USB的一些经验猜想【2019.4.15】
之前一直不明白为什么我的电脑明明只有一个USB3.0插口，但是我的所有设备只要连接到电脑都会挂载到USB3.0总线上，本来以为是Mac没驱动好，可是在win下边也同样如此。后来看过一些USB相关的教程，了解到这是采用了UEFI新型启动方式的原因，也就是intel的USB3.0技术，USB2.0叫EHCI，USB3.0叫XHCI。BIOS启用XHCI模式 后会将所有的2.0以及3.0设备同时挂载到3.0总线，2.0的设备命名为EHC1和EHC2，苹果则是EH01和EH02。因此如果BIOS启用了XHCI，那么EH相关的补丁也就不需要了。新型的UEFI启动会把所有的USB设备挂载到USB3.0上，所以说Mac下的USB设备挂载到3.0下是正常的。
在完善USB驱动的时候总会看到教程里边让打各种hotpatch的补丁，现在对于这些补丁的理解是，苹果机器在不断更新换代的过程中可能会更新各种驱动以及ACPI设备的描述命名，只有把非苹果的电脑的相关变量名改为白苹果的才能使OS的驱动和dsdt相互对接，从而正常工作比如EH01、EH02、XHC，这些都是白苹果下的变量名。
有时候会遇到USB配件需要电源的情况，这个其实就是上边说过的机型的设置会影响USB的驱动，可能会造成无法为USB提供电源的情况。还有一个最重要的原因就是EC补丁，从10.12开始macOS开始使用EC作为嵌入控制器，而大多数PC使用的是EC0或者H_EC，所以说要把相关变量命名为EC才能使AppleBusPowerController正常加载，这个驱动是给USB加电的前提，用来注入电源属性。而下一步才是SMBIOS的设置会影响到USB电源的问题，IOUSBHostFamily Info.plist中可以看到，缺少较新的SMBIOS。如MacBookPro9,1，iMac17,1和MacBookPro13等。这些模型必须使用不同的方法进行USB电源属性注入–对应机型的USBX，Hackintool可以生成。详细信息请看：https://www.tonymacx86.com/threads/guide-usb-power-property-injection-for-sierra-and-later.222266/ 。
起死回生的AR9565【2019.4.16】
新购的BCM94352HMB已经在路上了，所以此刻的我已经放弃折腾我的AR9565了，我断定蓝牙问题是因为这个9565与我的主板不兼容（尽管通过淘宝了解到只要没有白名单，接口对上，那么基本就是兼容的）。
今天在刷帖子的时候，无意看到了这么两篇帖子：
[教程] 装完系统后的一件事，Clover Acpi hotpatch给机器打补丁。
看完这两篇帖子之后，才明白了hotpatch的实质作用：按照白苹果的命名规则给dsdt重命名使驱动和硬件完美对接从而保证系统的正常运行。
既然这样，那么只要是适用自身dsdt的补丁岂不是都可以打，而且可以说百里无一害。于是我开始按照第一篇帖子的教程给我的dsdt打补丁，把每一个能在我dsdt中搜索到的名字都进行了重命名，并且附加了相应的ssdt文件，然后重启。
期间在rehabman的帖子中发现IRQ补丁可以通过clover的fix功能实现于是移除了我dsdt的IRQ补丁，在clover的fix中勾选了
FixHPET、FixIPIC、FixRTC以及FixTMR四个选项，开机声卡正常。
本以为系统以及足够完善，开机应该不会有太大的变化，可是奇迹出现了，蓝牙图标居然出来了，AR9565驱动了！尽管搜不到信号，但这是固件上传不成功导致的，通过win热启动就好了。
仅仅是打了hotpath补丁，没想到就解决了困扰了我这么久的问题，可是具体是哪一个hotpatch解决的，我并不清楚，本来以为是我的EH01和EH02这两个补丁少了ssdt的配合，可是移除了ssdt蓝牙依旧可驱，也或许是某些hotpatch的共同作用吧，不再纠结于此了。至少现在可以确定我的蓝牙USB通道现在没问题了，为下一步的BCM94352HMB做好了基础。
另外还有些心得请看这篇帖子：http://bbs.pcbeta.com/viewthread-1812424-1-1.html
完善亮度功能键【2019.4.17】
目前用了键盘驱动后各项功能键都正常，除了两个亮度调节功能键。
今天在论坛看到了一个brightkey的ssdt，它的作用就是直接修改dsdt中快捷键（_QXX）的method来调用亮度调节。于是在dsdt中找到了我的两个亮度调节对应的是Q11和Q12，键盘的名称是PSKB，然后再brightkey的ssdt中修改对应参数。不过重启后还是不行，后来直接将ssdt的方法写入了dsdt，重启后依然无果。后来在设置快捷键的时候发现两个按键变成了F14和F15，于是插上USB键盘，呼出了亮度调节快捷键设置的面板选项，将亮度调节快捷键设置为F14和F15，成功实现了亮度调节功能键。
后来了解到通过ssdt改写dsdt中设备方法的时候要使原来的方法无效才行，于是通过hotpatch把原来的Q11和Q12改成了别的，实验成功，避免了修改dsdt。
更换BCM94352HMB以及定制USB3.0【2019.4.18】
更换BCM94352HMB的过程见这篇帖子：最终还是入手了BCM94352HMB，顺便说一句，真香！
笔记本定制USB要简单许多，因为端口较少，不会有端口限制。所以直接照着win下的端口定制了。
我的电脑只有一个USB3.0的接口。蓝牙摄像头以及连接到3.0总线的2.0hub都要设为内建。对于3.0的接口，插入2.0设备和3.0设备时候走的虚拟端口是不一样的，于是用3.0的U盘插入3.0的口，发现我的对应的是port12，插入2.0设备时候是port1，直接用Hackintool把对应端口设置好：
port1：USB3.0的2.0虚拟端口（USB2）
port2：USB2.0hub（internal）
port3：USB2.0hub（internal）
port4：蓝牙（internal）
port5：摄像头（internal）
port12：USB30.的3.0虚拟端口（USB3）
把生成的USBport.kext放入clover引导，删除了USBinjectall驱动，开机一切正常，USB3.0可以5G，插入不同设备走不同的虚拟端口。
EC0 to EC 又换回了hotpatch方式【2019.4.19】
之前发现Hackintool的这个hotpatch会使我的dsdt出错后，采用了直接在dsdt中查找替换的改名方式，现在发现rehabman的EC0_ to EC_补丁很完美，于是不再修改dsdt中的EC0，改用hotpatch方式。
截止目前dsdt还剩下一个instant wake补丁，别的都通过hotpatch方式来完成了。
采用MBA7.2的原生变频【2019.4.21】
经过多次试验，发现采用和SMBIOS相匹配的变频效果是最好的，因此不再需要CPUFriend两个驱动了，系统直接调用MBA7.2的变频文件，不再修改最低频率，按照白果的1300来了。发热并没有增加很多，可能功耗会少许增加，但带来的是速度的提升和噪音的减少，风扇不会再像以前那样突然间猛转，变得稳定了许多，档位也很均衡，用Hackintool测试得到的结果是1300、1400、1500、1600、2000、2100、2200、2500八个档位。
彻底摆脱dsdt patch【2019.4.23】
发现定制了USB后（蓝牙摄像以及USB3.0总线上的2.0hub都设为内建）不需要再打instant wake的补丁了，不会睡眠秒醒了。现在可以实现鼠标唤醒了。目前所以的dsdt补丁都由hotpatch来完成了，patched文件夹已经不再放入dsdt了。
关闭BIOS在解锁模式【2019.4.26】
今天又解决了一个超大的问题——开进自检提示在解锁模式。
虽说此问题并不属于黑苹果的范畴，但一般很少出现此类问题，所以也就记在这里吧。
自从第一次修了电脑以后，拿回来开机就变成了在解锁模式下，每次开机自检上边就会出现一行小字，“在解锁模式”，英文是：manufacture programming mode is in unlock mode。看着难受不说，最重要的是开机时间至少慢了5秒钟。可是在网上也找不到解决的办法，都是说要返厂有保密工具才能解决此问题，所以就忍受了这么久。
可是今天无意在贴吧看到有人回复了解决方案，用HP官方的BIOS configuration Utility，可是下了最新版本的BCU，然而按照操作生成的BIOS设置文件里并没有教程里所说的哪一项，于是我又绝望了。抱着试试的态度，我又找到了原文出处，并下载了教程里提供的版本连接，安装后再次按照教程操作，没想到真的出现了manufacture的选项，于是按照操作一步一步来，最终设置成功。开机真的不再是解锁模式了，进入引导的速度也大大提升，简直不要太爽！
恢复了BIOS的序列号等信息【2019.4.27】
这次的问题还是因为之前修电脑导致的，笔记本在维修中如果需要刷新BIOS之类的操作的话，会导致产品信息的丢失，包含序列号、机型、主板CT码、UUID、PCIID等信息，也就是DMI。今天在网上了解到这些信息是可以重新注入的，需要借助HP的DMI工具—-NBDMIFIT。在网上找了很久没找到，最终在hpfocus社区获取到了。这个工具必须在纯DOS环境下操作，但是用HP的U盘格式化工具无法添加DOS启动，提示有写保护。于是又在网上搜寻方案，最终找到了DOS的镜像，然后通过UltralSO刻录到U盘，再从U盘启动就可以了。最后在电脑背板获取到了相关信息，然后写入到BIOS，成功恢复了DMI信息。
Clover引导转OpenCore引导【2020.3.10】
前几天升级了10.15.3的系统，一开始直升失败，系统安装完后进不去系统，以为是EFI不能用了，于是我又去更新各种驱动，没有了Mac环境配置起来如此之麻烦，可是不断测试后依旧无法进入系统，最后实在不行了我又去下了黑果小兵的镜像制作了安装盘，安装完成后顺利进入系统，用之前的EFI也没问题，但是为了之前的数据，我又从时间机器中传输数据到了新系统，可是漫长的等待后，数据传输完成后重启后再次无法进入系统，然后我猜测是之前的某些数据和新系统有冲突，于是我又重新全新安装了一次，不再传输旧的数据，果然，再重启也正常了，上个版本的EFI基本上没问题，只是升级了clover和几个重要驱动，唯一大的变化就是BCM94352HMB的蓝牙需要用新的驱动了，也就是由之前的二代驱动升级到了三代。各项功能正常使用。日常使用和上个版本差别不大，新的功能我的配置都不支持，所以还是有点后悔升级的，但是强迫症吗，能新就新，就这样用着吧。
经过一阵子的系统升级的折腾，发现论坛的黑友都在纷纷转向OC引导，于是就抱着学习的心态去了解了一番。clover转OC有几点原因，很多驱动都不在对clover做兼容性测试了，也就是停止对clover支持了；另外OC的轻量化和高定制化也是一大优势。
在看过黑果小兵的opencore精解后试着去配置了一套EFI，可是一直进不去系统，后来分析可能是没有关闭SIP，然后我又注入了太多的设备属性，导致的Panic。于是进一步对plist和ssdt以及驱动进行了精简，果然之后顺利进入系统。
其实clover转OC也不是特别复杂，只需要把之前的ssdt，hot patch，kext，kernel patch，设备属性等数据按照OC的规范迁移即可，在完善OC引导的过程中遇到了几个小问题。之前定制的亮度调节快捷键失效了，后来找到了新的ssdt，替换后正常；睡眠唤醒后需要点一下鼠标屏才会亮，之后发现有专门解决这个问题的ssdt，加入后即可。
在调试的时候发现了一个之前一直困扰着我的问题的答案，在10.13的系统的时候，有一次打完hotpatch补丁后意外发现一直无法加载的蓝牙硬件居然自己出来了，由于当时添加了太多的hotpatch，而我又不知他们每个的作用，于是一直到最后我也不知道是哪个补丁起了作用。今天在配置OC引导的时候，看到帖子里说OSI（操作系统补丁）如无必要，不建议加入，于是我就删除了这个补丁，可是到我开机后才发现，蓝牙硬件没了。之前怀疑过很多补丁，但一直觉得肯定不是这个，没想到啊！后来看了对这个补丁的解释是，有些硬件受系统限制则需要此补丁，我推测我这个蓝牙硬件就是有这个限制。
折腾黑苹果真的很累，但又痛并快乐着。从今天起，考上公务员之前不在碰黑苹果了，立贴为证！