AW: [U-Boot-Users] [PATCH 4/4] add csb637 (at91rm9200) support
Hi Anders,
u-boot-users-admin@lists.sourceforge.net wrote on :
this patch switches the at91rm9200 to synchronous clock mode after initialization (it would otherwise stay in FastBus mode which is the _slowest_ clock mode). This lets the core run at full speed when not doing bus accesses, increasing overall performance by a factor of four.
Changelog:
- patch by Anders Larsen, 2004-04-29 set the at91rm9200 clock to synchronous mode
Cheers Anders
I've tested your patch on the cmc_pu2 board. Boot time is reduced from about 32 s to 26 s with your patch (measured from starting power supply to a specific status message of our linux application). This is great!
I wonder if there are some pitfalls doing this on the AT91RM9200 cpu? As I understand the ARM920T Technical Reference Manual the clocking modes are a feature of the ARM920T core and not affected by the surrounding on-chip peripherals added by Atmel. So it should work for all cpu's with ARM920T core without problems?
I've also done an nbench benchmark under linux running in synchronous clock mode. But the results are the same as in fast bus clock mode. Strange. I've no idea why.
Regards, Martin
"Martin Krause" Martin.Krause@tqs.de schreibt:
I wonder if there are some pitfalls doing this on the AT91RM9200 cpu? As I understand the ARM920T Technical Reference Manual the clocking modes are a feature of the ARM920T core and not affected by the surrounding on-chip peripherals added by Atmel. So it should work for all cpu's with ARM920T core without problems?
Hi Martin,
there might be some boards with ARM920T cpu who can't use synchronous clock mode due to clock restrictions (see the TRM), but I really can't tell.
I've also done an nbench benchmark under linux running in synchronous clock mode. But the results are the same as in fast bus clock mode. Strange. I've no idea why.
Perhaps your Linux switches clock mode itself? (the at91rm9200 patch from maxim.org.za does _not_, however) What does /proc/cpuinfo say about this? With my patch I get: # grep -i bogomips /proc/cpuinfo BogoMIPS : 91.95 and without it I get appr. 28. I get the same speed improvement (x4) using an RSA encryption benchmark.
For reference here's the output from nbench 2.2.2 on my csb637 board: BYTEmark* Native Mode Benchmark ver. 2 (10/95) Index-split by Andrew D. Balsa (11/97) Linux/Unix* port by Uwe F. Mayer (12/96,11/97)
TEST : Iterations/sec. : Old Index : New Index : : Pentium 90* : AMD K6/233* --------------------:------------------:-------------:------------ NUMERIC SORT : 56.635 : 1.45 : 0.48 STRING SORT : 3.5857 : 1.60 : 0.25 BITFIELD : 1.2262e+07 : 2.10 : 0.44 FP EMULATION : 5.5644 : 2.67 : 0.62 FOURIER : 6.0343 : 0.01 : 0.00 ASSIGNMENT : 0.43937 : 1.67 : 0.43 IDEA : 186.71 : 2.86 : 0.85 HUFFMAN : 22.129 : 0.61 : 0.20 NEURAL NET : 0.0072986 : 0.01 : 0.00 LU DECOMPOSITION : 0.2586 : 0.01 : 0.01 ==========================ORIGINAL BYTEMARK RESULTS====================== INTEGER INDEX : 1.683 FLOATING-POINT INDEX: 0.010 Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0 ==============================LINUX DATA BELOW=========================== CPU : L2 Cache : OS : Linux 2.6.12-rc1-csb C compiler : arm_v4le-gcc libc : static MEMORY INDEX : 0.362 INTEGER INDEX : 0.470 FLOATING-POINT INDEX: 0.006 Baseline (LINUX) : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38 * Trademarks are property of their respective holder.
Cheers Anders
participants (2)
-
Anders Larsen -
Martin Krause