gumstix

Overo's are pr default shipped with the 600Mhz OMAP3 version. BeagleBoards
are shipped with the 720MHz (or 1GHz for Beagle XM :-)
The 600MHz mode is however considered an overdrive mode, which might shorten
the devices lifetime (see the datasheet - omap3530.pdf)

Taken from the datasheet (OPP5 = 600MHz overdrive mode):
--------------------------------------------------------
To avoid significant device degradation for commercial temperature
OMAP3530/OMAP3525 devices 
(0°C < Tj < 90°C), the device power-on hours (POH) must be limited to one of
the following:
* 100K total POH when operating across all OPPs and keeping the time spent
at OPP5 to less than 23K POH.
* 50K total POH when operating exclusively at OPP5.
* 44K total POH with no restrictions to the proportion of these POH at
operating points OPP1 - OPP5.
--------------------------------------------------------

I hope this clarified why it's pr. Default configured to 500MHz? - Best
regards
  Søren

---
SSC Solutions ApS - Denmark - http://www.ssc-solutions.dk

so taking it to the 600 or 720 its suppose to handle would shorten the
life of the overo? Is that correct? I read a thread that Don Anderson
wrote a reply that says they are shipped 600 but why would mine show
500 regardless?

Frustrating trying to sort out one problem and come across 50 more
each time, wish things were more clearly documented by gumstix on
things like this and others. :P Thanks for the info though

On Fri, Aug 27, 2010 at 1:06 PM, Søren Steen Christensen
<lists@...> wrote:
> Overo's are pr default shipped with the 600Mhz OMAP3 version. BeagleBoards
> are shipped with the 720MHz (or 1GHz for Beagle XM :-)
> The 600MHz mode is however considered an overdrive mode, which might shorten
> the devices lifetime (see the datasheet - omap3530.pdf)
>
> Taken from the datasheet (OPP5 = 600MHz overdrive mode):
> --------------------------------------------------------
> To avoid significant device degradation for commercial temperature
> OMAP3530/OMAP3525 devices
> (0°C < Tj < 90°C), the device power-on hours (POH) must be limited to one of
> the following:
> * 100K total POH when operating across all OPPs and keeping the time spent
> at OPP5 to less than 23K POH.
> * 50K total POH when operating exclusively at OPP5.
> * 44K total POH with no restrictions to the proportion of these POH at
> operating points OPP1 - OPP5.
> --------------------------------------------------------
>
> I hope this clarified why it's pr. Default configured to 500MHz? - Best
> regards
>  Søren
>
> ---
> SSC Solutions ApS - Denmark - http://www.ssc-solutions.dk
>
>
>
> ------------------------------------------------------------------------------
> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
> Be part of this innovative community and reach millions of netbook users
> worldwide. Take advantage of special opportunities to increase revenue and
> speed time-to-market. Join now, and jumpstart your future.
> http://p.sf.net/sfu/intel-atom-d2d
> _______________________________________________
> gumstix-users mailing list
> gumstix-users@...
> https://lists.sourceforge.net/lists/listinfo/gumstix-users
>

Whoops - A bit too fast - Fire and Water are actually shipped with the
720MHz OMAP3 version - Sorry I didn't catch this prior to now. 
All chips are however currently just configured for 500MHz and the user need
to change it if wanted (i.e. by setting mpurate to 720 in the U-boot
environment)...

The same story about overdrive is however still valid... From the latest
datasheet (OPP5 and 6 are now considered overdrive modes - It's
unfortunately not 100% clear to me if OPP5 is considered an overdrive mode
for the 720MHz version - or only for the 600MHz version ... :-)
-------------------------------------------------------------------------
To avoid significant device degradation for commercial temperature
OMAP3530/OMAP3525 devices 
(0°C < Tj < 90°C), the device power-on hours (POH) must be limited to one of
the following:
* 100K total POH when operating across all OPPs and keeping the time spent
at OPP5-OPP6 to less than 23K POH.
* 50K total POH when operating at OPP5 - OPP6.
* 44K total POH with no restrictions to the proportion of these POH at
operating points OPP1 - OPP6.
To avoid significant device degradation for extended temperature
OMAP3530A/OMAP3525A devices
-------------------------------------------------------------------------

