From: J. L. <vwy...@gm...> - 2010-08-27 19:48:55
|
I thought the overo fire was suppose to have 700mhz? doing a cat /proc/cpuinfo shows me having a BogoMIPS of 499.92? I have changed nothing relating to this why does mine show its running at 500mHz? Is there a way to clock it to the 700? or ? Kinda lost on the info on this one. The only reason I came across this was because I was trying to find out what was eating my memory and decided to see what that would give me. Thanks for any info on this one. |
From: Søren S. C. <li...@ss...> - 2010-08-27 20:06:52
|
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 - www.ssc-solutions.dk |
From: J. L. <vwy...@gm...> - 2010-08-27 20:20:10
|
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 <li...@ss...> 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 - 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 > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Søren S. C. <li...@ss...> - 2010-08-27 20:43:41
|
> 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 - www.ssc-solutions.dk |
From: Søren S. C. <li...@ss...> - 2010-08-27 20:21:06
|
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 - www.ssc-solutions.dk |
From: Steve S. <sa...@gm...> - 2010-08-28 03:13:00
|
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 <li...@ss...> 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 - 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 > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Kai H. [Automatica] <ka...@au...> - 2010-08-28 04:05:34
Attachments:
smime.p7s
|
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 > <li...@ss...> 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 - 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 >> gum...@li... >> 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 > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Søren S. C. <li...@ss...> - 2010-08-28 08:10:20
|
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 - www.ssc-solutions.dk |
From: J. L. <vwy...@gm...> - 2010-08-28 09:00:21
|
On Sat, Aug 28, 2010 at 1:10 AM, Søren Steen Christensen <li...@ss...> 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 - 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 > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Kai H. <ka...@au...> - 2010-08-28 09:57:39
|
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... |
From: Søren S. C. <li...@ss...> - 2010-09-05 11:25:48
|
I have now checked at TI E2E, and TI said/confirmed (as I expected), that its 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 its 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 havent 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/> www.ssc-solutions.dk |
From: Kai H. [Automatica] <ka...@au...> - 2010-09-05 11:46:26
Attachments:
smime.p7s
|
I think that is a good idea to have a default u-boot variable for CPU frequency of 500MHz, so that it's a lot easier for a user to find what needs to be changed to bump the frequency if they desire. Cheers, Kai On 05/09/2010, at 9:25 PM, Søren Steen Christensen 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. > > 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 - www.ssc-solutions.dk > ------------------------------------------------------------------------------ > 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 > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Steve S. <sa...@gm...> - 2010-09-05 13:31:37
|
On Sun, Sep 5, 2010 at 4:25 AM, Søren Steen Christensen <li...@ss...> 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 |
From: Søren S. C. <li...@ss...> - 2010-09-05 14:12:00
|
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 - www.ssc-solutions.dk |
From: Steve S. <sa...@gm...> - 2010-09-05 14:26:50
|
On Sun, Sep 5, 2010 at 7:11 AM, Søren Steen Christensen <li...@ss...> 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 |
From: Victor A. <vi...@cy...> - 2010-09-15 11:39:56
|
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" <sa...@gm...> To: "General mailing list for gumstix users." <gum...@li...> 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 <li...@ss...> 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 gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Kai H. <ka...@au...> - 2010-09-15 11:48:47
|
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" <sa...@gm...> > To: "General mailing list for gumstix users." > <gum...@li...> > 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 > <li...@ss...> 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 > gum...@li... > 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 > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Daniel H. <dan...@ni...> - 2010-09-15 12:26:18
|
> 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. |
From: Victor A. <vi...@cy...> - 2010-09-21 17:01:11
|
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" <dan...@ni...> To: "Victor Andres" <vi...@cy...>; "General mailing list for gumstix users." <gum...@li...> 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. |
From: AJ O. <coo...@gm...> - 2010-08-27 20:45:36
|
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 |
From: Søren S. C. <li...@ss...> - 2010-08-27 20:52:39
|
Just add "mpurate=720" to your bootargs variable... Alternatively you can use the cpufreq tools in Linux Søren --- SSC Solutions ApS - Denmark - www.ssc-solutions.dk |
From: J. L. <vwy...@gm...> - 2010-08-27 20:59:15
|
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 <li...@ss...> wrote: > Just add "mpurate=720" to your bootargs variable... > > Alternatively you can use the cpufreq tools in Linux > Søren > > --- > SSC Solutions ApS - Denmark - 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 > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Søren S. C. <li...@ss...> - 2010-08-27 21:11:44
|
> 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 - www.ssc-solutions.dk |
From: AJ O. <coo...@gm...> - 2010-08-28 22:34:27
|
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 < li...@ss...> wrote: > Just add "mpurate=720" to your bootargs variable... > > Alternatively you can use the cpufreq tools in Linux > Søren > > --- > SSC Solutions ApS - Denmark - 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 > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: J. L. <vwy...@gm...> - 2010-08-29 21:27:04
|
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 <coo...@gm...> 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 > <li...@ss...> wrote: >> >> Just add "mpurate=720" to your bootargs variable... >> >> Alternatively you can use the cpufreq tools in Linux >> Søren >> >> --- >> SSC Solutions ApS - Denmark - 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 >> gum...@li... >> 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 > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > |