2007-11-14 17:38:44     make error with cpu frequency scaling

Document created by Aaronwu Employee on Aug 6, 2013
Version 1Show Document
  • View in full screen mode

2007-11-14 17:38:44     make error with cpu frequency scaling

chris jones (UNITED STATES)

Message: 46844    I'm trying to include CPU frequency scaling in the my kernel.

I'm using uClinux-dist.R1.1-RC3 with the blackfin-toolchain-07r1.1-3.i386 for the CM-BF537E and the Stamp.

I get the following linker error upon make.

...

LD      .tmp_vmlinux1

/opt/uClinux/bfin-uclinux/bin/bfin-uclinux-ld.real: error: no memory region specified forloadable section `.initcall0.init'

make[1]: *** [.tmp_vmlinux1] Error 1

make[1]: Leaving directory `/home/cjones/bfin/kernel/uClinux-dist.R1.1-RC3/linux-2.6.x'

make: *** [linux] Error 1

...

Any suggestions?

I can't find much about frequency scaling on the forum.

Is it implemented yet?

Thanks

QuoteReplyEditDelete

 

 

2007-11-14 17:49:35     Re: make error with cpu frequency scaling

Mike Frysinger (UNITED STATES)

Message: 46846    cpufreq support does not currently work

QuoteReplyEditDelete

 

 

2008-03-27 17:30:28     Re: make error with cpu frequency scaling

Jonathan Kotta (UNITED STATES)

Message: 53179    I'm trying to get cpufreq to work on bf548-ezkit.  The end goal I have is to get frequency and voltage scaling working together.  So far, I have frequency scaling working, via the PLL_DIV, and sometimes voltage scaling works.  I am not doing the full general case as in the bfin_dpmc driver, because for me it is enough to just change the divider.  My problem is that when I update the VR_CTL register at all (even when not changing the value), the processor locks up for some frequency transitions.  I can switch between 525 and 262 MHz all I want, but I can't switch to 131 or 66 MHz if I touch the VR_CTL register at all.  Based on what the manual says, bfin_write_VR_CTL() is doing the right thing (it is initiating a "PLL programming sequence").  Any ideas?

cpufreq.patch

QuoteReplyEditDelete

 

 

2008-03-27 17:41:57     Re: make error with cpu frequency scaling

Mike Frysinger (UNITED STATES)

Message: 53183    i wonder if the irq locking in bfin_write_VR_CTL() is correct ... could you try putting the irq save/restore calls at the top/bottom of the function and see if that makes a difference ?

QuoteReplyEditDelete

 

 

2008-03-27 20:33:51     Re: make error with cpu frequency scaling

Jonathan Kotta (UNITED STATES)

Message: 53189    OK, I changed my bfin_write_VR_CTL() to look like this:

 

/* Writing to VR_CTL initiates a PLL relock sequence. */

static __inline__ void bfin_write_VR_CTL(unsigned int val)

{

    unsigned long flags, iwr0, iwr1, iwr2;

 

    local_irq_save(flags);

 

    /* Enable the PLL Wakeup bit in SIC IWR */

    iwr0 = bfin_read32(SIC_IWR0);

    iwr1 = bfin_read32(SIC_IWR1);

    iwr2 = bfin_read32(SIC_IWR2);

    /* Only allow PPL Wakeup) */

    bfin_write32(SIC_IWR0, IWR_ENABLE(0));

    bfin_write32(SIC_IWR1, 0);

    bfin_write32(SIC_IWR2, 0);

 

    bfin_write16(VR_CTL, val);

    SSYNC();

 

    /*local_irq_save(flags);*/

    asm("IDLE;");

    /*local_irq_restore(flags);*/

    bfin_write32(SIC_IWR0, iwr0);

    bfin_write32(SIC_IWR1, iwr1);

    bfin_write32(SIC_IWR2, iwr2);

 

    local_irq_restore(flags);

}

 

The problem is still there.

QuoteReplyEditDelete

 

 

2008-03-27 22:59:10     Re: make error with cpu frequency scaling

Mike Frysinger (UNITED STATES)

Message: 53201    your patch is full of whitespace damage ... please refrain from making such changes (tabs -> spaces) when posting things for review as it makes it very hard to figure out what you actually changed.

 

how come you needed to change time-ts.c ?

 

can you describe the exact hardware you're using and the exact settings you're transitioning to/from when things hang ?

