Recent content by 1Revenger1

Make sure that your drivers are up to date under EFI/OC/Drivers. BEP = Boot Entry Protocol - it's the protocol that OpenCore uses for drivers to add boot entries (such as through ResetNvramEntry.efi). I'm guessing that the version got incremented between versions due to changes in the protocol...

If your windows install is broken, you may be able to use a Linux live USB. I usually use "xinput --list-devices" in terminal or "sudo dmesg | grep -i input" Looking in dmesg will show SMBus devices and be a bit more specific about the type of I2C device it is, if it is I2C.

Unlikely. I'm guessing that the architecture for the newer iGPUs are not similar enough for the current drivers in macOS to be used. Also, this looks like it's mostly for GT1 GPUs (ie lowest tier of iGPUs). Most of the higher end GPUs from Haswell, Kabylake, etc already work. If GT1 GPUs already...

I'm mostly familiar with TB3, so I'll speak from my experience there. One thing to realize before starting is that TB3 and 4 controllers have a USB Controller built in to them. How the port works depends on what is on the other side of the cable. Some docks/hubs expose themselves as a PCI...

@robi42 According to the Configuration.pdf under Misc->Booter->PickerAttributes, you can use disk label files next to the bootloader to label boot entries. This does require bit 1 to be set in the PickerAttributes value though. From the Configuration PDF:

Thunderbolt should be labeled as USB-C ports yes (you'll need to figure out if it has a switch or not when setting the type). If it's 3.1 Gen 2 (ugh these names) but is USB-A, the type should the 3 for USB-A I think. I don't really know what limitations there are for TB4, I've never messed with it.

If I'm remembering right, Polaris drivers in Ventura uses AVX 2.0 instructions. Any CPUs which don't support AVX 2.0 (Ivy Bridge and older in this case) need to revert the Polaris drivers to an older version through OCLP.

Afaik, Lilu does nothing for early boot graphics. Lilu ends up doing some of the patches for Whatevergreen, such as renaming the iGPU in the IOService tree. That all got reverted anyway for AMD iGPUs, and I think is being done in WhateverRed.

Regarding longer boot times, it could potentially be TRIM if your booting from an NVMe drive. Some drivers are known to have a slow TRIM implementation. You could try disabling trim through OC to see if that helps boot times, though unfortunately you can't adjust the timeout limit in recent...

It sounds like they're renaming a device though instead of a method/function, which is why I'm confused and was asking for more details. Normally device renames are needed to make macOS kexts attach/work correctly when they use hard coded names (ie avoiding USB Maps, graphics, etc).

Why does the device need to be renamed in the first place? Is it a limitation of Big Surface? Be easier to change the Kext probably to match the ACPI rather than change the ACPI to match the kext

VoodooRMI was also updated this month. Mostly just some fix ups, and allowing configuration through ACPI like with VoodooPS2.

So, a couple of things. I'll start with a bit of background. The entire reason that mapping is needed is because macOS USB kexts have a limitation of 15 so called Personalities per controller. I will use personality to describe either the 2.0 or 3.0 part of a physical USB port, as these are...

OCValidate must correspond to the version of OC you are using too. i.e. if using OC 0.8.8, you must use OCValidate from 0.8.8 as well. I'm not sure how OCAT handles this, but I would hope it uses the version which corresponds to which version is selected.

Having the USB 2.0 and USB 3.0 personalities on different controllers isn't that unusual. That is how it's configured on my X1 Extreme (3.0 is on the thundebolt controller, 2.0 on the internal usb controller). Not entirely sure why OEMs have this companion port setup. Something similar was done...