Re: [Gumstix-users] Overo boot time; power management

[R. P. M. <log...@gm...>]

It is possible to get the Earth boards down to approx. 12mA in idle mode.

You have to put the SDRAM into self-refresh, stop all CPU internal
clocks and PLLs, turn off the USB PHY, shutdown all TPS internal PHYs
and clocks, and bring all TPS voltages down to minimum. When
restarting from a GPIO event the system runs at 13mHz by setting the
main clock divider to divide by 2. You also need to put the restart
code into the internal SRAM since the SDRAM is not available until it
is brought out of self-refresh.

But, we don't use Linux, or uBoot, or Xloader so unfortunately I can't
post the actual code, but hopefully this will give you an idea of
where to proceed.

I think the main reason it can't go lower than 12mA is because the
external 26MHz clock is always on and there is no control to turn it
off. I hope that the next version from Gumstix can correct this
problem. 12mA is really too high for a static state IMO. I think that
<3mA should be achievable with the right combination of controls in
place. The OMAP chip can support shutting down of the 26MHz clock in
idle modes but the Gumstix wiring does not appear to be configured for
this.

On 5/5/10, Greg <gu...@mo...> wrote:
>
> Thanks...
>
> On the other aspect of this: Does anyone else have any information, on how
> low the gumstix power dissipation can be driven, if the gumstix is idle?
> Are there low power modes that are available, for example, if all running
> threads are blocked, or in other circumstances?
>
> Since the gumstix (apparently) can't in fact fully shut itself down, how
> close is it possible to get to a sort of low-power standby state?
>
> Thanks, Greg
>
> At 04:29 AM 5/5/2010, you wrote:
>
>>I'm interested in doing this myself.  I haven't actually timed it, but
>> right now it seems to take our system (running gumstix overo summit pack)
>> about 30 seconds to boot.  I could likely decrease the time somewhat by
>> not having different services starting like ssh or broadcasting for a dhcp
>> address.
>>
>>As for power management, I haven't had much luck yet.  I read somewhere
>> about running 'echo mem > /sys/power/state', but that seems to just
>> immediately return to a prompt after displaying some messages that
>> appeared to be simulating going to sleep when I run it.  I did notice that
>> 'no apm support in kernel' does display on bootup, but don't know if apm
>> is needed for ALL power management functions, or just more advanced ones.
>>
>>On Thu, Apr 29, 2010 at 12:09 PM, Greg
>> <<mailto:gu...@mo...>gu...@mo...>
>> wrote:
>>
>>I'm contemplating a battery-powered application, where an Overo would need
>> to repeatedly place itself into a low-power standby state; typical usage
>> would involve waking up the Overo (through a keypress or other sort of
>> interrupt), running it for 30-60 seconds, and then placing it back into
>> standby until the next usage.  So I'm having two questions:
>>
>>1) Is anyone doing something similar, and finding it to work with a high
>> level of reliability?
>>
>>2) How long does it take for an Overo to boot, from a cold start (as
>> opposed to from a standby state)?  My recollection from using a Verdex a
>> couple of years ago, was that boot times were up around 60-90 seconds,
>> which would be very long by comparison to what I'm needing now...
>>
>>Thanks;
>>
>>Greg
>