QuoteReplyEditDelete

 

 

2008-03-28 12:16:03     Re: make error with cpu frequency scaling

Jonathan Kotta (UNITED STATES)

Message: 53258    Sorry about the whitespace; I hate tabs.  I've attached a new tabified patch.

 

I needed to change time-ts.c to modify the way the core timer works.  I'm changing cclk, which the core timer runs off of, which changes the kernel tick rate, which is assumed to be constant.  In the initialization of the core timer, I set the period shorter and set a divider.  Then I change the divider (tscale) in cpufreq.  I figured this would be easier than reinitializing the timer every time I changed frequencies.

 

I have a BF548-ezkit-lite, board rev 1.3.  It has a bf549 processor on it, SI rev 0.1.

 

I do this to set the frequency:

root:/sys/devices/system/cpu/cpu0/cpufreq> echo userspace > scaling_governor

root:/sys/devices/system/cpu/cpu0/cpufreq> echo 525000000 > scaling_setspeed

root:/sys/devices/system/cpu/cpu0/cpufreq> echo 262500000 > scaling_setspeed

root:/sys/devices/system/cpu/cpu0/cpufreq> echo 131250000 > scaling_setspeed

root:/sys/devices/system/cpu/cpu0/cpufreq> echo 65625000 > scaling_setspeed

 

It always crashes when I transition to 131 MHz or 65 MHz, from a higher frequency (525 MHz or 262 MHz).  This might be because sclk is changing during those transitions, but not the others.  It crashes on boot about half the time when I set userspace to be the default governor.  It crashes sporadically when transitioning to 525 MHz or 262 MHz.  Sometimes I get a HW trace, but I haven't seen any pattern to them.

 

When I don't call bfin_write_VR_CTL(), I can change frequencies as much as I want.

cpufreq.patch

QuoteReplyEditDelete

 

 

2008-03-28 13:20:01     Re: make error with cpu frequency scaling

Mike Frysinger (UNITED STATES)

Message: 53260    Michael may be able to provide better guidance as he's our power guy ...

 

with the SCLK reprogramming though, we'll probably need to setup our system for that.  i imagine we'd have to create an atomic notify chain (linux/notifier.h) and each of our peripheral drivers that relies on SCLK would register with that chain.  then our scale code would reprogram SCLK and then atomically call the chain ...

QuoteReplyEditDelete

 

 

2008-03-31 15:36:57     Re: make error with cpu frequency scaling

Jonathan Kotta (UNITED STATES)

Message: 53384    Does Michael frequent these forums?

 

I got it sort of working.  It's unstable, but it works sometimes.  I got rid of the SIC_IWR stuff from bfin_write_VR_CTL().  I can see why it is there, but the manual says nothing about that (in the VR_CTL section).

 

After reading about notifier chains, I agree that that is the way to go, but I really don't know much about actually using them yet.

QuoteReplyEditDelete

 

 

2008-03-31 15:56:48     Re: make error with cpu frequency scaling

Mike Frysinger (UNITED STATES)

Message: 53387    he's just on vacation atm

 

using notifier chains are easy ... but that'll come after we get the VR_CTL updating stable

QuoteReplyEditDelete

 

 

2008-03-31 15:56:56     Re: make error with cpu frequency scaling

Robin Getz (UNITED STATES)

Message: 53388    Jonathan:

 

>When I don't call bfin_write_VR_CTL(), I can change frequencies as much as I want.

 

When you don't write to the VR_CTL() - you aren't actually reprogramming anything.

 

The writes to PLL control registers does not actually change the PLL settings unless you go through a PLL reprogramming sequence. If you are simply changing the core dividor or SCLK dividor - it should the clocks on the next instruction. PLLs do not.

 

-Robin

QuoteReplyEditDelete

 

 

2008-04-01 03:37:01     Re: make error with cpu frequency scaling

Michael Hennerich (GERMANY)

Message: 53404    Jonathan,

 

the crashes you observe are likely coming from losing data integrity in external DDR L3 Memory.

Whenever you alter SCLK you have to reprogram DDR DRAM initialization parameters accordingly.

 

The sequence looks like folllowing:

 

1) Put DDR into self refresh

2) change SCLK

3) Update DDR registers (see include/asm-blackfin/mach-bf548/mem_init.h)

