current focus

[Werner Almesberger]

Sean McNeil wrote:
> Can u-boot be modified to bring up the system differently so that it  
> doesn't exceed the power budget?

It can be modified that it gets at least far enough to communicate with
the USB host to detect 500mA mode, detect the wall adapter, and to
enable the charger. The backlight has to stay off, so I haven't tried
to actually boot with all the power saving. This would be something to
explore for when we get rid of u-boot and move PMU control into the
kernel.

Here's my proof of concept:
http://people.openmoko.org/werner/gta02-chg/program.html

Note that this patch yields a u-boot that does not boot. Instead, it
does things that are useful for measurements. I still have to properly
integrate this into u-boot. (Need to finish my current batch of
experiments first, though.)

Here's a bit more background material:
http://svn.openmoko.org/developers/werner/meas/chg/

In each of the following subdirectories, there's the result of one of
the power reduction changes:

- usb-100: situation before any changes
- cpu-200: CPU frequency lowered to 200MHz
- ldo-off: unnecessary rails turned off
- choke-glamo: Glamo turned off
- cpu-idle: enter IDLE mode while waiting for power

> This sounds like it can't be worked around in software. Correct?

When a device has that problem, software can do very little. The system
doesn't even come out of reset. The only thing that can be done is to
set the PMU state such that it isn't particularly hostile when trying to
power up. (Some of the PMU settings are preserved when power cycling.)

> Can the demand on the power rails be mitigated by turning things on
> over a longer period of time?

The order in which power rails are brought up is hard-wired in the PMU
so we can't change that. Wish that we could ...

- Werner