How reverse-engineering AMD’s Precision Boost 2, ACPI tables, and the Embedded Controller turned an abandoned ultrabook into an overclocked 24/7 compute powerhouse.

#01 The College Workhorse Meets Its Demise

Back in 2021, I bought a truly solid laptop: the Huawei MateBook 13 AMD. Powered by an AMD Ryzen 5 3500U (4 cores, 8 threads), 16 GB of dual-channel DDR4 RAM, and a fast 512 GB NVMe SSD, it was a sleek, thin-and-light machine that served as my primary engineering workstation throughout university.

From multi-layer PCB layout and electronics embedded programming to compiling heavy codebases and gaming on the side, it handled everything without breaking a sweat. Its integrated Radeon Vega 8 graphics were surprisingly competent, comfortably pushing titles like GTA V at 720p 60 FPS.

It felt like an aluminum MacBook Air clone, but built with genuine thermal headroom: beefy power VRMs and a dual-fan cooling assembly allowed the CPU to routinely boost up to its 3.5 GHz single-core limit over its 2.1 GHz base clock.

After nearly four years of intense daily use, the physical toll caught up with it. The chassis hinge snapped clean off, and shortly thereafter, the internal battery pack died completely.

Removing the broken lid assembly
Removing the broken lid assembly
Inspecting motherboard power delivery
Inspecting motherboard power delivery
Bench-testing the headless motherboard
Bench-testing the headless motherboard

#02 Turning E-Waste into a 24/7 Compute Node

Rather than throwing away capable quad-core x86 silicon, I disassembled the laptop, stripped away the broken display and housing, and decided to repurpose the board as a dedicated, low-power headless server.

I loaded up a modern Linux distribution (Ubuntu 24.04/26.04) and configured it to run heavy background services:

🔬 BOINC Distributed Compute
Running multi-threaded AVX PrimeGrid sieves and Vega GPU OpenCL tasks.
📹 Frigate NVR
Hardware-accelerated video decoding across multiple live camera streams.
🌐 Network Services
ArchiveTeam Warrior web preservation workers and I2P routing nodes.
First headless boot and service initialization
First headless boot and service initialization
Monitoring daemon and thread distribution
Monitoring daemon and thread distribution
Initial compute benchmarks under Ubuntu
Initial compute benchmarks under Ubuntu

#03 Hitting the Dreaded 400 MHz Wall

Everything looked promising until I put the system under heavy load. That is when I discovered a huge limitation: without a functional battery connected, the motherboard refused to let the CPU boost past 2.1 GHz. Even worse, the GPU remained permanently locked at 450 MHz, and periodically, the entire APU would violently throttle down to 400 MHz (0.4 GHz).

Why does this happen? Modern laptops treat the battery not merely as an energy reservoir, but as a dynamic electrical buffer. If the Embedded Controller (EC) cannot communicate with a healthy battery over SMBus/I2C, it engages failsafe throttling via a dedicated hardware pin named BD PROCHOT# (Bi-Directional Processor Hot) to prevent brownouts.

My first instinct was simple: replace the degraded pouch cells inside the battery pack with new high-capacity 18650 lithium cells.

Custom 18650 Battery Pack Mod
Wiring rebuilt 3S 18650 cell packs to the factory battery management board

However, when I connected the rebuilt pack, the system still fell into an aggressive crawl (400 MHz to 1.5 GHz). Here is where hardware engineering meets firmware reality: modern laptop Battery Management Systems (BMS) store their operating states in volatile memory. If the cells drop dangerously below cutoff voltage or are severed, the BMS triggers an irreversible hardware lockout to prevent fires. Replacing the cells had triggered a permanent limp mode: no charging, no discharging, and continuous distress signals to the motherboard!

#04 Reverse Engineering the ACPI Tables & EC Memory

Since the physical battery pack was locked in firmware, I disconnected it completely and decided to solve the problem where it originated: in software and microcontroller emulation.

By dumping and disassembling the laptop's ACPI DSDT table (/sys/firmware/acpi/tables/DSDT), I uncovered exactly how the operating system and the Embedded Controller evaluate battery health.

🔍 Deep Technical Breakdown: The ACPI _BIX Check & EC RAM Map ▼

In the disassembled DSDT, the ACPI Extended Battery Information method (_BIX) contains a strict evaluation condition:

Method (_BIX, 0, Serialized) {
    If (ECOK ()) {
        If ((Acquire (Z009, 0x2000) == Zero)) {
            // CRITICAL CHECK: ALL THREE MUST BE NON-ZERO
            If (((BTDV && BTFC) && BTDC)) {
                BPKG [0x02] = BTDC /* Design Capacity */
                BPKG [0x03] = BTFC /* Last Full Charge Capacity */
                BPKG [0x05] = BTDV /* Design Voltage */
            }
            Release (Z009)
        }
    }
    Return (BPKG)
}

When a battery is absent, the Embedded Controller's RAM offsets for BTDC (0x84) and BTDV (0x86) sit at 0x00. This causes the kernel battery driver to switch to energy_battery_full_cap_broken_props, omitting capacity and energy_full from sysfs. Consequently, Linux system monitors like btop assume no battery exists and disable frequency scaling.

EC Offset Register Value Injected Purpose
0x80 ACST / BST1 0x03 Signals Mains AC Online + Battery Present
0x84 BTDC 3610 mAh Battery Design Capacity (Unlocks _BIX)
0x86 BTDV 11400 mV Battery Design Voltage (11.4V)
0x90 BAPV 12500 mV Current Voltage (12.5V simulated)

