My battery charging limit fix for MECHREVO Wujie 14XA

A developer fixed the battery charging limit function on the MECHREVO Wujie 14XA laptop by reverse-engineering the EC firmware with help from Codex and GPT-5.6 Sol. The bug occurs because the EC firmware always disables charging limit control due to invalid stored limit values. The workaround involves writing to live limit and state registers to enable the limit.

This write-up documents how I fixed the Battery Charging Limit function on the MECHREVO Wujie 14XA also known as the MechRevo Forza 14X . I did this with the help of Codex and GPT-5.6 Sol. A bug in the charge-limit control logic was partially fixed https://gist.github.com/w568w/b2fc5f9d1f4dff13efe751abec27b396?permalink comment id=6254723 gistcomment-6254723 in EC firmware version 2.08. However, even with the "latest" firmware, the charging limit still often fails to take effect on many models. EC versions 2.12 and 2.08 are bundled with BIOS versions N.1.14MRO50 and N.1.14MRO19 , respectively. With Codex's help, I disassembled the EC firmware images https://github.com/minortex/GX4HRXL-firmware and identified several important addresses in the controller: | Address | Meaning | Writable via ACPI Calls | |---|---|---| 0x07B9 | The effective Live Limit, ranging from 1 to 100 percent | Yes | 0x087F | The Stored Limit | No; it is above 0x07FF | 0x0742 2 | The enable gate for the charging limit | Yes | 0x07C3 and 0x0770 | State values that may have various effects, which are still unknown to us | Yes | It seems that we should be able to control the limit simply by writing to 0x07B9 , right? No There is a caveat. The charging routine in the EC firmware works roughly as follows: bool state is uint8 t value { return xram 0x07C3 == value || xram 0x0770 == value; } // The following code is executed once per second. bool limit enabled = state is 4 || state is 5 ; if limit enabled { uint8 t stored limit = xram 0x087F & 0x7f; if stored limit == 0 || stored limit 100 { disable control ; return; } } enable control ; // Enable control using the Live Limit. store limit ; // Save the Live Limit as the Stored Limit. For this laptop model, or at least for my unit, limit enabled is unfortunately always false . The EC therefore checks stored limit , which is also an invalid value. As a result, the EC always executes disable control and returns. The Live Limit register is never read, which is why writing to 0x07B9 has no effect at all. We seem to be stuck here because we cannot change the Stored Limit directly. Its address is greater than 0x07ff , so it cannot be written through an ACPI call. So, how can we fix this? The workaround is actually quite intuitive: we can change the State values Here is my plan: - Upgrade the BIOS/EC firmware to the latest version. Either N.1.14MRO50 or N.1.14MRO19 should work. - Write a value to the Live Limit. For example, set it to 60% with xram 0x07B9 <- 0x3C . - Overwrite the State value with 4 by setting xram 0x07C3 <- 0x04 , so that limit enabled becomes true . - Optionally, wait for a second or so to allow the EC to execute store limit . Then restore the original value of 0x07C3 . - Read 0x087F to verify whether the workaround worked. This worked on my unit: bash $ upower -i /org/freedesktop/UPower/devices/battery BAT0 native-path: BAT0 vendor: OEM model: standard serial: 00001 power supply: yes updated: Wed Jul 15 02:34:42 2026 6 seconds ago has history: yes has statistics: yes battery present: yes rechargeable: yes state: fully-charged warning-level: none energy: 76.8768 Wh energy-empty: 0 Wh energy-full: 80.08 Wh energy-full-design: 80.08 Wh voltage-min-design: 15.4 V capacity-level: Normal energy-rate: 0 W voltage: 16.232 V charge-cycles: N/A percentage: 96% capacity: 100% technology: lithium-ion icon-name: 'battery-full-charged-symbolic' $ cat /sys/class/power supply/BAT0/current now 0 The battery is at 96% but is still reported as fully charged. The reported current is also zero. The attachment is a simple script that automates this process. ⚠️ Review it carefully before running it This finding also explains something else. There are reports https://gist.github.com/w568w/b2fc5f9d1f4dff13efe751abec27b396?permalink comment id=6254573 gistcomment-6254573 that flashing BIOS/EC firmware from another OEM with the same motherboard can resolve the issue. Those BIOS versions include a menu option for configuring the Stored Limit, which naturally breaks the deadlock. In short, the root cause is that Mechrevo initializes the Stored Limit to an invalid value. And because of the EC's control logic, this leaves the system trapped in a state where writes to the Live Limit are effectively ignored . Whether their engineers fully understand the hardware and firmware they are shipping is quite an interesting question.