Best regards
  Søren

---
SSC Solutions ApS - Denmark - http://www.ssc-solutions.dk

> so taking it to the 600 or 720 its suppose to handle would shorten the
> life of the overo? Is that correct? 
YES

> I read a thread that Don Anderson
> wrote a reply that says they are shipped 600 but why would mine show
> 500 regardless?
I don't recall this thread - As indicated in my previous post I think you
can easily fix this by setting mpurate in U-boot

> Frustrating trying to sort out one problem and come across 50 more
> each time, wish things were more clearly documented by gumstix on
> things like this and others. :P Thanks for the info though
OMAP and OMAP-linux is still pretty new to the public and a lot of stuff
have to be fixed/cleaned up. 

It's however getting better and better day after day I think
  Søren :-)

---
SSC Solutions ApS - Denmark - http://www.ssc-solutions.dk

Could you give more info or a resource as to how to set the DSP and ARM
clock rate in u-boot please?

AJ ONeal

Just add "mpurate=720" to your bootargs variable...

Alternatively you can use the cpufreq tools in Linux
  Søren

---
SSC Solutions ApS - Denmark - http://www.ssc-solutions.dk

thanks soren :) Would you also know the correct way to change the
i2c_bus? I see everyone says to to i2c_bus=3,100 but when I run that
in uboot it doesnt seem to work as it still runs at 400?

On Fri, Aug 27, 2010 at 1:52 PM, Søren Steen Christensen
<lists@...> wrote:
> Just add "mpurate=720" to your bootargs variable...
>
> Alternatively you can use the cpufreq tools in Linux
>  Søren
>
> ---
> SSC Solutions ApS - Denmark - http://www.ssc-solutions.dk
>
>
> ------------------------------------------------------------------------------
> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
> Be part of this innovative community and reach millions of netbook users
> worldwide. Take advantage of special opportunities to increase revenue and
> speed time-to-market. Join now, and jumpstart your future.
> http://p.sf.net/sfu/intel-atom-d2d
> _______________________________________________
> gumstix-users mailing list
> gumstix-users@...
> https://lists.sourceforge.net/lists/listinfo/gumstix-users
>

> thanks soren :) Would you also know the correct way to change the
> i2c_bus? I see everyone says to to i2c_bus=3,100 but when I run that
> in uboot it doesnt seem to work as it still runs at 400?

Doesn't it work adding this to bootargs? It has been a while since I last
time tried, but at that time I think it worked...
- I do unfortunately not have a setup just in front of me right now, so I
can't give it a try :-(...

Remember that dependent on you U-boot version/setup bootargs might be
changed dependent on mmc- or nand-boot.
The actual string passed to the Linux kernel can be checked by "cat
/proc/cmdline" in the Linux console

Best regards - Good luck
  Søren

---
SSC Solutions ApS - Denmark - http://www.ssc-solutions.dk

Søren is correct about the reason that 500 Mhz is the default.

I've had many requests to change this such that u-boot automatically
sets the clock rate to the maximum for the version of the processor
being used.

What do folks think?  Should we leave 500 Mhz as the default, or allow
u-boot to automatically set it to 600 or 720 Mhz?

Steve

