XM Processor speed

[svrsig]

Running RISCOS on the XM means that the Linux Kernel is completely
replaced by the RISC OS 'hardware abstraction layer'. What ARM code is
required please to sense and change processor speed from the default
600 MHz to the options of 800 MHz and 1000MHz?

[Vladimir Pantelic]

replacing linux with riscos does not prevent you from looking
inside the linux kernel source code to see how the processor
speed change is done there.

same goes for reading the OMAP3 TRM, it is not linux specific
at all.

[svrsig]

A rather general reply - I was looking for something more specific!!

[Vladimir Pantelic]

On 09/20/2010 09:28 PM, svrsig wrote:
> A rather general reply - I was looking for something more specific!!

as in "please take your time to teach me things that I am to lazy to
look for myself"?

[svrsig]

'The linux kernel source code' with no link is unhelpful. I do not
program in C or C++ but am familiar with ARM code and BBC BASIC and so
will struggle with C code, hence why I asked about the relevant ARM
code. I don't want to struggle to *find* the relevant source as well!

[Maxim Podbereznyy]

what is ARM code? :)

2010/9/21 svrsig <ch...@svrsig.org>

--
You received this message because you are subscribed to the Google Groups "Beagle Board" group.
To post to this group, send email to beagl...@googlegroups.com.
To unsubscribe from this group, send email to beagleboard...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/beagleboard?hl=en.

[Gabi Voiculescu]

What you want is not very simple nor available in all flavors of the linux kernel. Depending on what version of the mainline kernel you use there may be no C sources to do what you want. Some links can be found here: http://elinux.org/OMAP_Power_Management, http://elinux.org/ELC_2010_Presentations The best source of information are the kernel sources. For ARM, particularily the omap processor class (which includes the soc used on the beagleboard xm), look at linux-omap-pm.git repository: - you need linux, git repository source control installed  then use (git clone git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git), since that is where the latest power management C sources can be found.  In any case you should look for the keywords: - dm37x - the CPU built into the beagleboard xM - OPP (operating point: a pair of frequncy / voltage at which TI recomends the OMAP34x/OMAP35x/DM37x processors reliably work (so do not look for a freq/voltage continuous law in the docs). For the actual points you need to refer to the dm37x data sheet from TI (while comparing the silicon implementation of the processor with what is in the beagle xm). - the frequency change is in files from: arch/arm/mach-omap2/ and arch/arm/plat-omap/ ... clock34xx.* contain the low level abstraction on top of the hw - the voltage registers are publicly undocumented but there are sources that make changes to these undocumented registers in linux --- On Tue, 9/21/10, Maxim Podbereznyy <lisa...@gmail.com> wrote:

[svrsig]

ARM code is simply that - machine code. For example LD R2,#3 ; ADR
R1,#0X800112233 ; STR [R1],R2 etc.
Setting processor speed would read and set registers which affect
clock divide and appear as physical memory.
But it does look rather more complicated than that due to the need for
power saving, temperature monitoring etc.
I may try to infer the necessary ARM code from the C source if it is
well documented - if the constants and memory locations are buried in
other files rather than clearly specified in the source then I'll let
someone else do it.

> > beagleboard...@googlegroups.com<beagleboard%2Bunsu...@googlegroups.com>
> > .

[h...@computer.org]

The register addresses and the individual bits are described in the
OMAP353x
Technical Reference Manual. You can download the 3500 pages through

http://focus.ti.com/docs/prod/folders/print/omap3530.html#technicaldocuments

With using this information you don't have to look into any C code and
have the best
control over all processor features.

Or, you run the kernel code through gcc -S to see the assembler code
produced by
the compiler. One hint you may be looking for: get the kernel sources
and look into

