Hey joerg_rw! Thanks for coming here to help us. Common sense also tell me that it's possible only by some hw effect, but for some reason, it doesn't seem right for me. You're perfectly right that many things said there were just assumptions - that's why lot of #fixme - but especially two things doesn't fit IMO for hardware fail theory. First, jvollmann find posts from other users having same issues - they claimed that Nokia Care solved it flashing via serial pins beneath battery. Still I don't buy it as-is, cause I see no reasons why unprotected D+/D- pins could result in "deeper" reflash, but... Then, despite fact You've suggested to scratch totally one of my posts (and I'm sure You're right about that - just to avoid misunderstanding), I think You'll agree that further update by jvollmann about his typo in command, resulting in false "0" for "charge_full_design", thus leaving only: cat /sys/class/power_supply/bq27200-0/capacity 0 cat /sys/class/power_supply/bq27200-0/charge_full 0 cat /sys/class/power_supply/bq27200-0/charge_now 0 cat /sys/class/power_supply/bq27200-0/time_to_empty_avg 0 cat /sys/class/power_supply/bq27200-0/time_to_empty_now 0 cat /sys/class/power_supply/bq27200-0/time_to_full_now 0
...as 0 may root from chip's inability to perform ANY calibration (as per 412b and shadowjk's posts, it's performed internally no matter if You use stock kernel or power-kernel), cause jvollmann isn't able to charge via USB cable (only charging battery externally). Mix it with many full reflash procedures - including cold reflash and EMMC reflash (yea, not quite relevant, but You know what i mean), and this may be why capacity, charge_full, charge_now, both "times to empty" and "time to full" are 0's. Then, charge_full_design shown as "2056320" , which is calculated by measuring resistance between ID pin and ground (thus being totally wrong, by the way), mean that ID pin IS probed correctly, right?
--- As for Your question, correct values for BSI are: 32-85 - Service battery, result in "LOCAL" bootstate 87-176 - Test battery, result in "TEST" bootstate 280-568 - Normal battery, no bootstate change, continue checking. Everything else - "UNKNOWN" and shutdown, except R&D mode. While 28-568 result in our perfectly fine load, I have no idea how LOCAL or TEST bootstates affect booting. It seems that scripts in /sbin/preinit/ and /etc/ that call getbootstate decide what to do - they're open, so probably, we can check that
1. That's why I told You about SDK/scartchbox - many "include" at the beginning, which You probably don't have with only gcc. 2. IF it works, You'll definitely be able to charge battery - it return exact same state as NORMAL (280-568), so no reasons why Your battery should be threaten differently. Charging with "UNKNOWN" doesn't work in R&D, cause Nokians use "dummy" batteries (false battery attached to main DC power source) in their workdesk's, so they don't want N900 to put power back into main by any means Everything above is correct only if (we assume that it will work at all, of course) there is no real serious hardware damage to charging chip. Which I think is most unlikely - keep in mind that joerg_rw seems to think otherwise, and he is MUCH (threat MUCH as multiplied by n times ) more experienced than me. So only time will tell