Disallowing draining until bricking

andrzej zaborowski balrogg at gmail.com
Fri Jul 18 00:47:13 CEST 2008


2008/7/17 Mike (mwester) <mwester at dls.net>:
> Andy Green wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hi -
>>
>> Folks in the wild have managed to drain their battery until it is not
>> able to get the device over the VB_SYS problem on startup even with USB
>> connected.
>>
>> As I see it there's a bunch of things we need to do to work towards
>> disallowing this as something that can be done easily.
>>
>> 1: our battery monitoring stuff lives in the X world at the moment.  For
>> our purposes this either needs to become a daemon, or because of the
>> critical nature of battery monitoring with this issue, better leave it
>> as it is in X and add a kernel thread for this purpose alone.
>
> (Is there a smiley symbol for biting one's tongue?)
>
>> 2: PMU has LOWBAT concept based on VB+ pin of battery level.  But, we
>> need some considerable juice left in our battery to work around VB_SYS
>> dip issue on next start.  So, better that we monitor it from the kernel
>> thread via HDQ where possible to learn true "capacity" figure and turn
>> ourselves OFF if no USB and we reach say 3% capacity.  Separately

PalmOS had a nice solution: at ~10% capacity it would suspend and
refuse to resume until the bootloader can see that battery is above
~20% again. The ~10% was enough for at least three weeks. With modem
forced off maybe we could reach a couple of days on Neo, that would
perhaps be enough for non tech users to (almost) never have to witness
the system boot up.

>> userspace stuff can be looking at this as well and reacting earlier with
>> UI feedback about critical battery state.  But in the kernel, this
>> critical action has less dependencies and we need to do it whether
>> userspace is happy or not, or we brick the device for the user.
>>
>> 3: Suspend needs the wake scheduler that I mentioned a few times.  We
>> can book a wake from suspend periodically (period depends on capacity
>> before suspend) and still turn ourselves OFF even from suspend at the 3%
>> level, for the case it's stuck in a drawer for a month in suspend.
>>
>> 4: Stuff like PANIC response needs to time out and go OFF.

S3C24xx has a watchdog timer for this (not sure if it's enabled in our
current defconfig). The watchdog timer causes a reset and u-boot will
know the reset came from the watchdog and can shut down. It is enabled
through /sys or kernel params.

Regards




More information about the openmoko-kernel mailing list