cpufreq on the Overo

[ravix]

Has anyone gotten this working? I've recompiled my kernel to enable all of the modules involving cpufreq and I can't seem to get any result. My dmesg has nothing about CPU frequency and the only file in /sys/devices/system/cpu/cpu0 is a crash log.

I've also tried loading the CPU_frequency kernel options as modules, which has no effect.

Is this is limitation with the kernel support of the processor?

[Philip Balister]

ravix wrote:
> Has anyone gotten this working? I've recompiled my kernel to enable all of
> the modules involving cpufreq and I can't seem to get any result. My dmesg
> has nothing about CPU frequency and the only file in
> /sys/devices/system/cpu/cpu0 is a crash log.
>
> I've also tried loading the CPU_frequency kernel options as modules, which
> has no effect.
>
> Is this is limitation with the kernel support of the processor?

I think the low-level support for cpufreq is only in the linux-omap-pm
branch. I've run this on the beagle, but the stock overo kernel will
support more things.

There is a linux-omap-pm recipe that could be made to work for the overo
I think.

Philip

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users

[ravix]

Philip Balister wrote

ravix wrote:
I think the low-level support for cpufreq is only in the linux-omap-pm
branch. I've run this on the beagle, but the stock overo kernel will
support more things.

There is a linux-omap-pm recipe that could be made to work for the overo
I think.

Would you mind providing more information about how to use the linux-omap-pm branch with the Overo? I've been trying without any success.

First I copied overo.conf from
org.openembedded.dev/conf/machine to
user.collection/conf/machine/

I then changed the line in overo.conf from
PREFERRED_PROVIDER_virtual/kernel = "linux-omap3" to
PREFERRED_PROVIDER_virtual/kernel = "linux-omap-pm"

then I copied all the contents of
org.openembedded.dev/packages/linux/linux-omap-pm/ to
user.collection/packages/linux/linux-omap-pm/

I am not sure about this next step, but linux-omap-pm did not have an overo directory inside, so I added it from the linux-omap3 directory by copying to contents of
org.openembedded.dev/packages/linux/linux-omap3/overo/ to
user.collection/packages/linux/linux-omap-pm/overo/

Now when I try to bitbake my image, which is a slightly modified version of console-base-image.bb called "sonar-base.bb" I see the following:

"NOTE: multiple providers are available for virtual/kernel (at91, linux, linux-omap3, linux-bast, linux-rt, linux-omap-2.6, gumstix-kernel);
NOTE: consider defining PREFERRED_PROVIDER_virtual/kernel"

Note that linux-omap-pm is not on the list.

Also, when I try to run bitbake -c rebuild linux-omap-pm I get:
"ERROR: Nothing PROVIDES 'linux-omap-pm'"

I also tried coping some of the patches from the linux-omap-pm recipe to the linux-omap3 recipe to see if I could enable the cpufreq features. Unfortunately these all failed to build.

Does anyone know what specifically is preventing the linux-omap3 build from using the cpufreq features, even when they are enabled via the kernel configuration?

Thanks

-Eric

[ravix]

ravix wrote

Would you mind providing more information about how to use the linux-omap-pm branch with the Overo? I've been trying without any success.

First I copied overo.conf from
org.openembedded.dev/conf/machine to
user.collection/conf/machine/

I then changed the line in overo.conf from
PREFERRED_PROVIDER_virtual/kernel = "linux-omap3" to
PREFERRED_PROVIDER_virtual/kernel = "linux-omap-pm"

then I copied all the contents of
org.openembedded.dev/packages/linux/linux-omap-pm/ to
user.collection/packages/linux/linux-omap-pm/

I am not sure about this next step, but linux-omap-pm did not have an overo directory inside, so I added it from the linux-omap3 directory by copying to contents of
org.openembedded.dev/packages/linux/linux-omap3/overo/ to
user.collection/packages/linux/linux-omap-pm/overo/

Now when I try to bitbake my image, which is a slightly modified version of console-base-image.bb called "sonar-base.bb" I see the following:

"NOTE: multiple providers are available for virtual/kernel (at91, linux, linux-omap3, linux-bast, linux-rt, linux-omap-2.6, gumstix-kernel);
NOTE: consider defining PREFERRED_PROVIDER_virtual/kernel"

Note that linux-omap-pm is not on the list.

Also, when I try to run bitbake -c rebuild linux-omap-pm I get:
"ERROR: Nothing PROVIDES 'linux-omap-pm'"

I also tried coping some of the patches from the linux-omap-pm recipe to the linux-omap3 recipe to see if I could enable the cpufreq features. Unfortunately these all failed to build.

Does anyone know what specifically is preventing the linux-omap3 build from using the cpufreq features, even when they are enabled via the kernel configuration?

Thanks

-Eric

I could really use some help with this.. any ideas?

-Eric

[Robal]

ravix wrote

Philip Balister wrote

ravix wrote:
I think the low-level support for cpufreq is only in the linux-omap-pm
branch. I've run this on the beagle, but the stock overo kernel will
support more things.

There is a linux-omap-pm recipe that could be made to work for the overo
I think.

Also, when I try to run bitbake -c rebuild linux-omap-pm I get:
"ERROR: Nothing PROVIDES 'linux-omap-pm'"

Thanks

-Eric

Hi,

I've copied only "oe/recipes/images/omap3-console-image.bb"   to  "user.collection/recipes/images/my-image.bb"
Then I've added a line to the bottom of the file:
PREFERRED_VERSION_linux-omap = "pm_2.6.29"

Then:
bitbake my-image

In your local.conf...  make sure, you've got BBFILES pointing to both oe recipes and user.collection recipes.
Also check your /oe/recipes/linux/...
Do you have linux-omap-pm* folders there ?

I baked the imaged OK, but I'm still having problems booting it properly...   It gets stuck at "Starting bluetooth..."

Cheers,
  Robert