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
