Post Installation refinement using debug 1.0.3 and 1.0.4 on Colorful B650 AMD board

[DASBOOT5]

If I attach my EFI's, serials removed, and Debug files, could you take a look at the EFI's for errors and anything that may be corrected from the debug logs from 1.0.3 and 1.0.4?
I have a running version of Sequoia 15.2 my Colorful MATX B650 Ryzen 7 7700 RX 6600 using release. But the debug versions will not complete boot, (on a flash drive), for testing although
they create debug logs. I am also working on the MIMO whitelist area which was the reason for the debug tests. Let me know if you are game for the lookover of my work
EFI from 1.0.3 ,1.0.4 and debug log file, can be uploaded for checking....
Here is non-booting config.plist fromEFI from 15.2 Sequoia flash with 1.0.3 debug OC and Log file in rtf format. since you have a server upload restriction that will not allow me to attach my EFI compressed

 

[EliteMacx86]

If I attach my EFI's, serials removed, and Debug files, could you take a look at the EFI's for errors and anything that may be corrected from the debug logs from 1.0.3 and 1.0.4?
I have a running version of Sequoia 15.2 my Colorful MATX B650 Ryzen 7 7700 RX 6600 using release. But the debug versions will not complete boot, (on a flash drive), for testing although
they create debug logs. I am also working on the MIMO whitelist area which was the reason for the debug tests. Let me know if you are game for the lookover of my work
EFI from 1.0.3 ,1.0.4 and debug log file, can be uploaded for checking....
Here is non-booting config.plist fromEFI from 15.2 Sequoia flash with 1.0.3 debug OC and Log file in rtf format. since you have a server upload restriction that will not allow me to attach my EFI compressed

Firstly, switch to the official Kexts and ACPI files.

Replace SSDT-EC and SSDT-USBX with SSDT-EC-USBX-DESKTOP. You can also note down the path and then directly change the path in the SSDT-EC-USBX (provided in the official OC package).
Disable ResetLogoStatus
If you have a restart issue, then only use DisableVariableWrite. Otherwise, disable it.
RX 6600 is a natively supported GPU. Why are you using NootRX?
You should disable the CustomSMBIOSGuid
Remove DebugEnhancer
Any specific reason to use PollAppleHotKeys?
Remove the debug args and add agdpmod=pikera
Set UpdateSMBIOSMode to Custom

 

[DASBOOT5]

1. All kexts that were available as debug versions on this site were used: https://dortania.github.io/builds/
2. This is a dual boot Windows 11 machine , SSDT-EC and SSDT-USB were created from SSDT time for this specific board.
3. I am not using WG and the boot arg agdpmod=pikera for the 6600. Debug is what I trying to accomplish. The version of OC I am using for testing is Debug and it will not boot. The Release 1.0.3 does boot, without error.
4. CustomSMBIOSGuid enabled and UpdateSMBIOSMode to Custom are set properly for my dual boot situation.
You did not make any comments on debug log file.
5. Debug kexts and drivers for Debug, release Kexts and Drivers for Release OC. Debug does not boot Release does.

 

[EliteMacx86]

1. All kexts that were available as debug versions on this site were used: https://dortania.github.io/builds/

Is there any reason to use DEBUG version of the kexts? The DEBUG versions should not be used in a production environment but only when you want to debug to get some additional details or when debugging when the system does not boot or has unexpected behavior.

2. This is a dual boot Windows 11 machine , SSDT-EC and SSDT-USB were created from SSDT time for this specific board.

The guide mentioned here does not recommend to use the SSDTTime to create the SSDT-EC and SSDT-USB.

I am not using WG and the boot arg agdpmod=pikera for the 6600. Debug is what I trying to accomplish. The version of OC I am using for testing is Debug and it will not boot. The Release 1.0.3 does boot, without error.

That's weird. Attach the revised EFI with the changes except for the RELEASE version of OC and kexts.

4. CustomSMBIOSGuid enabled and UpdateSMBIOSMode to Custom are set properly for my dual boot situation.

Is advised to use it only on DELL and SONY system with truncating BIOS.

You did not make any comments on debug log file.

Yes, because the EFI is missing so never checked it.

5. Debug kexts and drivers for Debug, release Kexts and Drivers for Release OC. Debug does not boot Release does

Attach the revised EFI with the changes mentioned above except for the RELEASE version of OC and related kexts.

 

[DASBOOT5]

In regards to SSDT EC-USBX:
From the SSDT time current site:

• 2. FakeEC - OS-aware Fake EC
  • This is the SSDT-EC, required for Catalina and newer users
• 4. USBX - Power properties for USB on SKL and newer SMBIOS
  • This is the SSDT-USBX. The prebuilt version can be used if desired, but SSDTTime can build a customizable version of SSDT-USBX.
• I have read more than one place that these two can be used together to obtain the same result as the prebuilt or custom generated SSDT(s)
• 
  
• The purpose of SSDT-EC/USBX is a couple things:
  
  • On desktops, the EC (or better known as the embedded controller) isn't compatible with AppleACPIEC driver, to get around this we disable this device when running macOS
  • AppleBusPowerController will look for a device named EC, so we will want to create a fake device for this kext to load onto
    • AppleBusPowerController also requires a USBX device to supply USB power properties for Skylake and newer, so we will bundle this device in with the EC fix
• This will provide you with some files, the main one you care about is SSDT-EC.aml. The DSDT and .dsl are only left for referencing or verification.
  
  
  The main things to note with this method: (Using SSDTTime for EC creation)
  
  
  • It doesn't provide you the USBX property to fix the power
    • This can easily be fixed by using this prebuilt file in addition to SSDT-EC: SSDT-USBX.aml
• Note USBX is only needed for Skylake and newer
• There is not much difference between SSDTTime generated USBx and the prebuilt USBx (IMO) other than the prebuilt is bloated with extra info not specific to the board being used.