u-boot low-battery handling

Andy Green andy at openmoko.com
Tue Aug 26 00:40:36 CEST 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:
| Andy Green wrote:
|> Maybe the best way to come at this is going to be move GTA02 to Qi
|
| Wish that was easy ... but then the over-optimized partitioning
| scheme bites us :-( Of course, just wiping out the entire NAND and
| setting up something sane would help.

What do you mean here as "over-optimized", the dynparts business?

Holger would like to see the NAND nuked so we can enable his hardware
ECC patches by default, which is a nice win on speed to balance the
hassle so people will be okay with it I think.  But I guess we open up
some space beween GTA01 and GTA02 then in terms of NAND handling in kernel.

Qi can do GTA01 without too much hassle, but it's a really big step for
that device since blowing the bootloader there is scary, I don't know it
is a good idea to be proposing it.  When GTA03 SD is done most of the
pieces are just sitting there already for a port though.

| Then we still have u-boot in NOR to worry about, which will still use
| the dynamic partitions, so it's only good for replacing qi, not for
| touching the rest. But I guess that's bearable.

Good old write-once.

| Plan B would be to make u-boot stay below the 100mA limit unless
| someone explicitly asks for the boot menu. How does that sound ?
...
| Plan C: accept that sort of palative treatment for u-boot, fully
| aware that this makes it terminally unmaintainable.

Reality is we have to engage with this at pcf50633 kernel driver for
GTA03, I think when we did that, we prefer to use the same path.  At the
least we try some different ways there and can maybe learn something to
apply here.

For example we may need the spinning action in U-Boot in pcf50633 for
GTA03 under 100mA / PC USB power circumstance, since at some point Linux
would otherwise bring up GSM.  Then if we did it, we might like to
remove it from U-Boot since 100mA limit boot into Linux is also mandated
there.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkizNOQACgkQOjLpvpq7dMrfOACfansnWwgRaeqy/WCQiaLwXyDu
EVkAnihOo0tVTHKF5QxM9e6R8zP9XWJg
=KGsC
-----END PGP SIGNATURE-----



More information about the openmoko-kernel mailing list