lastest 1.1.3 CONFIG_SKIP problems with arm920t on rm9200.

Hello,

I have upgraded U-Boot 1.1.2 to lastest 1.1.3. I still uses the boot.bin program to set up the flash and the dram and such while having defined SKIP_RELOCATE_UBOOT and SKIP_LOWLEVEL_INIT.

Indeed kept undefined I have seen that it breaks everything reaching SoC specific lowlevel_init.S in cpu/.../start.S. Imagine reinitializing flash while reading init values from it, or reinit the memory controller while using it !

It seems that these two were compulsory in my case. But even defined, my cpu goes in ABORT.

Any ideas ?

Regards,

Mathieu Deschamps

Hello!

I've tried similar configuration recently. My board has only a DataFlash, not parallel flash, and I'm forced to use RomBoot to initialize CPU and SDRAM.
It works for me.

I've inserted the following options into u-boot-1.1.3/include/configs/at91rm9200dk.h (which I'm using as a template for my config), and it works:
#define CONFIG_SKIP_LOWLEVEL_INIT
#define CONFIG_SKIP_RELOCATE_UBOOT

Also I've commented "bl lowlevel_init" instruction in u-boot-1.1.3/cpu/arm920t/start.S because it is undefined with SKIP_LOWLEVEL_INIT option set, and causes linking error.

Strange... As for me, it only breaks linking because of absence lowlevel_init.S in compilation with CONFIG_SKIP_LOWLEVEL_INIT set. See above for a solution.

With best regards,
  Andrey Vasilyev

P.S. Sorry for my bad english...

Hello and Hurrah !

It works, thanks for your answer Andrey :

Indeed I had the same linker trouble and what I decided to do was to move the ifdef SKIP_LOWLEVEL_INIT inside the cpu_init_crit in order to keep the 'bl' instr. and its symbol alone thus preventing linker's shouts (yes it complains about this)

The idea was good nevertheless I did it roughly (my #ifdef #endif embraced the whole procedure inners !) and Prog Counter never returned. Today's second look at it and I realized that only 'bl lowlevel_init' have to be commented or undef conditionnaly. See working patch below.

In the end, I'am wondering if letting still MMU disabled and ICACHE and DCACHE flushed could harm the rest of the U-Boot process...

Need of an extra upgrade ?

Mathieu Deschamps.

PS : Your english is fine for me Andrey.

===========

@@ -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
 
 #ifndef CONFIG_SKIP_RELOCATE_UBOOT
 relocate:                              /* relocate U-Boot to RAM           */

@@ -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
        mov     lr, ip
-
        mov     pc, lr
 

=========

Mathieu Deschamps <[email protected]> schreibt:

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