u-boot low-battery handling

Andy Green andy at openmoko.com
Tue Aug 26 20:43:38 CEST 2008

Hash: SHA1

Somebody in the thread at some point said:
| On Mon, Aug 25, 2008 at 07:08:43PM -0300, Werner Almesberger wrote:
|> 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.
| you call it over-optmizied.  I call it the only solution that I could
come up
| with, and that is still adhering to the spec of the NAND chip in
question.  You

Harald I still think you did a marvellous job doing this stuff, don't
take these moans as complaints on your breaking ground making a working
shipping system.  It's just the raw NAND is getting compared to ease of
accessing NAND hidden inside SD Card where all this detail is hidden,
and it doesn't make having to deal with raw NAND at all look pretty.
The NOR / write-once thing being stuck with what it is now with
knowledge about specific ECC and partition scheme also makes moving off
it hard.

| would have had to have about 1.5MB spare space in each partition in
order to
| account for the possible worst-case but still within vendor spec
factory bad
| block situation.  That's a lot of wasted space, something that you cannot
| afford with 64MByte total size, and probably still don't want to waste
| 256MB.

Because we shift to SD Card rootfs, the NAND is sort of embarrassment of
riches now.  We have it as glorified backup boot at the moment, so
blowing some MB doesn't hurt.

|> Plan C: accept that sort of palative treatment for u-boot, fully
|> aware that this makes it terminally unmaintainable.
| just because you don't like it, it's not unmaintainable.  From my
| u-boot is getting more maintainable (and better maintained) every month.

I think he's talking about the power stuff in U-Boot specifically.  The
power stuff in Linux is tough but our power stuff in U-Boot is really
pretty bad.  Ignoring if U-Boot itself is good or bad we make a good
move taking that much from bootloader and consolidating all the power
logic into pcf50633 driver in Linux I think.

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


More information about the openmoko-kernel mailing list