4) undo DDR self refresh

 

Best regards,

Michael

QuoteReplyEditDelete

 

 

2008-04-01 11:48:14     Re: make error with cpu frequency scaling

Jonathan Kotta (UNITED STATES)

Message: 53468    Thanks Michael.  I will try to get this working.

QuoteReplyEditDelete

 

 

2008-04-11 13:17:04     Re: make error with cpu frequency scaling

Jonathan Kotta (UNITED STATES)

Message: 54103    Michael:

 

When I said before that I can change the frequency all I want, I spoke prematurely.  I set up a script to change the frequency randomly, and it ran hundreds of times with no trouble, and I think I just got (un)lucky.  I can usually change the frequency dozens of times, but eventually it crashes.  Not surprising at all given your advice.

I've been trying to implement what you said.  I think I have the SDRAM in self-refresh and the code to modify the PLL in SRAM.  It still doesn't work reliably.  Any ideas?

 

What is mem_init.h for?  Is it just some sort of documentation?  I can't see it used anywhere, and when I tried to include it, there were errors about undefined symbols.  In any case, it was useful.

 

I was previously using 2.6.24, I am now using 2.6.22 from 2008R1-RC8.  New patch is attached.

cpufreq.patch

QuoteReplyEditDelete

 

 

2008-04-11 14:06:56     Re: make error with cpu frequency scaling

Mike Frysinger (UNITED STATES)

Message: 54108    pretend mem_init.h doesnt exist ... we're phasing it out

QuoteReplyEditDelete

 

 

2008-04-14 15:15:23     Re: make error with cpu frequency scaling

Michael Hennerich (GERMANY)

Message: 54208    Hi Jonathan,

 

>What is mem_init.h for?  Is it just some sort of documentation?

 

Just for your reference on how to compute the DDR control registers.

 

>It still doesn't work reliably.  Any ideas?

 

Do you know when it fails - which transition (from-to frequency, etc.)

How does it fail ?

 

Can you send me your test script - I will give your patch a try tomorrow.

 

-Michael

QuoteReplyEditDelete

 

 

2008-04-14 18:02:06     Re: make error with cpu frequency scaling

Jonathan Kotta (UNITED STATES)

Message: 54218    I can't see a pattern.  It crashes even when I just change to the same frequency over and over, as in "echo 525000000 > scaling_setspeed" over and over.  Test script is attached.

cpufreq_test.sh

QuoteReplyEditDelete

 

 

2008-04-15 11:49:59     Re: make error with cpu frequency scaling

Michael Hennerich (GERMANY)

Message: 54284    Hi Jonathan,

 

I spend today root causing what troubles your patch.

 

1) One issue was that you write VR_CTL with the same value.

 

"If the new value written to the PLL_CTL or VR_CTL register is the

same as the previous value, the PLL wake-up will occur immediately

(PLL is already locked), but the core and system clock will be

bypassed for the PLL_LOCKCNT duration. For this interval, code will

execute at the CLKIN rate instead of at the expected CCLK rate.

Software should guard against this condition by comparing the

current value to the new value before writing the new value."

 

 

I fixed that by adding a check to the bfin_write_VR_CTL() functions.

 

Now your code started to update VLEV.

 

 

2) The other issue is a bit more tricky - actually putting DDR

into Self Refresh is causing issues.

Your bf548_commit_pll() function with only DDR Self Refresh IN/OUT

is sometimes causing something similar to a Core Hang.

 

While the DDR is in Self Refresh Core, Cache and DMA should

not issue requests to DDR Memory.

I think this is what happens. You need to ensure that all DMA to L3 memory is turned off,

caches are flushed and your code doesn't run off or access L3 memory.

 

I would simply not change SCLK, only change CCLK using CSEL, and update VLEV

 

With a 525MHz VCO this gives you 3 possible frequencies:

 

CCLK = 525 MHz

CCLK = 262.5 MHz

CCLK = 131.25 MHz

 

I tried those three with setting the Core Voltage accordingly and the

OnDemand Governor for more than a couple hours, and thousands of transitions - without problems.

 

Best regards,

Michael

QuoteReplyEditDelete

 

 

2008-04-15 14:09:53     Re: make error with cpu frequency scaling

Jonathan Kotta (UNITED STATES)

Message: 54289    OK, that all makes sense.  Thanks for all of your help.

Outcomes