On Fri, Aug 27, 2010 at 1:20 PM, Søren Steen Christensen
<lists@...> wrote:
> Whoops - A bit too fast - Fire and Water are actually shipped with the
> 720MHz OMAP3 version - Sorry I didn't catch this prior to now.
> All chips are however currently just configured for 500MHz and the user need
> to change it if wanted (i.e. by setting mpurate to 720 in the U-boot
> environment)...
>
> The same story about overdrive is however still valid... From the latest
> datasheet (OPP5 and 6 are now considered overdrive modes - It's
> unfortunately not 100% clear to me if OPP5 is considered an overdrive mode
> for the 720MHz version - or only for the 600MHz version ... :-)
> -------------------------------------------------------------------------
> To avoid significant device degradation for commercial temperature
> OMAP3530/OMAP3525 devices
> (0°C < Tj < 90°C), the device power-on hours (POH) must be limited to one of
> the following:
> * 100K total POH when operating across all OPPs and keeping the time spent
> at OPP5-OPP6 to less than 23K POH.
> * 50K total POH when operating at OPP5 - OPP6.
> * 44K total POH with no restrictions to the proportion of these POH at
> operating points OPP1 - OPP6.
> To avoid significant device degradation for extended temperature
> OMAP3530A/OMAP3525A devices
> -------------------------------------------------------------------------
>
> Best regards
>  Søren
>
> ---
> SSC Solutions ApS - Denmark - http://www.ssc-solutions.dk
>
>
> ------------------------------------------------------------------------------
> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
> Be part of this innovative community and reach millions of netbook users
> worldwide. Take advantage of special opportunities to increase revenue and
> speed time-to-market. Join now, and jumpstart your future.
> http://p.sf.net/sfu/intel-atom-d2d
> _______________________________________________
> gumstix-users mailing list
> gumstix-users@...
> https://lists.sourceforge.net/lists/listinfo/gumstix-users
>

My preference would be that u-boot set the maximum non-overdrive frequency for the CPU.

If the user wants to shorten the part life by increasing it from there, then that's their choice, but with a COM straight "out of the box" it will run at the highest speed that it safely supports, rather than all COMs running at the same speed irrespective of the actual CPU speed.

Even looking at the worse-case scenario, with a restriction of 50k POH to run at OPP5 or OPP6, we're still talking 5 years and 8 months of 24/7 operation...

Kai

On 28/08/2010, at 1:12 PM, Steve Sakoman wrote:

> Søren is correct about the reason that 500 Mhz is the default.
> 
> I've had many requests to change this such that u-boot automatically
> sets the clock rate to the maximum for the version of the processor
> being used.
> 
> What do folks think?  Should we leave 500 Mhz as the default, or allow
> u-boot to automatically set it to 600 or 720 Mhz?
> 
> Steve
> 
> On Fri, Aug 27, 2010 at 1:20 PM, Søren Steen Christensen
> <lists@...> wrote:
>> Whoops - A bit too fast - Fire and Water are actually shipped with the
>> 720MHz OMAP3 version - Sorry I didn't catch this prior to now.
>> All chips are however currently just configured for 500MHz and the user need
>> to change it if wanted (i.e. by setting mpurate to 720 in the U-boot
>> environment)...
>> 
>> The same story about overdrive is however still valid... From the latest
>> datasheet (OPP5 and 6 are now considered overdrive modes - It's
>> unfortunately not 100% clear to me if OPP5 is considered an overdrive mode
>> for the 720MHz version - or only for the 600MHz version ... :-)
>> -------------------------------------------------------------------------
>> To avoid significant device degradation for commercial temperature
>> OMAP3530/OMAP3525 devices
>> (0°C < Tj < 90°C), the device power-on hours (POH) must be limited to one of
>> the following:
>> * 100K total POH when operating across all OPPs and keeping the time spent
>> at OPP5-OPP6 to less than 23K POH.
>> * 50K total POH when operating at OPP5 - OPP6.
>> * 44K total POH with no restrictions to the proportion of these POH at
>> operating points OPP1 - OPP6.
>> To avoid significant device degradation for extended temperature
>> OMAP3530A/OMAP3525A devices
>> -------------------------------------------------------------------------
>> 
>> Best regards
>>  Søren
>> 
>> ---
>> SSC Solutions ApS - Denmark - http://www.ssc-solutions.dk
>> 
>> 
>> ------------------------------------------------------------------------------
>> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
>> Be part of this innovative community and reach millions of netbook users
>> worldwide. Take advantage of special opportunities to increase revenue and
>> speed time-to-market. Join now, and jumpstart your future.
>> http://p.sf.net/sfu/intel-atom-d2d
>> _______________________________________________
>> gumstix-users mailing list
>> gumstix-users@...
>> https://lists.sourceforge.net/lists/listinfo/gumstix-users
>> 
> 
> ------------------------------------------------------------------------------
> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
> Be part of this innovative community and reach millions of netbook users 
> worldwide. Take advantage of special opportunities to increase revenue and 
> speed time-to-market. Join now, and jumpstart your future.
> http://p.sf.net/sfu/intel-atom-d2d
> _______________________________________________
> gumstix-users mailing list
> gumstix-users@...
> https://lists.sourceforge.net/lists/listinfo/gumstix-users

