Hello,
I'd like to bring your attention on the patch submitted by Anders which is pending in the commit queue. On my config it leads to huge slowdown (x10 slower) when executing standalone codes in Uboot, whereas its ok under Linux environnement.
The problem is set when overriding lowlevel_init function in defining a new void one in $(UB-1.1.3)/board/at91rm9200zeph/at91rm9200zeph.c. Indeed, this was fine and prevented linker error (undef symb) but it also prevent the I/D cache flush and the MMU disabling from happening.
Is this slowndown happens because of the MMU being activated or because of the cache being not flush ? I just can't tell. But in the opposite of Ander's reply, calling cpu_init_crit (without calling lowlevel_init of course) has to happen even when defining true CONFIG_SKIP_LOWLEVEL_INIT setup.
Doing so, and testing it for a while it breaks nothing for me.
In the end, my patch submission on the 20th is valid and workeable whether you start standalone application or not (if Linux has started ).
Mathieu Deschamps
On Tuesday 20 September 2005 11:36, you wrote:
Mathieu Deschamps mathieu.deschamps@com2gether.net schreibt:
=========== --- cpu/arm920t/start.S.orig 2005-09-19 16:35:45.000000000 +0200 +++ cpu/arm920t/start.S 2005-09-20 09:09:33.000000000 +0200 @@ -156,9 +156,7 @@ * we do sys-critical inits only at reboot, * not when booting from ram! */ -#ifndef CONFIG_SKIP_LOWLEVEL_INIT bl cpu_init_crit -#endif
Calling cpu_init_crit when CONFIG_SKIP_LOWLEVEL_INIT is defined doesn't look right and is sure to break e.g. the at91rm9200dk.
@@ -262,9 +260,11 @@ * find a lowlevel_init.S in your board directory. */ mov ip, lr
+#ifndef CONFIG_SKIP_LOWLEVEL_INIT bl lowlevel_init +#endif
A slightly different version (making lowlevel_init do noting when CONFIG_SKIP_LOWLEVEL_INIT is defined) is included in my "[PATCH 1/5] CSB637 - add KB920x support" submitted on the 2005-08-25 (pending in Wolfgang's queue).
Cheers Anders