Jolla C2 battery capacity reporting is broken, potentially after complete battery drain

Bug Reports
1

REPRODUCIBILITY: unknown
OS VERSION: 5.0.0.72 (Tampella) HARDWARE: Jolla C2 (Reeder S19 Max Pro S, Unisoc UMS9230/Tiger T606) UI LANGUAGE: German REGRESSION: Unknown - may have existed since release, became apparent after complete battery drain

DESCRIPTION:
I consulted claude “ai” in this issue and generated this bug report with claude. I don’t know what is true or what is speculation. So this report might be completely wrong. I just wanted to avoid reflashing Sailfish OS, but I will do that now after a backup. Here is the generated report:

Battery OCV (Open Circuit Voltage) tables fail to load due to a device tree / kernel driver property name mismatch. The driver sprd_battery_info.ko looks for monitored-battery-id-0 but the device tree only contains monitored-battery. This causes voltage_max_design to return -1 or 0 instead of 4400000, battery percentage drifting from actual charge state, all table lengths returning -22 (EINVAL), and potential unexpected shutdowns despite battery having charge.

PRECONDITIONS:

Issue becomes apparent after complete battery drain, but the underlying DT/driver mismatch likely exists on all Jolla C2 devices.

STEPS TO REPRODUCE:

  1. Check voltage_max_design: cat /sys/class/power_supply/battery/voltage_max_design

  2. Check dmesg for table loading: dmesg | grep ocv_table_len

  3. Check for property mismatch: find /sys/firmware/devicetree/base -name “monitored-battery*”

EXPECTED RESULT:

voltage_max_design should return 4400000, OCV tables should load successfully (positive table lengths), device tree should contain monitored-battery-id-0 matching what driver expects.

ACTUAL RESULT:

voltage_max_design returns -1 or 0. dmesg shows: ocv_table_len = -22, temp_table_len = -22, rabat_table_len = -22, basp_ocv_table_len = -22, basp_full_design_table_len = -22, basp_voltage_max_table_len = -22. Device tree only has monitored-battery, not monitored-battery-id-0. Driver logs “Mmatch: bat.id= fail in cmdline” (before cmdline patch) or silently fails to find monitored-battery-id-0 (after cmdline patch).

MODIFICATIONS:

Attempted fixes (blocked by locked bootloader/AVB): Patched hybris-boot.img cmdline to add bat.id=0 charge.basp=0 (partially helps). Patched DTBO to add monitored-battery-id-0 properties (blocked by AVB verification). Attempted to disable AVB via vbmeta flags=2 (blocked by locked bootloader).

ADDITIONAL INFORMATION:

Root Cause Analysis:

The kernel driver sprd_battery_info.ko expects device tree property format monitored-battery-id-X but the actual device tree (DTBO entry 1, dtbo_idx=1) only contains monitored-battery. Driver string analysis confirms this - strings /lib/modules/$(uname -r)/sprd_battery_info.ko | grep monitored shows “monitored-battery” and “Fail to get monitored-battery-id-%d”.

The property exists in 6 locations in the DTBO that need the -id-0 variant added: charger-manager node, fgu@c00 node, charger@6b node, and three local_fixups entries.

Evidence:

Basic battery parameters ARE detected internally (proving hardware is fine). cat /sys/class/power_supply/sc27xx-fgu/debug/dump_info shows max_volt:4400000, min_volt:3500000, total_mah:4096. But they cannot be exported via sysfs because table parsing fails.

Proposed Fix:

Either (1) update DTBO to add monitored-battery-id-0 properties alongside monitored-battery, or (2) update sprd_battery_info.ko driver to fall back to monitored-battery when monitored-battery-id-X not found.

User Workaround Blocked:

We successfully created a patched DTBO with monitored-battery-id-0 added using dtc decompile/recompile, but AVB rejects the modified DTBO (different hash), bootloader is locked so cannot flash via fastboot, cannot modify vbmeta to disable AVB (also blocked), and direct dd to partition works but boot fails with “no valid os found”.

Request:

(1) Can this DT/driver mismatch be fixed in a future Sailfish OS update? (2) Is there a way to unlock the bootloader or flash signed modified DTBO? (3) Can Jolla provide a corrected DTBO image?

Technical Details:

PMIC: SC2730, Fuel Gauge: SC27XX FGU, DTBO entry 1: offset=0xa93e size=0xa5b3 (42419 bytes), Kernel modules: sc27xx_fuel_gauge.ko sprd_battery_info.ko sprd-charger-manager.ko, Boot cmdline requires: bat.id=0 charge.basp=0

2

oh here is the link to the conversation, maybe that’s helpful: https://claude.ai/share/127cbc39-2f00-49e1-9967-7ad53ed0331c

3

I this a joke?

Delete?

2 Likes
4

Thanks for providing the conversation log, it is much more helpful than the bug report.

Can you try the following after fully charging the phone (that is, after /sys/class/power_supply/sgm41511_charger/status reports Full)?

echo 1000 > /sys/class/power_supply/sc27xx-fgu/calibrate
echo 1000 > /sys/class/power_supply/sc27xx-fgu/capacity
reboot

(The suggestion to write “1” to the “calibrate” property was wrong, it set the capacity to 0.1%)

3 Likes
5

Also, please undo all the boot image modifications that were suggested by Claude. They should not be necessary and may even cause some additional problems.

Looking at the driver code, you can see that the suggestion to change the DTBO to replace monitored-battery with monitored-battery-id-0 is not correct, the driver actually looks for monitored-battery: s19mps-kernel/drivers/power/supply/sprd_battery_info.c at master · mer-hybris/s19mps-kernel · GitHub

The “Missing bat.id= in kernel cmdline” is also not a problem, since the battery ID defaults to 0 (which is normal if there is only one battery).

In general, do not rely on “AI” tools to diagnose such problems correctly. Unfortunately Android vendor kernels have a lot of non-standard behavior - they may be showing error messages all over the place while still working as intended. So it’s better to compare this with a working phone before making conclusions about the cause of your problem.

The Jolla C2 actually does not store a lot of calibration data for the battery. Besides the device tree, which should never change, it only remembers the last state of charge before across reboots. If this becomes out of sync with the battery, it may be helpful to run the command I suggested above or leave the phone turned off for a bit longer than 15 minutes.

6 Likes
6

thank you very much, i wanted to run the commands, but since it is not my phone i didn’t have always access to it and now it doesn’t display anything anymore. i can flash it, but that’s all. maybe i ruined it by setting the capacity to 0.1%? but then a reflash should reset that maybe, i don’t know.

7

oh, it booted and i’m restoring the backup now. then i will apply those two commands. thank you for your help.