Hi Kai,

> My preference would be that u-boot set the maximum non-overdrive frequency
for the CPU.
Agree :-)

> If the user wants to shorten the part life by increasing it from there,
then that's their 
> choice, but with a COM straight "out of the box" it will run at the
highest speed that it 
> safely supports rather than all COMs running at the same speed
irrespective of the actual 
> CPU speed.
This is that current setting. AFAIK 500MHz is the highest safe frequence for
all versions, 
although I'm not 100% sure if the 720MHz version could run at 600MHz safely
as well - I think not... 
I will though try to check... 

> Even looking at the worse-case scenario, with a restriction of 50k POH to
run at OPP5 or OPP6,
> we're still talking 5 years and 8 months of 24/7 operation...
This is kind of talking against the argument you gave above? Or am I missing
something? 

Best regards
  Søren

---
SSC Solutions ApS - Denmark - http://www.ssc-solutions.dk

On Sat, Aug 28, 2010 at 1:10 AM, Søren Steen Christensen
<lists@...> wrote:
> Hi Kai,
>
>> My preference would be that u-boot set the maximum non-overdrive frequency
> for the CPU.
> Agree :-)
>
>> If the user wants to shorten the part life by increasing it from there,
> then that's their
>> choice, but with a COM straight "out of the box" it will run at the
> highest speed that it
>> safely supports rather than all COMs running at the same speed
> irrespective of the actual
>> CPU speed.
> This is that current setting. AFAIK 500MHz is the highest safe frequence for
> all versions,
> although I'm not 100% sure if the 720MHz version could run at 600MHz safely
> as well - I think not...
> I will though try to check...

Probably a dumb question here. But if the safest speed is 500 for the
fire and anything higher would be overclocking it, why is it listed as
a 720mHz processor? Just because its capable of going to that?


>
>> Even looking at the worse-case scenario, with a restriction of 50k POH to
> run at OPP5 or OPP6,
>> we're still talking 5 years and 8 months of 24/7 operation...
> This is kind of talking against the argument you gave above? Or am I missing
> something?
>
> Best regards
>  Søren
>
> ---
> SSC Solutions ApS - Denmark - http://www.ssc-solutions.dk
>
>
>
> ------------------------------------------------------------------------------
> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
> Be part of this innovative community and reach millions of netbook users
> worldwide. Take advantage of special opportunities to increase revenue and
> speed time-to-market. Join now, and jumpstart your future.
> http://p.sf.net/sfu/intel-atom-d2d
> _______________________________________________
> gumstix-users mailing list
> gumstix-users@...
> https://lists.sourceforge.net/lists/listinfo/gumstix-users
>

On 28/08/2010, at 6:10 PM, Søren Steen Christensen wrote:

> Hi Kai,
> 
>> My preference would be that u-boot set the maximum non-overdrive frequency
> for the CPU.
> Agree :-)
>> 

[snip]

>> Even looking at the worse-case scenario, with a restriction of 50k POH to
> run at OPP5 or OPP6,
>> we're still talking 5 years and 8 months of 24/7 operation...
> This is kind of talking against the argument you gave above? Or am I missing
> something? 