Armed with this discovery, I developed a lightweight Linux daemon, ec_voltage_patcher.py. Using the kernel's ec_sys interface, it continuously writes these register values directly into the Embedded Controller's RAM at 50 Hz (20ms intervals).

⚡ Solving the ACPI IRQ 9 Storm

Writing to EC registers triggers hardware interrupts across LPC/eSPI ports. Running a tight loop without tuning generated over 3,200 hardware interrupts per second, consuming 20% of an entire CPU core on [irq/9-acpi]! By calibrating the loop to a 20ms interval (50 Hz), interrupts dropped by 75%, reclaiming ~15% of the core for actual compute tasks while keeping telemetry rock-solid.

#05 Unlocking 35W Fast PPT & Defeating Throttling

With valid battery telemetry restored, the next milestone was lifting AMD's factory limits. By default, Huawei firmware restricts the APU to a modest 15W–18W STAPM limit.

Using ryzenadj, I reconfigured the processor's System Management Unit (SMU) registers to unlock its full desktop-like capability:

Automated SMU Calibration Routine ● Live in ec_voltage_patcher
# Boost power envelop & eliminate 400 MHz recovery traps
ryzenadj \
  --stapm-limit=35000 \        # 35W Sustained Power
  --fast-limit=35000 \         # 35W Fast PPT (Matched to avoid VRM over-current)
  --slow-limit=35000 \         # 35W Slow PPT
  --vrm-current=55000 \        # 55A TDC Sustained Current
  --vrmmax-current=70000 \     # 70A EDC Peak Electrical Current
  --tctl-temp=88 \             # 88°C Thermal Ceiling
  --prochot-deassertion-ramp=1 # Collapses 400MHz recovery from 30s to 1ms!

The magic trick here is --prochot-deassertion-ramp=1. Normally, when a transient spike trips the processor hot line, AMD's firmware forces a sluggish 30-second penalty box at 400 MHz before slowly climbing back up. Setting the ramp to 1 forces the processor to recover in just 1 millisecond, completely neutralizing random clock drops.

#06 Overcoming Heat-Soak: The PTM7950 Repaste

While the software power targets were unlocked, the hardware soon met another roadblock: thermal throttling. At 35W, the bare silicon die was shooting past 85°C almost instantly.

I took apart the stock copper cooling assembly and found the culprit: after 4 years, the factory silicone thermal paste had baked out completely into dry, chalky powder, creating micro-air gaps between the bare silicon and copper coldplate.

Dried up thermal paste on heatsink
The original thermal paste had completely dried up into a brittle barrier

To fix this permanently, I performed two critical hardware upgrades:

  1. Honeywell PTM7950 Phase-Change Pad: Unlike regular paste that pumps out under heat cycles, PTM7950 turns liquid at ~45°C to form microscopic contact with the silicon, solidifying when cool. It offers near-liquid-metal performance with zero risk of shorts.
  2. High-Conductivity VRM Thermal Pads: Placed on the voltage regulator MOSFETs to dissipate motherboard heat directly into an external aluminum heatsink with active fan assist.
  3. 100W USB-PD Power Supply: Upgraded from the stock 65W charger to a 100W brick, preventing transient voltage sag that previously triggered emergency BD PROCHOT downclocks.
Stable 35W All-Core Boost Telemetry
Stable 35W sustained operation: all 8 threads boosting between 2.7 and 3.1 GHz with temps at a cool 66°C

#07 Profile Comparison Matrix & Verified Results

Here is how the tuned profiles stack up across different operational targets. The current 24/7 profile delivers 100% stability under combined CPU and GPU compute:

Profile Fast PPT Slow PPT Tctl Temp All-Core Clocks Thermals & Acoustics Recommended For
Silent / Cool 25 W 22 W 72 °C ~2.40 – 2.50 GHz Whisper quiet, ~65–70°C Office work, quiet rooms
Stabilized 65W 30 W 28 W 84 °C ~2.40 – 2.89 GHz Passive block or OEM brick 24/7 compute with OEM 65W charger
Active Fan + 100W PD
Current Active
38 W 35 W 88 °C ~2.72 – 3.16 GHz Cool (~66–75°C) with fan 24/7 BOINC (CPU+GPU) + Frigate NVR
Max Turbo / Water 45 W 45 W 95 °C ~3.05 GHz (Physical limit) High airflow or liquid loop Benchmarking & watercooling
Sustained Power
35W
+133% over stock
All-Core Clocks
~2.87 GHz
Up to 3.16 GHz burst
GPU VRAM Bus
1.2 GHz
38.4 GB/s pinned
Operating Temp
~66 °C
PTM7950 + Fan

#08 Conclusion: Giving Hardware a Second Life

What began as an e-waste pile of broken aluminum and dead battery cells turned into an immensely satisfying deep dive into modern x86 power architecture.

By combining EC RAM emulation, Precision Boost 2 tuning, and modern phase-change thermal materials, this old laptop now runs faster, cooler, and more consistently than it ever did fresh out of the factory box. Today, it quietly crunches distributed science projects and manages home security streams 24/7 without skipping a single clock beat.

Want to inspect the scripts and firmware?

The battery emulator daemon, systemd service, and ESP32 code are available on GitHub.

View on GitHub →