Contribute
Register

Beginners Guide to using OC Auxiliary Tools App (Also known as OCAT)

I've created a feature request for sub-folder support in OCAT, but it probably won't come. If it would be implemented – which is unlikely –, ocvalidate would have to be modified as well. Because as of now, having kexts in sub-folders will produce errors when validating the config.
Why? What is the point in putting kexts in sub folders? There is no real need to do this
 
My laptop's EFI has many kexts for battery, trackpad, keyboard, Lenovo sensors, etc so it's nice to split them up. Especially since I'm moving kexts in and out of my EFI somewhat often as I work on them, it's nice to be able to quickly see what is in my EFI and is not for a specific category.

@5T33Z0 OCValidate returns zero errors on my EFI, which is why I was curious what errors you were getting.
 
@1Revenger1: Ah, now I know why I got errors. I named one folder "Wifi+BT". I think it doesnt like the "+":

Kernel->Add[20]->BundlePath contains illegal character!
Kernel->Add[21]->BundlePath contains illegal character!
Kernel->Add[22]->BundlePath contains illegal character!
Kernel->Add[23]->BundlePath contains illegal character!
Kernel->Add[24]->BundlePath contains illegal character!
 
I can understand why OCAT doesn't support kexts in folders. Most people don't bother, and most desktops don't even have enough kexts to really need any sort of organization. My use case is somewhat special, so I'm fine with support not being added. I really don't think it's a big deal. Reading back, it seems like I've caused an entire conversation around this (oops). I was mostly just sharing my experiance, but it's not that indicitive for other users (unless they created a weird ApECID value too).
 
@1Revenger1 I don't mind either- It's just that I noticed the issues that occur when trying to use OCAT this way. And that's why I suggested to add the feature. I later saw that you already suggest it.

OT: So, "Sheikah Slate", eh? :D I copped me a Wii-U in November dirt cheap and have been playing Zelda BOTW eversince. It's the best Zelda title I've played since OOT.
 
Last edited by a moderator:
Could I ask a question? Using Ocat what Smbios would be chosen to allow the following for a Skylake board:

When spoofing a Skylake board to Kaby lake to allow Ventura to install must you use a Skylake Base EFI, not a Kaby, and then only use the 18,3 SMBIOS to avoid the Apple cliff/wall install block and use the video device property id information from Skylake rather than Kaby? Or should the info and base be all Kaby?

Note 2: iMac17,1 was dropped in the release of macOS Ventura.
If running macOS Ventura, use a Kaby Lake SMBIOS.
Also, can you boot Ventura with a Monterey installer flash using the proper EFI from the Ventura upgrade, to test an Opencore upgrade ie 0.8.7 to 0.8.8? Or must it be a Ventura flash minimum? (AAPL,ig-platform-id for Skylake: 01001219 Discrete GPU) (AAPL,ig-platform-id for Kaby: 03001259 Discrete GPU)
 
Last edited:
Could I ask a question? Using Ocat what Smbios would be chosen to allow the following for a Skylake board:

When spoofing a Skylake board to Kaby lake to allow Ventura to install must you use a Skylake Base EFI, not a Kaby, and then only use the 18,3 SMBIOS to avoid the Apple cliff/wall install block and use the video device property id information from Skylake rather than Kaby? Or should the info and base be all Kaby?

Note 2: iMac17,1 was dropped in the release of macOS Ventura.
If running macOS Ventura, use a Kaby Lake SMBIOS.
Also, can you boot Ventura with a Monterey installer flash using the proper EFI from the Ventura upgrade, to test an Opencore upgrade ie 0.8.7 to 0.8.8? Or must it be a Ventura flash minimum? (AAPL,ig-platform-id for Skylake:00001219 Discrete GPU) (AAPL,ig-platform-id for Kaby: 03001259 Discrete GPU)
on my skylake laptop for example, I changed from MacBookPro13,1 to MacBookPro14,1 and I also changed platform ID from 00001619 to 00001B59

you should be able to do the same with desktop, change from iMac17,x to iMac18,x and change platform ID accordingly

that was the only change required (also changing USBPorts.kext info.plist from MacBookPro13,1 to MacBookPro14,1)
 
When spoofing a Skylake board to Kaby lake to allow Ventura to install must you use a Skylake Base EFI, not a Kaby, and then only use the 18,3 SMBIOS to avoid the Apple cliff/wall install block and use the video device property id information from Skylake rather than Kaby? Or should the info and base be all Kaby?
The only drawback I can envisage is the USB mapping maybe a problem but I am not absolutely certain.
Also, can you boot Ventura with a Monterey installer flash using the proper EFI from the Ventura upgrade, to test an Opencore upgrade ie 0.8.7 to 0.8.8? Or must it be a Ventura flash minimum? (AAPL,ig-platform-id for Skylake:00001219 Discrete GPU) (AAPL,ig-platform-id for Kaby: 03001259 Discrete GPU)
On my system I boot Monterey, Big Sur and Ventura all on their own respective Drives with only one EFI Folder residing on the Ventura Drive so I don't think that will be a problem.
 
@dasboot5

  1. First of all: you need to configure the EFI for the CPU you have in your system!
  2. You also need to spoof the the IGPU of a kabylake sytstem, as explained here
  3. Spoofing SMBIOS is old-school and not required if you have Big Sur installed! Instead you can combine Booter Patches from OCLP to skip board-id checks and add RestrictEvents kext with an additional boot-arg (revpatch=sbvmm) to make macOS believe it is running in a Virtual Machine. This way you can use the intended SMBIOS for Skylake, install Ventura and updates. It's explained here in detail
  4. So: if Big Sur is installed already, you can make use of macOSes Virtualization Capabilities and install/upgrade and boot macOS Ventura with iMac17,1 SMBIOS.
You also seem to confuse the terms dGPu and iGPU…
 
Back
Top