No, I was merely thinking out loud - I think that the Overo should ship in a safe configuration that is rated for many years of use, but should someone need more performance, you're still looking at over 5 years of continuous reliable service.

Putting an Overo in, for example, an automotive application where the lifespan of the vehicle (hopefully) a lot longer than 5 years and you'd want it to be running at the stock speed, but if it's for a consumer application with a design lifespan of 3-4 years (of 24-7 operation, mind you) then you should be good to ramp up the speed to max...

What about the DSP? How can that speed be set?

Thanks

AJ ONeal


On Fri, Aug 27, 2010 at 2:52 PM, Søren Steen Christensen <
lists@...> wrote:

> Just add "mpurate=720" to your bootargs variable...
>
> Alternatively you can use the cpufreq tools in Linux
>   Søren
>
> ---
> SSC Solutions ApS - Denmark - http://www.ssc-solutions.dk
>
>
>
> ------------------------------------------------------------------------------
> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
> Be part of this innovative community and reach millions of netbook users
> worldwide. Take advantage of special opportunities to increase revenue and
> speed time-to-market. Join now, and jumpstart your future.
> http://p.sf.net/sfu/intel-atom-d2d
> _______________________________________________
> gumstix-users mailing list
> gumstix-users@...
> https://lists.sourceforge.net/lists/listinfo/gumstix-users
>

So is that speed (DSP) not settable then? Just curious, I am trying to
write down as much info as I can so when I get to needing that I have
the info jotted down.



On Sat, Aug 28, 2010 at 3:33 PM, AJ ONeal <coolaj86@...> wrote:
> What about the DSP? How can that speed be set?
> Thanks
> AJ ONeal
>
>
> On Fri, Aug 27, 2010 at 2:52 PM, Søren Steen Christensen
> <lists@...> wrote:
>>
>> Just add "mpurate=720" to your bootargs variable...
>>
>> Alternatively you can use the cpufreq tools in Linux
>>  Søren
>>
>> ---
>> SSC Solutions ApS - Denmark - http://www.ssc-solutions.dk
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
>> Be part of this innovative community and reach millions of netbook users
>> worldwide. Take advantage of special opportunities to increase revenue and
>> speed time-to-market. Join now, and jumpstart your future.
>> http://p.sf.net/sfu/intel-atom-d2d
>> _______________________________________________
>> gumstix-users mailing list
>> gumstix-users@...
>> https://lists.sourceforge.net/lists/listinfo/gumstix-users
>
>
> ------------------------------------------------------------------------------
> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
> Be part of this innovative community and reach millions of netbook users
> worldwide. Take advantage of special opportunities to increase revenue and
> speed time-to-market. Join now, and jumpstart your future.
> http://p.sf.net/sfu/intel-atom-d2d
> _______________________________________________
> gumstix-users mailing list
> gumstix-users@...
> https://lists.sourceforge.net/lists/listinfo/gumstix-users
>
>

The DSP speed can be set via registers:
http://e2e.ti.com/support/dsp/omap_applications_processors/f/447/p/62658/225772.aspx#225772

I don't have a simple answer yet, but the pointed me to:

> spruf98h.pdf - Processor Clock Control - page 414 - section 4.12.6.1.4


I think the more useful info starts here:
page 429 - Table 4-98 - CM_CLKSEL1_PLL_IVA2

Also on page 352:

> Before any transition to OPP1 or OPP2, set the DPLL2 bypass clock to
> CORE_CLK/4 in the CM_CLKSEL1_PLL_IVA2[20:19] IVA2_CLK_SRC bit field. During
> relock phase, the DSP clock is 83 MHz. This has no effect on performance
> because DPLL2 relock time is only a few μs.


If I get around to figuring out how to actually set it in normal people
terms I'll post again.

AJ ONeal

On Sun, Aug 29, 2010 at 3:26 PM, J. L. <vwyodapink@...> wrote:

