[U-Boot-Users] asynchronous clocking mode for arm920t
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
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
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
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
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
participants (2)
-
Anders Larsen -
Steven Scholz