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.