The New Beginner's Guide to USB Port Configuration

[Edhawk]

Just reviewed the IOReg and see that you are using a Broadcom WiFi/BT card not the original Intel card that came with the board. I assume you are using the CNVI connector for this card.

Rest of the IOReg looks OK and as I would expect.

 

[dasboot5]

I'm happy to have a look at the EFI etc.but have a couple of questions/observations.

Did the system suffer with 'Instant Wake' issues, before you added the SSDT-GPRW.aml table and companion patch to the /EFI/OC/ACPI folder and config.plist respectively?

If not then you may not need this SSDT and the config.plist ACPI patch.

You have an obsolete ACPI patch for Method (UPRW, 2,.... enabled in your config.plist.

View attachment 557431 Obsolete patch

It is obsolete because the DSDT.aml doesn't contain a Method (UPRW, 2,.... . It contains a Method (GRPW, 2,.... entry.

I assume you obtained the SSDT-GPRW.aml from this Dortania Github page.

GPRW/UPRW/LANC Instant Wake Patch | OpenCore Post-Install

You might want to ensure that Lilu.kext and VirtualSMC.kext are the first and second kexts in the Kernel > Add section of your config.plist. While you have Lilu.kext first, VirtualSMC.kext is fourth, with another Lilu plugin (NVMeFix.kext) injected before VirtualSMC.kext. This is not usually a good thing.

Kernel > Patch > 0
Not sure if you need this AppleRTC patch. Where did you obtain the patch and under what circumstances was it being used by the owner/developer?

View attachment 557437 AppleRTC Kernel > Patch

Misc > Debug > AppleDebug and ApplePanic are set to false, they should be set as True.

USBPorts.kext details will be in my next post.

Rest of the OC EFI looks fine.

Edhawk,
Thank You for helping. I broke a cardinal rule and asked Tonymac user who had the same MB writing under the Ventura relase thread (Yomira) if I could see his EFI and comapare to see if I had missed something on may convert over from 0.7.5 to 0.8.6. He has the added SSdt and had both patches installed I wondered about the 2nd so I can remove the UPRW version.
I actually have a list I made up of the order of Lilu and Virtual but in my hasted tom use Propertree's OC snapshot to add a couple of kexts I have notice it change the order, i usually 2nd check and drag the kexts back to there proper order but I did not do this this time. I will correct.
Without Kext patch 0 the board would reset the bios to safemode, (F1 Boot Error), every time on shutdown or restart. Requiring a F1 / F10 restart. I found this at the Github: F1 Boot error Fix Asus Z490I.
On misc debug there are additional lines in 0.8.6 open core buld that are not in the 0.8.5 build that were causing schema error to show before my picker them appears. These were DoubleClick pointer etc. I removed the lines which removed the schema errors so the children count matched 0.8.5 nut are you saying setting them to True will allow the 3 lines to be added back in.? There are 10key/pairs vs 13 in 0.8.5:

 

[dasboot5]

Just reviewed the IOReg and see that you are using a Broadcom WiFi/BT card not the original Intel card that came with the board. I assume you are using the CNVI connector for this card.

Rest of the IOReg looks OK and as I would expect.

No The card is in and adapter in the lower sata m.2 slot. The slot above has the Window Nvme M.2. and there is no card in the CNVI slot as putting any card other that a cnvi card in theIO slot will cause a no boot-at-all situation and the card will not work as well, the bluetooth header goes to an internal USB 2.0 header and I named it 255 to allow it work properly and it does. You can see the setup on Jergo link I just sent. There is no other way to get a Broadcom card to work as the only PCIE slot is supporting graphics. I extended the wifi cables from the card to the orginal wifi bulkhead antenna connections. So it looks as there there is a card in the slot but it is empty and disabled in bios.

 

[Edhawk]

The kext order is easy to change when using the Clean snapshot feature in ProperTree. As long as you are aware of the issue and can re-order the kexts that is fine.

The Patch '0' is fine and obviously required for your board to boot correctly. I hadn't seen this patch before, so needed to ask the question about its usage.

Not sure what you are asking regarding the Misc > Debug options not being set and how they relate to the AppleInput options you deleted. The two sections are separate and should be dealt with as two different issues.

Setting the three entries in Misc > Debug to True is just how the OC guide says they should be set. If your system works without them then it is simply a choice of testing to see if the Boot issues are connected to these entries not being enabled.

If you are using OC 0.8.5 the additional entries in AppleInput will not be required. So no, don't add them back in to your config.

 

[Edhawk]

OK, my assumptions were a little off the mark. But at least you know where everything is placed and how it all connects.

The WiFi/BT card being in the second M.2 slot doesn't make any significant difference if the BT module is connected to the USB2 header. As you already have the USB port for the BT set correctly.

 

[dasboot5]

OK, my assumptions were a little off the mark. But at least you know where everything is placed and how it all connects.

The WiFi/BT card being in the second M.2 slot doesn't make any significant difference if the BT module is connected to the USB2 header. As you already have the USB port for the BT set correctly.

I have made all the corrections you noted.
1. removed the extra patch in regards to the SSDT GPRW.
2. corrected the load order of the Kernel extension in the Kernel section
3. redid the USB port Kext naming, and no change, still has the startup problem although I may have the C switch incorrect so I will try changing that tomorrow and report back. One C with the switch was removed, but I kept the actual C-type port on the back IO as I had it.
4. Fixed the misc debug items to True.

I wonder if I should put back these boot args: debug=0x100 and keepsyms=1 to see if this helps?
I could pout back verbose and maybe that would give a clue as to what is causing the panic... But it only does it one time if I wait long enough for the 2nd boot try...25 secs or longer...
Thank You again.

 

[Edhawk]

Temporarily adding -v debug-0x100 and keepsyms=1 to your config would help with diagnosing the kernel panic. You could take a photo of the stop point, which would help us see what is happening and what might be the cause of the KP. With the three boot args the system should stop, not automatically reboot.

Post a copy of your revised EFI so I can check it over. Redact your Serial etc from the config before posting a copy.

 

[dasboot5]

Edhawk,
It does not stop on the error it just reboots to picker UI and the without a time delay it goes straight through although the verbose screen is much longer. There is not enough time to take a clear pic of the shorter verbose screen before the auto restart. No kernel panel delay screen from the OS after the error on the first restart. The corrected EFI and screen print of the new USB setup and kext are attached.
Seems like a combo reboot loop/ panic. Something is abnormal about this board....

 

[Edhawk]

Are you booting Linux on this system? If not, then you should remove the OpenLinuxBoot.efi from the /EFI/OC/Drivers folder in your setup.

Your config and OC folder are set to boot to the OC GUI, not the OC Picker List. Are you sure you are using the correct EFI when booting? You don't have another EFI on another drive, which may be used?

I have changed the EFI attached below, so it boots to the Acidanthera OC GUI, so you can tell when you are using the correct EFI. Just add your Serial etc, and see how this revised EFI boots.

 

[Edhawk]

You might be advised to disable the Type-C ports in your USBPorts.kext until you are sure they are set correctly.

If you have a port that is Type-c without a switch (10) there should be another companion port set the same. Not the USB2 virtual port, but another physical Type-c connector, that shows when the type-c device is flipped 180°.