GTi15 "GTiAT302" BIOS

rdn · 2026-06-21T16:43:10+00:00

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

Beelink CS-Yvette

rus.tyler.msk Apologies for the delayed reply; our beta BIOS has only recently stabilized, and we have just returned from the Mid-Autumn Festival holiday.

Yes, please try updating to this BIOS to resolve the issue with your device.

I have sent the BIOS firmware to you via private message; please check for it.

rus.tyler.msk

Beelink CS-Yvette Yes, I have received GTiAT303_rom.zip, but I am on a business trtip till the end of this week. As soon as I get home I can try to update and let you know here on forum.

Beelink CS-Yvette

rus.tyler.msk Thank you for your understanding.We will wait for your update.

Have a nice business trip.

rus.tyler.msk

Beelink CS-Yvette

Hello! I have installed the GTiAT303 BIOS you provided and tested it on my GTi15. Thank you to you and the BIOS engineering team: the original ACPI error is resolved.

System details after the update:

• Manufacturer and model: AZW GTi, hardware version V3.0
• CPU: Intel Core Ultra 9 285H
• Previous BIOS: GTiAT302
• Current BIOS: GTiAT303, dated September 11, 2026
• OS: Gentoo Linux x86_64
• Running kernel: 7.2.9-gentoo-gti15-prod2

With GTiAT301 and GTiAT302, every boot produced two instances of AE_NOT_FOUND for _SB.PC00.LPCB.ITE8.GETT, followed by failure of _TZ.TZ00._TMP. After updating to GTiAT303, neither error appears in the
current boot log.

The firmware thermal zone is now registered:

ACPI: thermal: Thermal Zone [TZ00] (27 C)

Linux exposes it as /sys/class/thermal/thermal_zone0, with type acpitz. Its temperature reading is currently 26800 millidegrees Celsius (26.8 °C). The independent CPU sensor also works; it currently reports
approximately 45–47 °C. The system boots normally, and I have not observed thermal throttling.

There is one remaining ACPI warning during boot:

ACPI: thermal: [Firmware Bug]: No valid trip points!

I see no trip_point_* entries for the acpitz thermal zone in sysfs. Could your BIOS engineers clarify whether TZ00 is intentionally a temperature-reporting-only zone? If it is intended to provide passive,
active or critical thermal thresholds to the operating system, could the trip-point definitions be checked for a future BIOS release? I am not claiming that cooling has failed; I am reporting the remaining
firmware warning and the absence of OS-visible thresholds.

A separate, lower-priority message is:

Bluetooth: hci0: No support for _PRR ACPI method

I have not confirmed any Bluetooth malfunction. Please let me know whether the absence of _PRR is expected for this hardware.

If useful, I can provide a fresh dmesg, dmidecode, ACPI table dump and thermal-zone sysfs output from GTiAT303 for comparison with the GTiAT302 diagnostic bundle I previously shared. A short changelog
describing the ACPI changes in GTiAT303 would also be appreciated.

Thank you again for addressing the ITE8.GETT issue.

Best regards,
Stanislav (rus.tyler.msk)

rdn

I’ve seen a similar error logged when using Omarchy, currently using GTiAT303 bios.
Would like to test the updated BIOS too.

Beelink CS-Yvette

rus.tyler.msk Thank you very much for your detailed test report. We are glad that the new BIOS GTiAT303 fixed the original AE_NOT_FOUND ACPI error.

Regarding the two remaining warnings you mentioned:

ACPI thermal: [Firmware Bug]: No valid trip points!
The thermal zone TZ00 is designed for temperature reporting only, without trip points defined. This is an intentional firmware design. It will not affect temperature reading, normal cooling or thermal throttling. We will forward your feedback to our BIOS engineering team to evaluate adding trip-point definitions in future BIOS releases.
Bluetooth: hci0: No support for _PRR ACPI method
The lack of _PRR ACPI method support is expected for this hardware platform. It does not impact normal Bluetooth functionality.

We will sort out the ACPI changes and prepare a brief changelog later.
Feel free to share the dmesg, dmidecode, ACPI table dump and thermal-zone sysfs outputs if you wish, we will use them for further reference.

