xperia64 · August 8, 2024 02:06
diff --git a/Gigabyte X670(E) Maple Ridge Nonsense b/Gigabyte X670(E) Maple Ridge Nonsense
 UPDATE: Current resolution/state of things is this:
 1. Upstream grub's `acpi` command reassembles the ACPI table layout in reverse order, breaking various features
 2. Fork of grub that correctly rebuilds/patches the ACPI tables: https://github.com/xperia64/grub/tree/fix/acpi_ordering
 3. Patch CPMMSOSC SSDT table from current revision BIOS, variable U4PC `0x0F` -> `0xFF`
 4. grub arguments: `acpi -1 -2 /path/to/patched.aml`
 5. Card is mostly functional: first-hotplug is functional, re-hotplug is not functional; boltctl says force power isn't functional under Linux
 6. Working TB networking between my 7840U Framework laptop running Arch to my GC Maple Ridge card on an X670E Pro X BIOS F31b running Windows 11

 Original:
 Gigabyte's newer X670(E) boards with TB AIC support have a problem with Gigabyte's own Maple Ridge TB4/USB4 card.

 Older BIOS versions such as F13 for the Aorus Master and F3 for the Aorus Pro X seem to support this card without issue, while the next version is problematic.

 Maple Ridge simply fails to initialize under Windows with Code 10, and under Linux with error -110, both of which are supposedly power-on related.

 I did some digging, and it seems that Gigabyte did tweak their USB4-related SSDT APCI table between the broken and working versions.


 Specifically, the table in question is "CPMMSOSC".


 I'm not exactly sure what it's doing, but the logic has clearly changed a bit such that it doesn't initialize the USB4 controller properly anymore.


 As a dumb attempt at fixing this, I simply took the CPMMSOSC table from the last working BIOS, and force-loaded it via grub.

 This seems to make Maple Ridge once again mostly functional under Linux, with no real issues of note.
 Windows is another story. It usually makes the USB 3 controller part of Maple Ridge work, but I sometimes have to kick it in Device Manager by disabling/enabling it.
 Thunderbolt under Windows is flaky with this hack. It seemed to work better when I loaded the SSDT from the registry with TESTSIGNING rather than grub, but another time it also just worked fine with grub.

 The TB4 PCIe ports are correctly marked as hotplug in Windows, so that all still works.


 Meanwhile my ASRock Z270 build from before USB4 was even invented handles this card just fine. Very odd.



 I dumped the latest CPMMSOSC table from F31a, and made the change of updating the U4PC variable from 0x0F to 0xFF.
 This seems to make Maple Ridge somewhat functional as with using the old table, but presumably with a bugfix or two.

 I tried this change because the old table initialized U4PC to 0xFF, and the new table has a lot of special cases for if U4PC *is* 0xFF.

 tl;dr I recommend this method of dumping CPMMSOSC for now and updating the value of U4PC to 0xFF; it's still mostly functional under Linux and *can* work under Windows, albeit flaky when it comes to hotplug.

 Later I'm going to investigate the USB4 tables from an ASRock board and see what the difference is.
	UPDATE: Current resolution/state of things is this:
	1. Upstream grub's `acpi` command reassembles the ACPI table layout in reverse order, breaking various features
	2. Fork of grub that correctly rebuilds/patches the ACPI tables: https://github.com/xperia64/grub/tree/fix/acpi_ordering
	3. Patch CPMMSOSC SSDT table from current revision BIOS, variable U4PC `0x0F` -> `0xFF`
	4. grub arguments: `acpi -1 -2 /path/to/patched.aml`
	5. Card is mostly functional: first-hotplug is functional, re-hotplug is not functional; boltctl says force power isn't functional under Linux
	6. Working TB networking between my 7840U Framework laptop running Arch to my GC Maple Ridge card on an X670E Pro X BIOS F31b running Windows 11

	Original:
	Gigabyte's newer X670(E) boards with TB AIC support have a problem with Gigabyte's own Maple Ridge TB4/USB4 card.

	Older BIOS versions such as F13 for the Aorus Master and F3 for the Aorus Pro X seem to support this card without issue, while the next version is problematic.

	Maple Ridge simply fails to initialize under Windows with Code 10, and under Linux with error -110, both of which are supposedly power-on related.

	I did some digging, and it seems that Gigabyte did tweak their USB4-related SSDT APCI table between the broken and working versions.


	Specifically, the table in question is "CPMMSOSC".


	I'm not exactly sure what it's doing, but the logic has clearly changed a bit such that it doesn't initialize the USB4 controller properly anymore.


	As a dumb attempt at fixing this, I simply took the CPMMSOSC table from the last working BIOS, and force-loaded it via grub.

	This seems to make Maple Ridge once again mostly functional under Linux, with no real issues of note.
	Windows is another story. It usually makes the USB 3 controller part of Maple Ridge work, but I sometimes have to kick it in Device Manager by disabling/enabling it.
	Thunderbolt under Windows is flaky with this hack. It seemed to work better when I loaded the SSDT from the registry with TESTSIGNING rather than grub, but another time it also just worked fine with grub.

	The TB4 PCIe ports are correctly marked as hotplug in Windows, so that all still works.


	Meanwhile my ASRock Z270 build from before USB4 was even invented handles this card just fine. Very odd.



	I dumped the latest CPMMSOSC table from F31a, and made the change of updating the U4PC variable from 0x0F to 0xFF.
	This seems to make Maple Ridge somewhat functional as with using the old table, but presumably with a bugfix or two.

	I tried this change because the old table initialized U4PC to 0xFF, and the new table has a lot of special cases for if U4PC is 0xFF.

	tl;dr I recommend this method of dumping CPMMSOSC for now and updating the value of U4PC to 0xFF; it's still mostly functional under Linux and can work under Windows, albeit flaky when it comes to hotplug.

	Later I'm going to investigate the USB4 tables from an ASRock board and see what the difference is.