> So is that speed (DSP) not settable then? Just curious, I am trying to
> write down as much info as I can so when I get to needing that I have
> the info jotted down.
>
>
>
> On Sat, Aug 28, 2010 at 3:33 PM, AJ ONeal <coolaj86@...> wrote:
> > What about the DSP? How can that speed be set?
> > Thanks
> > AJ ONeal
> >
> >
> > On Fri, Aug 27, 2010 at 2:52 PM, Søren Steen Christensen
> > <lists@...> wrote:
> >>
> >> Just add "mpurate=720" to your bootargs variable...
> >>
> >> Alternatively you can use the cpufreq tools in Linux
> >>  Søren
> >>
> >> ---
> >> SSC Solutions ApS - Denmark - http://www.ssc-solutions.dk
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
> >> Be part of this innovative community and reach millions of netbook users
> >> worldwide. Take advantage of special opportunities to increase revenue
> and
> >> speed time-to-market. Join now, and jumpstart your future.
> >> http://p.sf.net/sfu/intel-atom-d2d
> >> _______________________________________________
> >> gumstix-users mailing list
> >> gumstix-users@...
> >> https://lists.sourceforge.net/lists/listinfo/gumstix-users
> >
> >
> >
> ------------------------------------------------------------------------------
> > Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
> > Be part of this innovative community and reach millions of netbook users
> > worldwide. Take advantage of special opportunities to increase revenue
> and
> > speed time-to-market. Join now, and jumpstart your future.
> > http://p.sf.net/sfu/intel-atom-d2d
> > _______________________________________________
> > gumstix-users mailing list
> > gumstix-users@...
> > https://lists.sourceforge.net/lists/listinfo/gumstix-users
> >
> >
>
>
> ------------------------------------------------------------------------------
> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
> Be part of this innovative community and reach millions of netbook users
> worldwide. Take advantage of special opportunities to increase revenue and
> speed time-to-market. Join now, and jumpstart your future.
> http://p.sf.net/sfu/intel-atom-d2d
> _______________________________________________
> gumstix-users mailing list
> gumstix-users@...
> https://lists.sourceforge.net/lists/listinfo/gumstix-users
>

I have now checked at TI E2E, and TI said/confirmed (as I expected), that
it’s the voltage more than the frequency which age the chips => 600MHz and
720MHz are both considered overdrive modes for both 600- and 720-grade
silicon. Please see answer here:
https://e2e.ti.com/support/dsp/omap_applications_processors/f/447/p/62063/22
3487.aspx#223487 



The highest totally safe operating freq (100K POH) is therefore 500MHz
regardless of chip-grade. Increasing to 600MHz or 720MHz will statistically
shorten the chip lifetime (and increase the power consumption), so I
recommend keeping default at 500MHz, but it might be an idea to introduce a
dummy mpurate variable set to 500 in U-boot for users to easily figure out
what to change in order to increase the speed to i.e. 600MHz or 720 MHz
should the need/want. 

 

The above being said. The complete idea with OMAP is to run at as low a
frequency as possible when not needing the processing power and just scale
to something higher on the fly when needed. In the longer run I therefore
think it’s best to just let Linux idle-thread/frequency-governor handle the
CPU scaling (with a user defined max-setting). There is already some support
for this, but to be honest I haven’t checked it for a long time…

 

Best regards and thanks – I hope this clarified the topic?

  Søren

 

---

SSC Solutions ApS - Denmark -  <http://www.ssc-solutions.dk/>
 http://www.ssc-solutions.dk

Hi AJ ONeal,

> If I get around to figuring out how to actually set it in normal people terms I'll post again. 

I think the short answer is just to set the ARM cpu rate using mpurate as discussed, since this will as well scale the DSP speed. In case you need to scale ARM and DSP individually I’m 99.9% sure this as well can be done by modifying the registers directly, but then you don’t run an any prequalified OPP point any longer and you might be a bit more on your own with respect to selecting the right operating voltage for the given configuration :-)