Beelink CS-Yvette

rdn Thanks for your feedback. The ACPI warning you encountered is the same No valid trip points warning we discussed earlier. The TZ00 thermal zone is designed only for temperature reporting and will not affect cooling or performance. We will notify you when a newer BIOS version is available for testing.

rus.tyler.msk

Beelink CS-Yvette

Thank you for clarifying the thermal-zone and Bluetooth warnings. There is one additional issue I would like your BIOS engineers to review: resource-mapping warnings from the Linux
igen6_edac driver.

System details:

• Beelink GTi15, Intel Core Ultra 9 285H.
• BIOS: GTiAT303, dated September 11, 2026.
• OS: Gentoo Linux.
• Kernel: 7.2.9-gentoo-gti15-prod2.
• EDAC driver: igen6_edac, version 2.5.1.

The following messages appear during boot:

acpi PNP0C02:04: Reserved [mem 0xfedc0000-0xfedc7fff]

resource: resource sanity check: requesting [mem 0×00000000fedc0000-0×00000000feddffff], which spans more than PNP0C02:04 [mem 0xfedc0000-0xfedc7fff]
caller igen6_probe+0×88/0×920 [igen6_edac] mapping multiple BARs

resource: resource sanity check: requesting [mem 0×00000000fedc0000-0×00000000fedcffff], which spans more than PNP0C02:04 [mem 0xfedc0000-0xfedc7fff]
caller igen6_probe+0×19a/0×920 [igen6_edac] mapping multiple BARs

The ACPI resource shown in the log covers 32 KiB, while the driver requests mappings of 128 KiB and 64 KiB starting at the same address.

Despite these warnings, both memory controllers register successfully:

EDAC MC0: Giving out device to module igen6_edac controller Intel_client_SoC MC#0: DEV 0000:00:00.0 (INTERRUPT)
EDAC MC1: Giving out device to module igen6_edac controller Intel_client_SoC MC#1: DEV 0000:00:00.0 (INTERRUPT)
EDAC igen6: v2.5.1

The current sysfs counters are zero for both controllers:

mc0: ce_count=0, ue_count=0
mc1: ce_count=0, ue_count=0

I am reporting a resource-range mismatch, not a confirmed RAM failure. I also cannot yet determine whether this originates in the BIOS resource declarations or the Linux driver.

Could your engineers please check:

Whether the ACPI PNP0C02:04 resource declaration covers the intended register range on this platform.
Whether these warnings could affect memory-error reporting or are harmless here.
Whether a BIOS correction is appropriate, or this should instead be reported to the Linux EDAC maintainers.

I will provide the full boot log, ACPI table dump and relevant sysfs outputs if needed. Thank you!

rus.tyler.msk

Beelink CS-Yvette

I have attached GTi15-GTiAT303-EDAC-20261010.zip with diagnostics for the igen6_edac resource-mapping warnings mentioned above.

System: Beelink GTi15, Intel Core Ultra 9 285H, BIOS GTiAT303 dated September 11, 2026, Gentoo Linux with kernel 7.2.9-gentoo-gti15-prod2.

The archive includes:
• Full available kernel log and OpenRC boot log.
• BIOS, CPU and RAM information.
• EDAC counters, PCI host-bridge details and /proc/iomem.
• Relevant ACPI and thermal sysfs outputs.
• 40 unmodified binary ACPI tables.

To fit the forum’s upload limit, the ACPI tables are compressed separately inside the ZIP as acpi-tables.tar.xz. Extraction instructions are included in README.txt.

Personal identifiers have been redacted from the text logs.

Both EDAC controllers register successfully, and their corrected and uncorrected error counters remain zero. However, the driver requests 64 KiB and 128 KiB mappings starting at 0xfedc0000, while the ACPI resource declaration reserves only 32 KiB.

Could your BIOS engineers review this discrepancy and advise whether the firmware resource declaration needs correcting or whether this should be investigated by the Linux EDAC maintainers?

Thanks!

gti15-gtiat303-edac-20261010.zip

105kB

Beelink CS-Yvette

rus.tyler.msk Thank you for your report. We will pass this on to our technical team and notify you of any updates.

« Previous Page