GTi15 "GTiAT302" BIOS

rdn

What are the changes for this new BIOS for GTi15 “GTiAT302”?

https://dr.bee-link.cn/?dir=uploads%2FGTI%2FGTi15%2FBIOS%2FGTi15-BIOS-Version4-GTiAT302-Note-Update-code-only-GTiAT30X-can-flash

rdn

Successfully installed on my machine.

rdn

Any support team on this forum that can answer this?

Beelink CS-George

Hi there, the BIOS update is to improve the stability and hardware compatibility

jatvarthur

Is it update from T203-T205 bios or for some “hardware revision 2” platform? Like there was with gti14, if I recall correctly?

jatvarthur

rdn what was the previous bios version on your machine?

rdn

jatvarthur T205

jatvarthur

@Beelink CS-George Can you help with this, please? Is this bios compatible with my machine?

Beelink CS-George

jatvarthur Absolutely, this BIOS is fully compatible with your device.

rus.tyler.msk

Hello Beelink Support Team,

I found a reproducible ACPI firmware bug on my Beelink GTi15.

System information:

Model: Beelink GTi15 / AZW GTi V3.0
CPU: Intel Core Ultra 9 285H
OS: Gentoo Linux
Kernel: 7.2.2
Current BIOS: GTiAT301, dated March 12, 2026

The following errors appear twice during every boot:

ACPI BIOS Error (bug): Could not resolve symbol [_SB.PC00.LPCB.ITE8.GETT], AE_NOT_FOUND
ACPI Error: Aborting method _TZ.TZ00._TMP due to previous error (AE_NOT_FOUND)

I decompiled all ACPI tables loaded by the system. The problem is in the SSDT with OEM Table ID “Ther_Rvp”.

Its thermal zone TZ00 contains an _TMP method that calls:

_SB.PC00.LPCB.ITE8.GETT (0×2B)

However, the ITE8.GETT method is not defined in the DSDT or in any of the SSDTs. Therefore, TZ00._TMP fails and the vendor thermal zone is not registered by the operating system.

Independent CPU, NVMe and memory temperature sensors still work, but the firmware-provided system-board thermal zone and its operating-system thermal policy are unavailable.

I also extracted and examined the official GTiAT302 firmware image. Unfortunately, the same defective Ther_Rvp table and the same call to the missing ITE8.GETT method are still present. No definition of GETT
exists in the GTiAT302 ACPI tables either. Therefore, GTiAT302 does not fix this specific ACPI problem.

This is a firmware AML namespace error rather than a Linux kernel issue.

Could you please forward this report to the BIOS engineering team and provide a corrected BIOS?

Possible solutions appear to be:
Add the missing ITE8.GETT and related methods;
Select the valid thermal backend already present in the firmware;
Correct the ECON configuration;
Remove or replace the incompatible Ther_Rvp SSDT.

I can provide the complete ACPI table dump, decompiled DSL files, hashes and full kernel log if required.

Please let me know whether a corrected GTiAT303 or a test BIOS can be provided.

Thank you.

rus.tyler.msk

Beelink CS-George

Hello Beelink Support Team,

I found a reproducible ACPI firmware bug on my Beelink GTi15.

System information:

Model: Beelink GTi15 / AZW GTi V3.0

CPU: Intel Core Ultra 9 285H

OS: Gentoo Linux

Kernel: 7.2.2

Current BIOS: GTiAT301, dated March 12, 2026

The following errors appear twice during every boot:

ACPI BIOS Error (bug): Could not resolve symbol [_SB.PC00.LPCB.ITE8.GETT], AE_NOT_FOUND
ACPI Error: Aborting method TZ.TZ00.TMP due to previous error (AE_NOT_FOUND)

I decompiled all ACPI tables loaded by the system. The problem is in the SSDT with OEM Table ID “Ther_Rvp”.

Its thermal zone TZ00 contains an _TMP method that calls:

_SB.PC00.LPCB.ITE8.GETT (0×2B)

However, the ITE8.GETT method is not defined in the DSDT or in any of the SSDTs. Therefore, TZ00._TMP fails and the vendor thermal zone is not registered by the operating system.

Independent CPU, NVMe and memory temperature sensors still work, but the firmware-provided system-board thermal zone and its operating-system thermal policy are unavailable.

I also extracted and examined the official GTiAT302 firmware image. Unfortunately, the same defective Ther_Rvp table and the same call to the missing ITE8.GETT method are still present. No definition of GETT
exists in the GTiAT302 ACPI tables either. Therefore, GTiAT302 does not fix this specific ACPI problem.