arch/arm/mach-omap2/board-omap3beagle.c
arch/arm/plat-omap/*.c

But anyway, my impression is that you are too low level. You should
better learn C
than how to program the OMAP registers in assembler.

On 21 Sep., 22:46, svrsig <ch...@svrsig.org> wrote:
> ARM code is simply that - machine code. For example LD R2,#3 ; ADR
> R1,#0X800112233 ; STR [R1],R2 etc.
> Setting processor speed would read and set registers which affect
> clock divide and appear as physical memory.
> But it does look rather more complicated than that due to the need for
> power saving, temperature monitoring etc.

Yes, it *is* complicated. Therefore, all this is done in higher level
language source code (C).

> > > beagleboard...@googlegroups.com<beagleboard%2Bunsubscribe@googlegr oups.com>

[Michael Zucchi]

The problem is the linux source is difficult to follow at the best of
times unless you work on it all the time, and the omap stuff isn't the
best of times by any stretch. The omap code supports numerous devices
and is written by many people and is spread all over the place. And
RiscOS probably doesn't even do the power management stuff (it isn't
really required if you're not on batteries) after the bootloader has
setup the system so a lot of what you do find might not be applicable
anyway (or make the whole job more painful).

Isn't this the cpu in the XM anyway?
http://focus.ti.com/docs/prod/folders/print/dm3730.html

> To unsubscribe from this group, send email to beagleboard...@googlegroups.com.

[Maxim Podbereznyy]

If you want to dig the Linux sources easy then install "ctags" and just watch C-code of every single function or definitions. It is fast and easy.

DM3730 is at XM

2010/9/22 Michael Zucchi <not...@gmail.com>

[svrsig]

My first hack is therefore:
mm%=!&48004940
REM Contents of CM_CLKSEL1_PLL_MPU
m%=(mm% AND &7FF00)>>8
n%=mm% AND &3F
nn%=!&48004944
REM Contents of CM_CLKSEL2_PLL_MPU
m2%=nn% AND &1F
PRINT "Clock speed is 52MHz mult by";m%;" div by ";n%+1;" div by
";m2%;" =";52*m%/(n%+1)/m2%;" MHz"

On Sep 22, 9:44 am, Maxim Podbereznyy <lisar...@gmail.com> wrote:
> If you want to dig the Linux sources easy then install "ctags" and just
> watch C-code of every single function or definitions. It is fast and easy.
>
> DM3730 is at XM
>
> 2010/9/22 Michael Zucchi <not...@gmail.com>
>
> > The problem is the linux source is difficult to follow at the best of
> > times unless you work on it all the time, and the omap stuff isn't the
> > best of times by any stretch.  The omap code supports numerous devices
> > and is written by many people and is spread all over the place.  And
> > RiscOS probably doesn't even do the power management stuff (it isn't
> > really required if you're not on batteries) after the bootloader has
> > setup the system so a lot of what you do find might not be applicable
> > anyway (or make the whole job more painful).
>
> > Isn't this the cpu in the XM anyway?
> >http://focus.ti.com/docs/prod/folders/print/dm3730.html
>
> > On 22 September 2010 15:48, h...@computer.org <h...@computer.org> wrote:
> > > The register addresses and the individual bits are described in the
> > > OMAP353x
> > > Technical Reference Manual. You can download the 3500 pages through
>

> >http://focus.ti.com/docs/prod/folders/print/omap3530.html#technicaldo...

> > >> > > beagleboard...@googlegroups.com<beagleboard%2Bunsu...@googlegroups.com>

> > <beagleboard%2Bunsubscribe@googlegr oups.com>
> > >> > > .
> > >> > > For more options, visit this group at
> > >> > >http://groups.google.com/group/beagleboard?hl=en.
>
> > > --
> > > You received this message because you are subscribed to the Google Groups
> > "Beagle Board" group.
> > > To post to this group, send email to beagl...@googlegroups.com.
> > > To unsubscribe from this group, send email to

> > beagleboard...@googlegroups.com<beagleboard%2Bunsu...@googlegroups.com>

> > .
> > > For more options, visit this group at
> >http://groups.google.com/group/beagleboard?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Beagle Board" group.
> > To post to this group, send email to beagl...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > beagleboard...@googlegroups.com<beagleboard%2Bunsu...@googlegroups.com>

[svrsig]

And then dynamically change CM_CLKSEL2_PLL_MPU to select 600/800/1000
MHz.

[Vladimir Pantelic]

On 09/21/2010 10:46 PM, svrsig wrote:
> ARM code is simply that - machine code. For example LD R2,#3 ; ADR
> R1,#0X800112233 ; STR [R1],R2 etc.

well yes, but many people these days trust a compiler to convert C
code to "ARM" code :) And C code that writes a few values to registers
is not much harder to read than "ARM" code.

> I may try to infer the necessary ARM code from the C source if it is
> well documented - if the constants and memory locations are buried in
> other files rather than clearly specified in the source then I'll let
> someone else do it.

ah, yes, not putting all those pesky constants into every source code
file, but rather into common include files is a very bad thing to do,
right?

[svrsig]

Fortunately someone else has been helpful and has provided the
necessary code, written in BASIC:

10ON ERROR PRINT REPORT$;" at ";ERL : END
20DIM buf% 256
30DIM code% 256
40DCDC_GLOBAL_CFG = &61
50VDD1_VSEL = &B9
60VDD1_VMODE_CFG = &BA
70
80MPU_CM = &48004900
90CM_CLKEN_PLL_MPU = &4
100CM_IDLEST_MPU = &20
110CM_IDLEST_PLL_MPU = &24
120CM_AUTOIDLE_PLL_MPU = &34
130CM_CLKSEL1_PLL_MPU = &40
140CM_CLKSEL2_PLL_MPU = &44
150CM_CLKSTCTRL_MPU = &48
160CM_CLKSTST_MPU = &4C
170
180CONTROL_IDCODE = &4830A204
190
200DATA "OMAP35x", &B6D6, &B7AE : REM Two different hawkeye numbers
for OMAP35x
210REM Ascending order for easier lookup
220REM OPP VDD1 MPU IVA2 DPLL1CLKOUT_M2
230DATA "OPP1", 0.985, 125, 90, 1
240DATA "OPP2", 1.06, 250, 180, 1
250DATA "OPP3", 1.20, 500, 360, 1
260DATA "OPP4", 1.27, 550, 400, 1
270DATA "OPP5", 1.35, 600, 430, 1
280DATA "OPP6", 1.35, 720, 520, 1
290DATA "", 0, 0, 0, 0
300
310
320DATA "AM/DM37x", &B891, &B891 : REM Repeat the same number twice
to keep the code simple!
330REM OPP VDD1 MPU IVA2 DPLL1CLKOUT_M2
340DATA "OPP60", 0.97, 300, 260, 2
350DATA "OPP100", 1.14, 600, 520, 1
360DATA "OPP130", 1.27, 800, 660, 1
370DATA "", 0, 0, 0, 0
380
390DATA "", 0, 0
400
410REM Code to peek/poke memory
420P%=code%
430[ OPT 2
440.peek%
450SWI "OS_EnterOS"
460LDR R0,[R0]
470MSR CPSR_c,#16
480MOV PC,R14
490.poke%
500SWI "OS_EnterOS"
510STR R1,[R0]
520MSR CPSR_c,#16
530MOV PC,R14
540]
550
560REM Detect OMAP type
570SYS "OS_Memory",14,CONTROL_IDCODE TO ,,A%,key%
580ON ERROR SYS "XOS_Memory",15,key% : PRINT REPORT$;" at ";ERL :
END
590IDCODE%=USR peek%
600HAWKEYE%=(IDCODE%>>12) AND &FFFF
610A$=FNFindOMAP
620IF A$<>"" THEN PRINT "Machine belongs to ";A$;" family" ELSE
PRINT "Unknown OMAP type!" : SYS "XOS_Memory",15,key% : END
630
640REM Map in MPU_CM
650SYS "OS_Memory",14,MPU_CM TO ,,CM%
660
670REM Verify that everything is as we expect
680IF (FNpeek(CM_CLKEN_PLL_MPU) AND 7)<>7 OR
(FNpeek(CM_IDLEST_PLL_MPU) AND 1)<>1 THEN
690 PRINT "Warning: MPU DPLL not locked!"
700ENDIF
710CLKSEL1 = FNpeek(CM_CLKSEL1_PLL_MPU)
720IF (CLKSEL1 AND &7F)<>&C THEN
730 PRINT "Warning: Unexpected MPU_DPLL_DIV value detected.
Frequency calculations may be incorrect!"
740ENDIF
750CLKSEL2 = FNpeek(CM_CLKSEL2_PLL_MPU)
760
770REM With a 13MHz sys_clk and a MPU_DPLL_DIV of &C, the MPU clock
frequency is given by CM_CLKSEL1_PLL_MPU.MPU_DPLL_MULT/
CM_CLKSEL2_PLL_MPU.MPU_DPLL_CLKOUT_DIV
780MPU_FREQ% = ((CLKSEL1>>8) AND &7FF)/(CLKSEL2 AND &1F)
790PRINT "Current frequency: ";MPU_FREQ%;"MHz"
800
810REM Now check VDD1
820IF (FNread(DCDC_GLOBAL_CFG) AND 8)<>0 THEN
830 PRINT "SmartReflex is enabled! Surely we have a proper way of
changing CPU frequency by now? Go use that instead!"
840 SYS "XOS_Memory",15,key%
850 END
860ELSE IF (FNread(VDD1_VMODE_CFG) AND 1)<>0 THEN
870 PRINT "VMODE is enabled! Who's controlling VDD1?"
880 SYS "XOS_Memory",15,key%
890 END
900ELSE
910 PRINT "VDD1 under manual control"
920ENDIF
930ENDIF
940
950PROCsetbits(VDD1_VMODE_CFG,2)
960VDD1% = FNread(VDD1_VSEL)
970PRINT "Current VDD1: ";(VDD1%*0.0125+0.6);"V"
980A$=FNFindOMAP
990READ OPP$
1000MIN=10000
1010MAX=0
1020WHILE OPP$<>""
1030 READ V,MPU,IVA,DPLL1CLKOUT_M2
1040 PRINT OPP$;" ";V;"V max ";MPU;"MHz"
1050 IF MPU>MAX THEN MAX=MPU
1060 IF MPU<MIN THEN MIN=MPU
1070 READ OPP$
1080ENDWHILE
1090INPUT "Enter new MPU clock frequency (MHz)";N%
1100IF (N%<MIN) OR (N%>MAX) THEN PRINT "Bad frequency!" : SYS
"XOS_Memory",15,key% : END
1110
1120REM Work out which OPP it belongs in
1130A$=FNFindOMAP
1140REPEAT
1150 READ OPP$,V,MPU,IVA,DPLL1CLKOUT_M2
1160UNTIL MPU>=N%
1170
1180PRINT "Chosen frequency lies in ";OPP$
1190NEW_VDD1%=((V-0.6)+0.0124)/0.0125 : REM Round up
1200NEW_V = NEW_VDD1%*0.0125+0.6
1210REM Pre-increment VDD1 to ensure stability
1220IF (NEW_VDD1% > VDD1%) THEN
1230 PRINT "Increasing VDD1 to ";NEW_V;"V"
1240 PROCwrite(VDD1_VSEL,NEW_VDD1%)
1250 IF FNread(VDD1_VSEL)<>NEW_VDD1% THEN
1260 PRINT "VDD1 change failed! Aborting"
1270 PROCwrite(VDD1_VSEL,VDD1%)
1280 SYS "XOS_Memory",15,key%
1290 END
1300 ENDIF
1310ENDIF
1320IF (N%<>MPU_FREQ%) OR (DPLL1CLKOUT_M2<>(CLKSEL2 AND &1F)) THEN
1330 PRINT "Adjusting MPU DPLL to ";N%;"..."
1340 REM Go to bypass mode
1350 PROCpoke(CM_CLKEN_PLL_MPU,(FNpeek(CM_CLKEN_PLL_MPU) AND
&7FF8)+5)
1360 REM Wait for completion
1370 WHILE (FNpeek(CM_IDLEST_PLL_MPU) AND 1)<>0
1380 ENDWHILE
1390 REM Set new frequency
1400 PROCpoke(CM_CLKSEL2_PLL_MPU,DPLL1CLKOUT_M2)
1410 PROCpoke(CM_CLKSEL1_PLL_MPU,(CLKSEL1 AND &3800FF) + ((N
%*DPLL1CLKOUT_M2)<<8))
1420 REM Request lock
1430 PROCpoke(CM_CLKEN_PLL_MPU,FNpeek(CM_CLKEN_PLL_MPU) OR 7)
1440 REM Wait for completion
1450 WHILE (FNpeek(CM_IDLEST_PLL_MPU) AND 1)<>1
1460 ENDWHILE
1470 PRINT "...complete!"
1480ENDIF
1490IF (NEW_VDD1% < VDD1%) THEN
1500 PRINT "Decreasing VDD1 to ";NEW_V;"V"
1510 PROCwrite(VDD1_VSEL,NEW_VDD1%)
1520 IF FNread(VDD1_VSEL)<>NEW_VDD1% THEN
1530 PRINT "VDD1 change failed! System may be unstable!"
1540 ENDIF
1550ENDIF
1560
1570SYS "XOS_Memory",15,key%
1580END
1590
1600DEF PROCclearbits(reg%,clr%)
1610PROCmodbits(reg%,clr%,0)
1620ENDPROC
1630DEF PROCsetbits(reg%,set%)
1640PROCmodbits(reg%,0,set%)
1650ENDPROC
1660DEF PROCmodbits(reg%,clr%,set%)
1670PROCwrite(reg%,(FNread(reg%) AND NOT clr%) OR set%)
1680ENDPROC
1690DEF PROCwrite(reg%,byte%)
1700buf%!0 = &4b*2
1710buf%!4 = buf%+128
1720buf%!8 = 2
1730buf%?128 = reg%
1740buf%?129 = byte%
1750SYS "OS_IICOp",buf%,1
1760ENDPROC
1770DEF FNread(reg%)
1780buf%!0 = &4b*2
1790buf%!4 = buf%+128
1800buf%!8 = 1
1810buf%?128 = reg%
1820buf%!12 = &4b*2+1
1830buf%!16 = buf%+132
1840buf%!20 = 1
1850SYS "OS_IICOp",buf%,2
1860=buf%?132
1870DEF FNpeek(addr%)
1880A%=CM%+addr%
1890=USR peek%
1900DEF PROCpoke(addr%,val%)
1910A%=CM%+addr%
1920B%=val%
1930CALL poke%
1940ENDPROC
1950DEF FNFindOMAP
1960RESTORE
1970REPEAT
1980 READ A$,HAWKEYE1%,HAWKEYE2%
1990 IF A$="" OR HAWKEYE1%=HAWKEYE% OR HAWKEYE2%=HAWKEYE% THEN =A$
2000 REM Skip the OPP table
2010 REPEAT
2020 READ OPP$,V,MPU,IVA,DPLL1CLKOUT_M2
2030 UNTIL OPP$=""
2040UNTIL FALSE

[Maxim Podbereznyy]

KILL ME NOW!
who reads and support such shi#?

svrsig, do you feel yourself lucky? I believe you are not!

2010/9/23 svrsig <ch...@svrsig.org>

--
You received this message because you are subscribed to the Google Groups "Beagle Board" group.
To post to this group, send email to beagl...@googlegroups.com.

To unsubscribe from this group, send email to beagleboard...@googlegroups.com.

[Mark Crichton]

Or use LXR locally. Which is a nice way to browse the code. Sadly, I
don't think there's a public version on the OMAP branch of the kernel,
but there should be. Anyone with some beefy hardware able to build the
index and share it with the world?

Look at http://lxr.linux.no for an example. That just follows the
vanilla branch.

As for ARM code, best bet is to read the CPU documentation, and if you
know ARM, just engage your brain to put together what you need to do.
I find that looking at the output of GCC sometimes makes my head want
to explode, since sometimes it's far from simple and straightforward.

Take Care,
Mark Crichton

[Dave Hylands]

Hi,

On Wed, Sep 22, 2010 at 1:44 AM, Maxim Podbereznyy <lisa...@gmail.com> wrote:
> If you want to dig the Linux sources easy then install "ctags" and just
> watch C-code of every single function or definitions. It is fast and easy.

Another site that I find extremely useful is

http://http://lxr.linux.no/linux/

This is cross referenced HTML of the full sources. You can pick your
version as well.

This works well for all of the code that's in the mainline kernel.

--
Dave Hylands
Shuswap, BC, Canada
http://www.DaveHylands.com/

[svrsig]

Clearly you are not a programmer! This is simply a stop-gap for RISC
OS where a proper solution will either be incorporated into the ROM
image using a C compiler, or will be a stand-alone utility (as in the
Linux GUI) written either in BASIC or in C when the more complex
SmartReflex bits are adeed, without which 1GHz is noit supported.
Meanwhile this simply allows the speed to be cranked up from 600MHz to
800MHz. It is not important whether this temporary patch is elegant or
not as it is only a stepping stone to the proper solution. It is a bit
complicated as the relevant memory addresses are not in the BASIC user
memory area but is written in modular form, with comments and defined
constants to make it more readbale. Far easier than trawling through
poorly indexed C source manually.

> > beagleboard...@googlegroups.com<beagleboard%2Bunsu...@googlegroups.com>
> > .

[Vladimir Pantelic]

On 09/24/2010 11:59 AM, svrsig wrote:
> Clearly you are not a programmer! This is simply a stop-gap for RISC
> OS where a proper solution will either be incorporated into the ROM
> image using a C compiler,

so suddenly you are able to handle C code :)

> or will be a stand-alone utility (as in the
> Linux GUI) written either in BASIC or in C when the more complex
> SmartReflex bits are adeed, without which 1GHz is noit supported.
> Meanwhile this simply allows the speed to be cranked up from 600MHz to
> 800MHz. It is not important whether this temporary patch is elegant or
> not as it is only a stepping stone to the proper solution. It is a bit
> complicated as the relevant memory addresses are not in the BASIC user
> memory area but is written in modular form, with comments and defined
> constants to make it more readbale. Far easier than trawling through
> poorly indexed C source manually.

lol

[svrsig]

No, I am not interested in C code. Someone else is doing the
compiling!

[Mark Lazarewicz]

All of these HOTOW's and cryptic sites to get your beagle board running   If you are just starting out and are an application type   See http://www.keil.com/support/man/docs/ds5gs/ds5gs_2dev_bb.htm   You will need to download the eclipse based GUI and buy the usb2ethernet dongle to use ethernet to debug an application can be up in an hour --- On Fri, 9/24/10, svrsig <ch...@svrsig.org> wrote:

-- You received this message because you are subscribed to the Google Groups "Beagle Board" group. To post to this group, send email to beagl...@googlegroups.com.

To unsubscribe from this group, send email to beagleboard+unsub...@googlegroups.com.