Peter Zhurba

Custom AO725 firmware for a non-standard AL12B32/SANYO battery

This page has two parts. The first part is a simple step-by-step flashing guide for an already prepared AO725 file set. The second part describes an AI-assisted workflow that can be adapted to similar firmware tasks, but only after the model, files, and recovery method are checked separately.

Warning: flashing BIOS/EC firmware can brick the laptop. A wrong image, model, power state, recovery file, or USB drive can leave the board unusable. Do not start flashing without external power, a charged battery, verified hashes, and a prepared rescue path.

Part 1. Simple flashing guide

1. Take the required files

Download the files for flashing and verification:

If you use the prepared winpe.img.gz, ZHG108.EXE and platform.ini are usually not separate manual steps. They are verified sources and part of the prepared environment. Still keep them nearby: they help confirm exactly what is being used to flash the laptop.

Expected SHA256 values for AO725:

If a hash does not match, do not use that file.

2. Write the WinPE USB drive

Take winpe.img.gz and write it to a USB drive as a raw/dd image.

Example for Linux:

gzip -dc winpe.img.gz | sudo dd of=/dev/sdX bs=4M status=progress conv=fsync

Here /dev/sdX must be the USB drive, not the system disk.

Be careful: dd completely overwrites the selected disk. Check the device name twice before running the command.

3. Prepare the rescue USB drive

Take a separate FAT32 USB drive.

Put this file in the root directory:

ZHGBIOS.fd

Keep this USB drive nearby, but do not insert it into the working laptop unless recovery is actually needed. On the AO725, recovery is related to Fn+Esc, and it should not be started "just to test".

4. Check that this is really your case

Continue only if all of this matches:

  • laptop is Acer Aspire One 725 / AO725;
  • BIOS branch is 1.xx, not 2.xx;
  • the image is V1.08 from the ZHG family;
  • battery is reported as AL12B32 / SANYO;
  • the pre-patch symptom is sudden shutdown at about 11.6 V.

If the model, BIOS branch, or battery differs, do not flash this patched FD.

5. Verify the patched file

Compare the original and patched FD:

cmp -l zhgbiosR.fd zhgbiosR_AL12B32_profile3_to_profile0_patched.fd

Expected output is exactly one line:

55883   3   0

That corresponds to this change:

offset 0xDA4A: 03 -> 00

If there is more than one difference, do not flash the file.

6. Prepare the flashing work directory

The WinPE USB drive must contain a flashing work directory with:

InsydeFlash.exe
platform.ini
zhgbiosR.fd

In that directory, zhgbiosR.fd must be the patched file renamed from:

zhgbiosR_AL12B32_profile3_to_profile0_patched.fd

Check that the work directory contains exactly one .fd file:

dir *.fd

Expected result:

zhgbiosR.fd

7. Flash from WinPE

Connect the power adapter.

Make sure the battery is installed and charged.

Boot from the prepared WinPE USB drive.

Open the flashing work directory.

Run:

InsydeFlash.exe

During flashing:

  • do not disconnect power;
  • do not close the lid;
  • do not remove the battery;
  • do not touch the rescue USB drive;
  • wait for completion and reboot.

8. Check the result

After a successful boot, check that the laptop passes the old shutdown point around 11.6 V.

Safe check:

  • charge the battery;
  • enable battery-value logging;
  • discharge under a normal load;
  • stop at an OS software threshold, for example 30%;
  • do not pull a 3S Li-ion battery into deep discharge.

In the successful test, the laptop reached an OS-triggered shutdown at 30% and about 10.68 V, then started charging immediately after AC power was connected.

Part 2. AI-assisted workflow

For guided flashing support, use this starter prompt:

Starter prompt for a firmware-flashing AI assistant

The point of AI-assisted mode is not to let AI "guess" a firmware. Its role is different:

  • guide the operator step by step;
  • verify model, BIOS branch, and file names;
  • require a rescue plan before flashing;
  • check SHA256 and cmp;
  • stop dangerous actions;
  • prevent using a patched file on the wrong model;
  • remind that flashrom writes on a laptop with an EC are a bad path without separate analysis.

This approach can be reused for other laptops and other firmware tasks, but the AO725 files themselves cannot be reused. For another model, AI must ask again for:

  • exact device model;
  • current BIOS/EC version;
  • official firmware package;
  • standard recovery method;
  • verified hashes;
  • expected diff;
  • model-specific stop conditions.

AO725-specific hashes, ZHGBIOS.fd, the patched FD, and offset 0xDA4A: 03 -> 00 apply only to the investigated Acer Aspire One 725.

What the patch changes

The new compatible AL12B32/SANYO battery charged and was detected by Linux, but the AO725 suddenly powered off during discharge at about 11.6 V. EC firmware analysis showed that AL12B32 selected battery profile selector 03, and that profile contains an early threshold around 11600 mV.

The patch changes exactly one value:

offset 0xDA4A: 03 -> 00

Meaning:

before: AL12B32 -> selector 3 -> profile 3
after:  AL12B32 -> selector 0 -> profile 0

The goal is to remove the hardware-looking cutoff around 11.6 V and let the OS perform a controlled shutdown at its configured threshold.

Tools used to study the firmware

The investigation and firmware preparation used:

  • Linux shell/coreutils: sha256sum, cmp, dd, od, find, mount, umount, sync;
  • Python 3 for binary analysis, offset search, and diff verification;
  • InsydeFlash for the standard Windows/WinPE flashing path;
  • WinPE as the service environment;
  • flashrom only for probe/read-only SPI chip assessment, not for writing;
  • iasl for ACPI/DSDT battery and EC path analysis;
  • strings and binary search inside the firmware image;
  • UEFI/IFR analysis tools for Setup/IFR and hidden BIOS variable analysis;
  • 7-Zip or a similar archive tool for unpacking vendor packages and preparing work directories.