This is a firmware AML namespace error rather than a Linux kernel issue.

Could you please forward this report to the BIOS engineering team and provide a corrected BIOS?

Possible solutions appear to be:

Add the missing ITE8.GETT and related methods;

Select the valid thermal backend already present in the firmware;

Correct the ECON configuration;

Remove or replace the incompatible Ther_Rvp SSDT.

I can provide the complete ACPI table dump, decompiled DSL files, hashes and full kernel log if required.

Please let me know whether a corrected GTiAT303 or a test BIOS can be provided.

Thank you.

rus.tyler.msk

Beelink CS-George

Hello,

Today, August 30, 2026, I updated my Beelink GTi15 from BIOS GTiAT301 to the new GTiAT302. The update completed successfully and the system boots normally, but the existing ACPI error has not been fixed.

System information:

Model: Beelink GTi15 / AZW GTi V3.0
CPU: Intel Core Ultra 9 285H
BIOS vendor: American Megatrends International
Previous BIOS: GTiAT301, dated March 12, 2026
Current BIOS: GTiAT302, dated April 1, 2026
SMBIOS version: 3.8.0
Platform firmware revision: 5.32
BIOS image size: 14 MiB
Boot mode: UEFI
Secure Boot: disabled
Operating system: Gentoo Linux x86_64
Kernel: 7.2.2-gentoo-gti15-prod2

The following errors still appear during every boot:

ACPI BIOS Error (bug): Could not resolve symbol [_SB.PC00.LPCB.ITE8.GETT], AE_NOT_FOUND (20260408/psargs-365)

ACPI Error: Aborting method _TZ.TZ00._TMP due to previous error (AE_NOT_FOUND) (20260408/psparse-543)

These messages appear twice during startup. As a result, the firmware thermal zone _TZ.TZ00 cannot provide its temperature through the _TMP method.

Other temperature sensors—including CPU, GPU, NVMe, memory, and network controller sensors—remain available, and I have not observed thermal throttling. Nevertheless, one firmware-defined thermal zone is
unusable.

The same ITE8.GETT / TZ00._TMP error was present with BIOS GTiAT301 and several earlier Linux kernels. Therefore, this does not appear to be a regression in Linux kernel 7.2.2. Unfortunately, updating to
GTiAT302 today did not resolve it.

Could Beelink please:
Confirm whether this is a known error in the GTi15 ACPI DSDT.
Correct the missing or incorrectly referenced ITE8.GETT method.
Provide a newer BIOS containing the ACPI fix.
Publish a detailed changelog for GTiAT302.

I can provide a complete dmesg, dmidecode, acpidump, and disassembled DSDT if required.

Beelink CS-George

rus.tyler.msk Hi there,

Thanks for the details.
Please provide a complete dmesg, dmidecode, acpidump, and disassembled DSDT

rus.tyler.msk

Beelink CS-George

Hello,

Thank you. I have attached the requested diagnostic bundle collected on September 2, 2026 while running BIOS GTiAT302 and kernel 7.2.2-gentoo-gti15-prod2.

The archive contains the complete dmesg and dmidecode output, the extracted DSDT and all SSDTs, their disassembled DSL files, and an ACPI dump. I omitted only the unrelated MSDM table because it contains the embedded Windows product key. All firmware tables relevant to this ACPI error are included unchanged.

The affected ThermalZone (TZ00) is defined in the SSDT with OEM Table ID “Ther_Rvp” rather than in the main DSDT. Its _TMP method calls:

\_SB.PC00.LPCB.ITE8.GETT (0x2B)

Ther_Rvp declares GETT as an external one-argument method, but no Method (GETT, …) definition is present in the DSDT or in any of the 22 extracted SSDTs. The attached dmesg contains the same AE_NOT_FOUND error twice during boot.

Please let me know if you need any additional logs, the unrelated MSDM table, or a test with a diagnostic BIOS.

Best regards,
Stanislav

the link to the archive (couldn’t upload over 120kb limit)

Beelink CS-George

rus.tyler.msk Thank you for your reply.Our R&D team is searching for relevant solutions. We will notify you immediately if there are any updates.

rus.tyler.msk

Beelink CS-George

Thank you, George. Please, feel free to contact me anytime for additional info. I am really looking forward to updating my BIOS firmware with fix I hope in 303

The hardware is great by the way!

Beelink CS-George

rus.tyler.msk Thank you for your kind feedback on the hardware.
Our R&D team is still working on the BIOS fix. As soon as the new BIOS firmware is officially released, we will reach out to you without delay.
Please feel free to let us know if you need any further information in the meantime.