[U-Boot-Users] asynchronous clocking mode for arm920t

[U-Boot-Users] asynchronous clocking mode for arm920t

[Steven Scholz]

Hi all,

( was: [U-Boot-Users] [PATCH 4/4] add csb637 (at91rm9200) support )

I wrote:

 >> this patch switches the at91rm9200 to synchronous clock mode after
 >> initialization (it would otherwise stay in FastBus mode which is
 >> the _slowest_ clock mode).
 >
 > But I thought FastBus mode is the prefered setting for ARM cpus.

Now I retract the above statement and claim the oposite! ;-)

Anders' is correct. Atmel support told me a year ago
"Linux uses the Asynchronous mode."
With his patch I now get 79.87 BogoMIPS again (without less the 40).

So I helps for AT91RM9200.

But I don't see something similar for my i.MX ARM9 and still this on in 
running as fast as expected...
The reason ist that this setting is done in board/mx1fs2/lowlevel_init.S and 
board/scb9328/lowlevel_init.S.

So I'd say the asynchronous clocking mode is best for all arm920t cpus and 
thus maybe this is the better patch:

Index: u-boot/cpu/arm920t/start.S
===================================================================
RCS file: /cvsroot/u-boot/u-boot/cpu/arm920t/start.S,v
retrieving revision 1.13
diff -u -r1.13 start.S
--- u-boot/cpu/arm920t/start.S  5 Apr 2005 22:30:51 -0000       1.13
+++ u-boot/cpu/arm920t/start.S  4 May 2005 11:27:35 -0000
@@ -246,13 +246,14 @@
         mcr     p15, 0, r0, c8, c7, 0   /* flush v4 TLB */

         /*
-        * disable MMU stuff and caches
+        * disable MMU stuff and caches, switch to Asynchronous Clocking Mode
          */
         mrc     p15, 0, r0, c1, c0, 0
         bic     r0, r0, #0x00002300     @ clear bits 13, 9:8 (--V- --RS)
         bic     r0, r0, #0x00000087     @ clear bits 7, 2:0 (B--- -CAM)
         orr     r0, r0, #0x00000002     @ set bit 2 (A) Align
         orr     r0, r0, #0x00001000     @ set bit 12 (I) I-Cache
+       orr     r0, r0, #0xC0000000     @ set bit 31 (iA) and 30 (nF)
         mcr     p15, 0, r0, c1, c0, 0

Can someone comment on the s3c24x0 cpu?

--
Steven

[U-Boot-Users] asynchronous clocking mode for arm920t

[Anders Larsen]

Steven Scholz <steven.scholz@imc-berlin.de> schreibt:
>So I'd say the asynchronous clocking mode is best for all arm920t cpus
>and 
>thus maybe this is the better patch:
>
>Index: u-boot/cpu/arm920t/start.S

Hi Steven,

you're not supposed to switch clocking mode before the PLLs are
set up and have had time to stabilize. This takes place in the
first part of lowlevel_init, which is called _after_ the code
your patch touches.
If we switch clocking mode in start.S we can only do so after
lowlevel_init returns (a few lines further down).

Cheers
 Anders

[U-Boot-Users] asynchronous clocking mode for arm920t

[Steven Scholz]

Anders,

> you're not supposed to switch clocking mode before the PLLs are
> set up and have had time to stabilize. This takes place in the
> first part of lowlevel_init, which is called _after_ the code
> your patch touches.
> If we switch clocking mode in start.S we can only do so after
> lowlevel_init returns (a few lines further down).

Of course, you're right.

But still, I'd love to hear if this is working for s3c24x0 as well.

--
Steven

[U-Boot-Users] asynchronous clocking mode for arm920t

[Anders Larsen]

Hi Steven,

just to avoid misunderstandings:
Indeed it seems the clocking mode is a general ARM920 issue
and not an AT91RM9200-specific one.
I fully agree that the right place to set it is in
cpu/arm920t/start.S as you suggested - only I didn't have the
courage to do it, since I can only test on one board (csb637).

Cheers
 Anders

[U-Boot-Users] asynchronous clocking mode for arm920t

[Steven Scholz]

Hi Anders,

> just to avoid misunderstandings:
> Indeed it seems the clocking mode is a general ARM920 issue
> and not an AT91RM9200-specific one.
> I fully agree that the right place to set it is in
> cpu/arm920t/start.S as you suggested - only I didn't have the
> courage to do it, since I can only test on one board (csb637).

No need to be afraid. Wolfgang does _not_ bite! ;-)

Just prepare a proper patch, explain in the Changelog entry (you have to 
provide) what you are doing and why.

If it sounds sane, noone objectcs and some people can confirm that the patch 
is working (I am happy to test), I am sure Wolfgang will apply your patch. 
Although I don't know how deep his patch stack currently is...

--
Steven