Please as well take a look at: https://e2e.ti.com/support/dsp/omap_applications_processors/f/447/p/62138/223140.aspx#223140 

Best regards and thanks
  Søren

---
SSC Solutions ApS - Denmark - http://www.ssc-solutions.dk

On Sun, Sep 5, 2010 at 4:25 AM, Søren Steen Christensen
<lists@...> wrote:
> I have now checked at TI E2E, and TI said/confirmed (as I expected), that
> it’s the voltage more than the frequency which age the chips => 600MHz and
> 720MHz are both considered overdrive modes for both 600- and 720-grade
> silicon. Please see answer here:
> https://e2e.ti.com/support/dsp/omap_applications_processors/f/447/p/62063/223487.aspx#223487
>
> The highest totally safe operating freq (100K POH) is therefore 500MHz
> regardless of chip-grade. Increasing to 600MHz or 720MHz will statistically
> shorten the chip lifetime (and increase the power consumption), so I
> recommend keeping default at 500MHz, but it might be an idea to introduce a
> dummy mpurate variable set to 500 in U-boot for users to easily figure out
> what to change in order to increase the speed to i.e. 600MHz or 720 MHz
> should the need/want.

This is in fact the approach that I chose.  The mpurate variable in
the default u-boot environment (set to 500) has been there for quite
some time.

Steve

Hi Steve,

> This is in fact the approach that I chose.  The mpurate variable in
> the default u-boot environment (set to 500) has been there for quite
> some time.

Cool - Have a admit that it has been a while since I last time did a pull
from you u-boot git tree - Great news :-)
  Søren

---
SSC Solutions ApS - Denmark - http://www.ssc-solutions.dk

On Sun, Sep 5, 2010 at 7:11 AM, Søren Steen Christensen
<lists@...> wrote:
> Hi Steve,
>
>> This is in fact the approach that I chose.  The mpurate variable in
>> the default u-boot environment (set to 500) has been there for quite
>> some time.
>
> Cool - Have a admit that it has been a while since I last time did a pull
> from you u-boot git tree - Great news :-)

Yes, it probably has been a lot longer than you think!  That commit
was made last February!

http://www.sakoman.com/cgi-bin/gitweb.cgi?p=u-boot.git;a=commit;h=3a764ac373b5d950a51c26db8d20dfc0f4533d25

Steve

Hello,

And is it possible change the CPU speed after the uboot has been loaded?
I want to boot the overo at maximum speed (mpurate of uboot set to 500 or 
600), but when all drivers and configuration files have been loaded, reduce 
the cpu speed (to 300 or 400 for example).

Víctor Andrés

----- Original Message ----- 
From: "Steve Sakoman" <sakoman@...>
To: "General mailing list for gumstix users." 
<gumstix-users@...>
Sent: Sunday, September 05, 2010 4:26 PM
Subject: Re: [Gumstix-users] Overo Fire CPU speed


On Sun, Sep 5, 2010 at 7:11 AM, Søren Steen Christensen
<lists@...> wrote:
> Hi Steve,
>
>> This is in fact the approach that I chose. The mpurate variable in
>> the default u-boot environment (set to 500) has been there for quite
>> some time.
>
> Cool - Have a admit that it has been a while since I last time did a pull
> from you u-boot git tree - Great news :-)

Yes, it probably has been a lot longer than you think!  That commit
was made last February!

http://www.sakoman.com/cgi-bin/gitweb.cgi?p=u-boot.git;a=commit;h=3a764ac373b5d950a51c26db8d20dfc0f4533d25

Steve

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
gumstix-users mailing list
gumstix-users@...
https://lists.sourceforge.net/lists/listinfo/gumstix-users

I assume you're doing this to speed the boot process? I would imagine that the boot process is more IO bound than CPU bound, but that's just a pure guess, I haven't profiled it or anything like that.

Kai

