From: Thorsten B. <tho...@go...> - 2010-10-02 20:36:11
|
How can I set up the frequency of the ARM-Core of the OMAP3 on the Gumstix ? - Can it be done in the bootloader ? How low can it be set ? -- View this message in context: http://old.nabble.com/ARM-Core-CPU-Freuqency-tp29868055p29868055.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Søren S. C. <li...@ss...> - 2010-10-02 21:31:30
|
Hi Thorsten, > - Can it be done in the bootloader ? How low can it be set ? You can set the variable mpurate in u-boot. In theory you can set it all the way down to 0MHz. In practice 125MHz I the lowest officially supported operation frequency... Best regards - Good luck Søren --- SSC Solutions ApS - Denmark - www.ssc-solutions.dk |
From: Thorsten B. <tho...@go...> - 2010-10-02 21:42:47
|
Søren Steen Christensen wrote: > > Hi Thorsten, > >> - Can it be done in the bootloader ? How low can it be set ? > You can set the variable mpurate in u-boot. In theory you can set it all > the > way down to 0MHz. > > In practice 125MHz I the lowest officially supported operation > frequency... > > Best regards - Good luck > Søren > > --- > SSC Solutions ApS - Denmark - www.ssc-solutions.dk > > > ------------------------------------------------------------------------------ > 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 > > OK - I did in the u-boot environment at startup setenv mpurate 125; saveenv; reset; After fw-printenv I also get now : ... mpurate=125 BUT when I call : cat /proc/cpuinfo I still get 499 BogoMips So it seems that the CPU fruqency seems not to be lowered. I'm also monitoring the power consumption of the overo fire board (on a chestnut mainboard) (and would like to lower it to the "min") - and it seems that the board power consumption seems not be changed - still - without monitor and usb peripherals around 450mA at 5V. Also the boot-up time seems not to be decreased due to a lower clock speed. Like that I assume my approach for manipulating the cpu-frequency wasn't successful. Maybe there are better way to monitor this (please let me know). Anyway I hope that someone can help me to get things going in order to lower clock frequency of the device and save power. Furtheron - if there is a way to lower the cpu frequency at runtime - I would be highl interested - I read about something like "cpufreq" but couldn't find this tool (in the packages ...) -- View this message in context: http://old.nabble.com/ARM-Core-CPU-Freuqency-tp29868055p29868344.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Søren S. C. <li...@ss...> - 2010-10-02 22:18:08
|
> I'm also monitoring the power consumption of the overo fire board (on a chestnut mainboard) > (and would like to lower it to the "min") - and it seems that the board power consumption > seems not be changed - still - without monitor and usb peripherals around 450mA at 5V. And (just to be sure) you have "mpurate=${mpurate}" being part of your bootargs as well? Taking a look at: http://elinux.org/OMAP_Power_Management might help with respect to runtime management... Follow the link at the bottom in order to go to source for the cpufreq tools... AFAIR you might as well be able to get these from an OE build, although I haven't checked this for quite some time... Best regards - Good luck Søren --- SSC Solutions ApS - Denmark - www.ssc-solutions.dk |
From: Thorsten B. <tho...@go...> - 2010-10-02 22:23:24
|
>And (just to be sure) you have "mpurate=${mpurate}" being part of your bootargs as well? How do I check this ? fw_printenv delivers "... mpurate=125" isn't this sufficient ? -- View this message in context: http://old.nabble.com/ARM-Core-CPU-Freuqency-tp29868055p29868550.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: J. L. <vwy...@gm...> - 2010-10-02 22:34:15
|
On Sat, Oct 2, 2010 at 3:23 PM, Thorsten Brandt <tho...@go...> wrote: > > >>And (just to be sure) you have "mpurate=${mpurate}" being part of your > bootargs as well? > > How do I check this ? fw_printenv delivers "... mpurate=125" isn't this > sufficient ? boot up through the console port hit enter before the 5 seconds are up then: printenv - to see current environment setenv - set what you want saveenv - save your changes reset - reboots it That should set it up correctly for you > -- > View this message in context: http://old.nabble.com/ARM-Core-CPU-Freuqency-tp29868055p29868550.html > Sent from the Gumstix mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------------ > 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: Søren S. C. <li...@ss...> - 2010-10-02 22:39:43
|
> How do I check this ? In U-boot: printenv Check if line containing bootargs is similar to: bootargs=xxxxxxxxxxxxxxxxxxxxxxxx mpurate=${mpurate} xxxxxxxxxxxxxxxx In Linux: cat /proc/cmdline Check if the line contains "mpurate=125"? Best regards Søren --- SSC Solutions ApS - Denmark - www.ssc-solutions.dk |
From: Thorsten B. <tho...@go...> - 2010-10-02 22:48:53
|
Søren Steen Christensen wrote: > >> How do I check this ? > > In U-boot: > printenv > > Check if line containing bootargs is similar to: > bootargs=xxxxxxxxxxxxxxxxxxxxxxxx mpurate=${mpurate} xxxxxxxxxxxxxxxx > > In Linux: > cat /proc/cmdline > Check if the line contains "mpurate=125"? > > > > Best regards > Søren > > --- > SSC Solutions ApS - Denmark - www.ssc-solutions.dk > > > ------------------------------------------------------------------------------ > 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 > > printenv in the u-boot environment delivers : Overo # printenv bootcmd=if mmc init; then if run loadbootscript; then run bootscript; else if ru n loaduimage; then run mmcboot; else run nandboot; fi; fi; else run nandboot; fi bootdelay=5 baudrate=115200 loadaddr=0x82000000 console=ttyS2,115200n8 vram=12M dvimode=1024x768MR-16@60 mmcroot=/dev/mmcblk0p2 rw mmcrootfstype=ext3 rootwait nandroot=/dev/mtdblock4 rw nandrootfstype=jffs2 mmcargs=setenv bootargs console=${console} vram=${vram} omapfb.mode=dvi:${dvimod e} omapfb.debug=y omapdss.def_disp=${defaultdisplay} root=${mmcroot} rootfstype= ${mmcrootfstype} nandargs=setenv bootargs console=${console} vram=${vram} omapfb.mode=dvi:${dvimo de} omapfb.debug=y omapdss.def_disp=${defaultdisplay} root=${nandroot} rootfstyp e=${nandrootfstype} loadbootscript=fatload mmc 0 ${loadaddr} boot.scr bootscript=echo Running bootscript from mmc ...; source ${loadaddr} loaduimage=fatload mmc 0 ${loadaddr} uImage mmcboot=echo Booting from mmc ...; run mmcargs; bootm ${loadaddr} nandboot=echo Booting from nand ...; run nandargs; nand read ${loadaddr} 280000 400000; bootm ${loadaddr} dieid#=0096000400000000040373051001601b ethact=smc911x-0 defaultdisplay=lcd43 mpurate=125 bootargs=mpurate=125 stdin=serial stdout=serial stderr=serial Environment size: 1211/131068 bytes So here we have mpurate=125 and bootargs defined ... Hmm, and cat /proc/line delivers : root@overo:~# cat /proc/cmdline console=ttyS2,115200n8 vram=12M omapfb.mode=dvi:1024x768MR-16@60 omapfb.debug=y omapdss.def_disp=lcd43 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait So no mpurate=125 .... ... and still no success concerning power consumption ... -- View this message in context: http://old.nabble.com/ARM-Core-CPU-Freuqency-tp29868055p29868634.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Thorsten B. <tho...@go...> - 2010-10-02 22:52:51
|
Thorsten Brandt wrote: > > > > Søren Steen Christensen wrote: >> >>> How do I check this ? >> >> In U-boot: >> printenv >> >> Check if line containing bootargs is similar to: >> bootargs=xxxxxxxxxxxxxxxxxxxxxxxx mpurate=${mpurate} xxxxxxxxxxxxxxxx >> >> In Linux: >> cat /proc/cmdline >> Check if the line contains "mpurate=125"? >> >> >> >> Best regards >> Søren >> >> --- >> SSC Solutions ApS - Denmark - www.ssc-solutions.dk >> >> >> ------------------------------------------------------------------------------ >> 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 >> >> > > printenv in the u-boot environment delivers : > > Overo # printenv > bootcmd=if mmc init; then if run loadbootscript; then run bootscript; else > if ru > n loaduimage; then run mmcboot; else run nandboot; fi; fi; else run > nandboot; fi > bootdelay=5 > baudrate=115200 > loadaddr=0x82000000 > console=ttyS2,115200n8 > vram=12M > dvimode=1024x768MR-16@60 > mmcroot=/dev/mmcblk0p2 rw > mmcrootfstype=ext3 rootwait > nandroot=/dev/mtdblock4 rw > nandrootfstype=jffs2 > mmcargs=setenv bootargs console=${console} vram=${vram} > omapfb.mode=dvi:${dvimod > e} omapfb.debug=y omapdss.def_disp=${defaultdisplay} root=${mmcroot} > rootfstype= > ${mmcrootfstype} > nandargs=setenv bootargs console=${console} vram=${vram} > omapfb.mode=dvi:${dvimo > de} omapfb.debug=y omapdss.def_disp=${defaultdisplay} root=${nandroot} > rootfstyp > e=${nandrootfstype} > loadbootscript=fatload mmc 0 ${loadaddr} boot.scr > bootscript=echo Running bootscript from mmc ...; source ${loadaddr} > loaduimage=fatload mmc 0 ${loadaddr} uImage > mmcboot=echo Booting from mmc ...; run mmcargs; bootm ${loadaddr} > nandboot=echo Booting from nand ...; run nandargs; nand read ${loadaddr} > 280000 > 400000; bootm ${loadaddr} > dieid#=0096000400000000040373051001601b > ethact=smc911x-0 > defaultdisplay=lcd43 > mpurate=125 > bootargs=mpurate=125 > stdin=serial > stdout=serial > stderr=serial > > Environment size: 1211/131068 bytes > > So here we have mpurate=125 and bootargs defined ... > > Hmm, and cat /proc/line delivers : > > root@overo:~# cat /proc/cmdline > console=ttyS2,115200n8 vram=12M omapfb.mode=dvi:1024x768MR-16@60 > omapfb.debug=y > omapdss.def_disp=lcd43 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait > > > So no mpurate=125 .... > > ... and still no success concerning power consumption ... > > > Is it maybe the order of the variable definition - bootargs is defined after mmcargs= setenv bootargs ... ? (Is it possible to reorder variables ?) -- View this message in context: http://old.nabble.com/ARM-Core-CPU-Freuqency-tp29868055p29868653.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Steve S. <sa...@gm...> - 2010-10-02 23:09:29
|
On Sat, Oct 2, 2010 at 3:52 PM, Thorsten Brandt <tho...@go...> wrote: > > > > Thorsten Brandt wrote: >> >> >> >> Søren Steen Christensen wrote: >>> >>>> How do I check this ? >>> >>> In U-boot: >>> printenv >>> >>> Check if line containing bootargs is similar to: >>> bootargs=xxxxxxxxxxxxxxxxxxxxxxxx mpurate=${mpurate} xxxxxxxxxxxxxxxx >>> >>> In Linux: >>> cat /proc/cmdline >>> Check if the line contains "mpurate=125"? >>> >>> >>> >>> Best regards >>> Søren >>> >>> --- >>> SSC Solutions ApS - Denmark - www.ssc-solutions.dk >>> >>> >>> ------------------------------------------------------------------------------ >>> 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 >>> >>> >> >> printenv in the u-boot environment delivers : >> >> Overo # printenv >> bootcmd=if mmc init; then if run loadbootscript; then run bootscript; else >> if ru >> n loaduimage; then run mmcboot; else run nandboot; fi; fi; else run >> nandboot; fi >> bootdelay=5 >> baudrate=115200 >> loadaddr=0x82000000 >> console=ttyS2,115200n8 >> vram=12M >> dvimode=1024x768MR-16@60 >> mmcroot=/dev/mmcblk0p2 rw >> mmcrootfstype=ext3 rootwait >> nandroot=/dev/mtdblock4 rw >> nandrootfstype=jffs2 >> mmcargs=setenv bootargs console=${console} vram=${vram} >> omapfb.mode=dvi:${dvimod >> e} omapfb.debug=y omapdss.def_disp=${defaultdisplay} root=${mmcroot} >> rootfstype= >> ${mmcrootfstype} >> nandargs=setenv bootargs console=${console} vram=${vram} >> omapfb.mode=dvi:${dvimo >> de} omapfb.debug=y omapdss.def_disp=${defaultdisplay} root=${nandroot} >> rootfstyp >> e=${nandrootfstype} >> loadbootscript=fatload mmc 0 ${loadaddr} boot.scr >> bootscript=echo Running bootscript from mmc ...; source ${loadaddr} >> loaduimage=fatload mmc 0 ${loadaddr} uImage >> mmcboot=echo Booting from mmc ...; run mmcargs; bootm ${loadaddr} >> nandboot=echo Booting from nand ...; run nandargs; nand read ${loadaddr} >> 280000 >> 400000; bootm ${loadaddr} >> dieid#=0096000400000000040373051001601b >> ethact=smc911x-0 >> defaultdisplay=lcd43 >> mpurate=125 >> bootargs=mpurate=125 >> stdin=serial >> stdout=serial >> stderr=serial >> >> Environment size: 1211/131068 bytes >> >> So here we have mpurate=125 and bootargs defined ... >> >> Hmm, and cat /proc/line delivers : >> >> root@overo:~# cat /proc/cmdline >> console=ttyS2,115200n8 vram=12M omapfb.mode=dvi:1024x768MR-16@60 >> omapfb.debug=y >> omapdss.def_disp=lcd43 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait >> >> >> So no mpurate=125 .... >> >> ... and still no success concerning power consumption ... >> >> >> > > Is it maybe the order of the variable definition - bootargs is defined after > mmcargs= setenv bootargs ... ? > > (Is it possible to reorder variables ?) No that isn't the issue. My guess is either that your u-boot version is pre introduction of the mpurate feature, or you still have an old environment in nand. Start by checking your u-boot revision, if it is an old build update to something more recent. Be sure to also erase your nand environment so that u-boot uses an appropriate default. From the u-boot prompt: nand erase 240000 20000 reset After the reboot do a printenv and make sure that the mpurate setup is present in the default environment. Steve |
From: Thorsten B. <tho...@go...> - 2010-10-02 23:24:43
|
nand erase 240000 20000 reset O.K., guys - thank you very much for the support - the nand erase - and the whole setup once again did the "trick" now : I have : root@overo:~# cat /proc/cmdline console=ttyS2,115200n8 mpurate=125 vram=12M omapfb.mode=dvi:1024x768MR-16@60 oma pfb.debug=y omapdss.def_disp=dvi root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait and root@overo:~# cat /proc/cpuinfo Processor : ARMv7 Processor rev 3 (v7l) BogoMIPS : 124.45 Features : swp half thumb fastmult vfp edsp thumbee neon vfpv3 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x1 CPU part : 0xc08 CPU revision : 3 Hardware : Gumstix Overo Revision : 0020 Serial : 0000000000000000 Now the whole system is also booting muc slower - at least this is fine ... from a standpoint of powerconservation I have to state that this did not as much as I expected - I have now around 400mA for the whole board - still some way to go so - but for this time again : thank you very much for the suppport ! -- View this message in context: http://old.nabble.com/ARM-Core-CPU-Freuqency-tp29868055p29868799.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Thorsten B. <tho...@go...> - 2010-10-02 23:13:33
|
OMAP3530-GP ES3.1 Board revision: 0 Reading boot sector Loading u-boot.bin from mmc U-Boot 2010.09-rc2 (Sep 23 2010 - 16:14:43) OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 720 mHz Gumstix Overo board + LPDDR/NAND I2C: ready DRAM: 256 MiB NAND: 256 MiB In: serial Out: serial Err: serial Board revision: 0 Tranceiver detected on mmc2 Die ID #0096000400000000040373051001601b Net: smc911x-0 Hit any key to stop autoboot: 0 Overo # sakoman wrote: > > On Sat, Oct 2, 2010 at 3:52 PM, Thorsten Brandt > <tho...@go...> wrote: >> >> >> >> Thorsten Brandt wrote: >>> >>> >>> >>> Søren Steen Christensen wrote: >>>> >>>>> How do I check this ? >>>> >>>> In U-boot: >>>> printenv >>>> >>>> Check if line containing bootargs is similar to: >>>> bootargs=xxxxxxxxxxxxxxxxxxxxxxxx mpurate=${mpurate} xxxxxxxxxxxxxxxx >>>> >>>> In Linux: >>>> cat /proc/cmdline >>>> Check if the line contains "mpurate=125"? >>>> >>>> >>>> >>>> Best regards >>>> Søren >>>> >>>> --- >>>> SSC Solutions ApS - Denmark - www.ssc-solutions.dk >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> 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 >>>> >>>> >>> >>> printenv in the u-boot environment delivers : >>> >>> Overo # printenv >>> bootcmd=if mmc init; then if run loadbootscript; then run bootscript; >>> else >>> if ru >>> n loaduimage; then run mmcboot; else run nandboot; fi; fi; else run >>> nandboot; fi >>> bootdelay=5 >>> baudrate=115200 >>> loadaddr=0x82000000 >>> console=ttyS2,115200n8 >>> vram=12M >>> dvimode=1024x768MR-16@60 >>> mmcroot=/dev/mmcblk0p2 rw >>> mmcrootfstype=ext3 rootwait >>> nandroot=/dev/mtdblock4 rw >>> nandrootfstype=jffs2 >>> mmcargs=setenv bootargs console=${console} vram=${vram} >>> omapfb.mode=dvi:${dvimod >>> e} omapfb.debug=y omapdss.def_disp=${defaultdisplay} root=${mmcroot} >>> rootfstype= >>> ${mmcrootfstype} >>> nandargs=setenv bootargs console=${console} vram=${vram} >>> omapfb.mode=dvi:${dvimo >>> de} omapfb.debug=y omapdss.def_disp=${defaultdisplay} root=${nandroot} >>> rootfstyp >>> e=${nandrootfstype} >>> loadbootscript=fatload mmc 0 ${loadaddr} boot.scr >>> bootscript=echo Running bootscript from mmc ...; source ${loadaddr} >>> loaduimage=fatload mmc 0 ${loadaddr} uImage >>> mmcboot=echo Booting from mmc ...; run mmcargs; bootm ${loadaddr} >>> nandboot=echo Booting from nand ...; run nandargs; nand read ${loadaddr} >>> 280000 >>> 400000; bootm ${loadaddr} >>> dieid#=0096000400000000040373051001601b >>> ethact=smc911x-0 >>> defaultdisplay=lcd43 >>> mpurate=125 >>> bootargs=mpurate=125 >>> stdin=serial >>> stdout=serial >>> stderr=serial >>> >>> Environment size: 1211/131068 bytes >>> >>> So here we have mpurate=125 and bootargs defined ... >>> >>> Hmm, and cat /proc/line delivers : >>> >>> root@overo:~# cat /proc/cmdline >>> console=ttyS2,115200n8 vram=12M omapfb.mode=dvi:1024x768MR-16@60 >>> omapfb.debug=y >>> omapdss.def_disp=lcd43 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait >>> >>> >>> So no mpurate=125 .... >>> >>> ... and still no success concerning power consumption ... >>> >>> >>> >> >> Is it maybe the order of the variable definition - bootargs is defined >> after >> mmcargs= setenv bootargs ... ? >> >> (Is it possible to reorder variables ?) > > No that isn't the issue. My guess is either that your u-boot version > is pre introduction of the mpurate feature, or you still have an old > environment in nand. > > Start by checking your u-boot revision, if it is an old build update > to something more recent. > > Be sure to also erase your nand environment so that u-boot uses an > appropriate default. From the u-boot prompt: > > nand erase 240000 20000 > reset > > After the reboot do a printenv and make sure that the mpurate setup is > present in the default environment. > > Steve > > ------------------------------------------------------------------------------ > 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 > > -- View this message in context: http://old.nabble.com/ARM-Core-CPU-Freuqency-tp29868055p29868743.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Thorsten B. <tho...@go...> - 2010-10-02 23:31:42
|
Just a short addon question : Is it possible to power off the WLAN/Bluetooth module on the Overo Fire totaly (by software / by the bootloader) if it is not needed (at all) ? -- View this message in context: http://old.nabble.com/ARM-Core-CPU-Freuqency-tp29868055p29868830.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Steve S. <sa...@gm...> - 2010-10-02 23:39:31
|
On Sat, Oct 2, 2010 at 4:31 PM, Thorsten Brandt <tho...@go...> wrote: > > Just a short addon question : > > Is it possible to power off the WLAN/Bluetooth module on the Overo Fire > totaly (by software / by the bootloader) if it is not needed (at all) ? If you don't need the wifi/bt module then obviously the best choice power-wise (not to mention cost!) is to buy a version of the module that doesn't include this hardware. Otherwise you can pull on the reset gpio's for the module -- see the kernel board file for which gpio's are used. I think someone gave a command line method to hold the module in reset -- search for the recent power measurement thread on this list. Steve |
From: Thorsten B. <tho...@go...> - 2010-10-02 23:47:41
|
Just for your convenience : We have a subsea application here. As you might know water is a polar medium - so you will have a hard time to use wlan even for short distance communication under water - but (!) when the subsea module is coming up - to sealevel (for example near a mother ship) then it' quite nice to have a wan conection to the module - as it is fast and rugged. As power is an issue for the subsea phase - as everything is powered on battery - it's not much an issue when the module comes up - and can recharge on the surface. That's the reason, why I choose the overo fire and would be interested in switching of the WLAN module. I think similar thinking applies to several other data logging applications where devices come back to a "host" in order to get rid of collected data in a fast and rugged manner - wireless ... Just as an explanation ... Thank you very much for the further advice you gave me ... sakoman wrote: > > On Sat, Oct 2, 2010 at 4:31 PM, Thorsten Brandt > <tho...@go...> wrote: >> >> Just a short addon question : >> >> Is it possible to power off the WLAN/Bluetooth module on the Overo Fire >> totaly (by software / by the bootloader) if it is not needed (at all) ? > > If you don't need the wifi/bt module then obviously the best choice > power-wise (not to mention cost!) is to buy a version of the module > that doesn't include this hardware. > > Otherwise you can pull on the reset gpio's for the module -- see the > kernel board file for which gpio's are used. > > I think someone gave a command line method to hold the module in reset > -- search for the recent power measurement thread on this list. > > Steve > > ------------------------------------------------------------------------------ > 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 > > -- View this message in context: http://old.nabble.com/ARM-Core-CPU-Freuqency-tp29868055p29868877.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Søren S. C. <li...@ss...> - 2010-10-03 09:13:01
|
Hi Thorsten, For further information about bringing down the power consumption please have a look at the following thread http://sourceforge.net/mailarchive/forum.php?thread_name=000001cb5bc0%24efaa 6080%240101a8c0%40EointecVideo&forum_name=gumstix-users as well... Best regards - Good luck Søren --- SSC Solutions ApS - Denmark - www.ssc-solutions.dk |
From: Victor A. <vi...@cy...> - 2010-10-05 08:46:49
|
You can do that in the U-boot with the mpurate variable. In this way you can set the freuqency before you start the overo and you can't change it. In the other side, you can use linux-omap-pm kernel, that will let you change it after the linux has been started. More information: http://elinux.org/OMAP_Power_Management ----- Original Message ----- From: "Thorsten Brandt" <tho...@go...> To: <gum...@li...> Sent: Saturday, October 02, 2010 10:36 PM Subject: [Gumstix-users] ARM-Core CPU Freuqency > > How can I set up the frequency of the ARM-Core of the OMAP3 on the Gumstix > ? > - Can it be done in the bootloader ? > > How low can it be set ? > -- > View this message in context: > http://old.nabble.com/ARM-Core-CPU-Freuqency-tp29868055p29868055.html > Sent from the Gumstix mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------------ > 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: Steve S. <sa...@gm...> - 2010-10-05 14:27:43
|
On Tue, Oct 5, 2010 at 1:46 AM, Victor Andres <vi...@cy...> wrote: > In the other side, you can use linux-omap-pm kernel, that will let you > change it after the linux has been started. I've seen other folks on the list who recommend using the pm branch of linux-omap too. If it works for you, that it great! But please bear in mind this quote from Kevin Hilman (maintainer of the PM branch) on the linux-omap list yesterday: "What do you need from the PM branch that is not in l-o master? The PM branch is *experimental*, and is under significant change while parts that are not yet ready for mainline are being reworked and in some cases completely re-written. IOW, the PM branch is unstable and should not be trusted. (I can say that, I am the maintainer.) ;) " Regards, Steve |