I did use the auto-upgrade and it worked fine. I didn't see the start of this thread so I don't know if this is specific to something or in general. How long will this issue persist as I have a video going out on this.
When HackinDROM updates our
config.plist it looks for differences between the XML schema of the current and new versions of OpenCore. If some attributes were
added or
deleted, or the "
type" (i.e. Boolean, String, Data) of some attributes was changed, HackinDROM can manage those changes quite well.
But when we
change the value of an existing attribute (an attribute whose 'format' is exactly the same in the current and new versions of OpenCore), HackinDROM does not accommodate that change. Instead, HackinDROM assumes that you, as the owner, changed the value for a good reason and you wish to keep the value that you currently have.
Unfortunately, when we enabled AppleVTD, we changed the value of an existing attribute,
DisableIoMapper
, from Checked-ON to Checked-OFF. Because all of us already have this attribute and it is set to Checked-ON, HackinDROM assumed that we wanted to keep it on. So it did not change it. And hence, the upgrade failed to enable AppleVTD.
This is not really the fault of HackinDROM because
it worked as it was designed to work. So instead, this is something we overlooked in the design. We are still discussing a solution, but in the near term the burden will lie on me to make these changes clear to our users. The mini-guide will need to include a
Post-Update Procedure to manually adjust such attributes.
Also, it looks like using fakePCIID for i225-V networking might not be necessary based on this info from the OC site:
2.5 Gbps Intel LAN. This works out of the box with AppleIntelI210Ethernet but requires a device-id injection of <F2150000> and a kext patch. This is all the same as with the CML boards. Additionally, with macOS 11.4 Beta 1, Apple has opened up AppleIntelI210Ethernet to supporting a larger array of devices including the i225-V NIC found on most higher-end boards. This requires no device-id injection or kext patch.
Is this coming here? Thanks.
We have actually commented out the injection of
device-id
, but the mini-guide asks Catalina users to un-comment that line because the native device ID 0x15F3 is not supported in Catalina, but it is supported in Big Sur and Monterey. Catalina users have to spoof the device ID back to 0x15F2.