On 15/09/2010, at 9:39 PM, Victor Andres wrote:

> Hello,
> 
> And is it possible change the CPU speed after the uboot has been loaded?
> I want to boot the overo at maximum speed (mpurate of uboot set to 500 or 
> 600), but when all drivers and configuration files have been loaded, reduce 
> the cpu speed (to 300 or 400 for example).
> 
> Víctor Andrés
> 
> ----- Original Message ----- 
> From: "Steve Sakoman" <sakoman@...>
> To: "General mailing list for gumstix users." 
> <gumstix-users@...>
> Sent: Sunday, September 05, 2010 4:26 PM
> Subject: Re: [Gumstix-users] Overo Fire CPU speed
> 
> 
> On Sun, Sep 5, 2010 at 7:11 AM, Søren Steen Christensen
> <lists@...> wrote:
>> Hi Steve,
>> 
>>> This is in fact the approach that I chose. The mpurate variable in
>>> the default u-boot environment (set to 500) has been there for quite
>>> some time.
>> 
>> Cool - Have a admit that it has been a while since I last time did a pull
>> from you u-boot git tree - Great news :-)
> 
> Yes, it probably has been a lot longer than you think!  That commit
> was made last February!
> 
> http://www.sakoman.com/cgi-bin/gitweb.cgi?p=u-boot.git;a=commit;h=3a764ac373b5d950a51c26db8d20dfc0f4533d25
> 
> Steve
> 
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
> 
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> gumstix-users mailing list
> gumstix-users@...
> https://lists.sourceforge.net/lists/listinfo/gumstix-users 
> 
> 
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> gumstix-users mailing list
> gumstix-users@...
> https://lists.sourceforge.net/lists/listinfo/gumstix-users

> And is it possible change the CPU speed after the uboot has been loaded?

I'm also interested in that!

A quick search has revealed this:
 - 
http://elinux.org/OMAP_Power_Management#DVFS:_Dynamic_Voltage_and_Frequency_Scaling
   there, the overo is also listed as "supported platform". definitely worth 
a try. please report back if it has worked.

# cpufreq-set -f 550000


 - 
http://processors.wiki.ti.com/index.php/UserGuidePowerMgmt_PSP_03.00.00.05
   ..this is for becoming a contributor to the above links "pm" ;-)
   ..or if we have to compile the pm feature into the kernel.

have a nice day,
Daniel.

I think I need to use the DVFS and the cpufreq utils.
In my recipes/linux folder I have seen a linux-omap-pm_2.6.29.bb. I have 
done a bitbake linux-omap-pm and it has been generated 
module-2.6.29-r88-pm-....-overo.tgz
Do I have to compile a 2.6.29 omap3-console-image, untar the 
omap3-console-image-overo.tar.bz2 file, unzip the module file on it 
(replacing the files), generate the image again and reflash the Overo?
I don't know how to use this module- file.

Thanks, I will be reporting my progress.

Víctor Andres

----- Original Message ----- 
From: "Daniel Haas" <daniel.haas@...>
To: "Victor Andres" <victor@...>; "General mailing list for 
gumstix users." <gumstix-users@...>
Sent: Wednesday, September 15, 2010 2:25 PM
Subject: Re: [Gumstix-users] Overo Fire CPU speed


>> And is it possible change the CPU speed after the uboot has been loaded?
>
> I'm also interested in that!
>
> A quick search has revealed this:
> - 
> http://elinux.org/OMAP_Power_Management#DVFS:_Dynamic_Voltage_and_Frequency_Scaling
>   there, the overo is also listed as "supported platform". definitely 
> worth a try. please report back if it has worked.
>
> # cpufreq-set -f 550000
>
>
> - 
> http://processors.wiki.ti.com/index.php/UserGuidePowerMgmt_PSP_03.00.00.05
>   ..this is for becoming a contributor to the above links "pm" ;-)
>   ..or if we have to compile the pm feature into the kernel.
>
> have a nice day,
> Daniel.