[U-Boot-Users] [Patch] U-Boot-V2: Replace CONFIG_SKIP_LOWLEVEL_INIT with CONFIG_MACH_HAS_INIT_LOWLEVEL

[Sascha Hauer]

On Thu, May 08, 2008 at 11:49:37AM -0500, Menon, Nishanth wrote:
> Hi Sascha,
> Based on http://sourceforge.net/mailarchive/forum.php?thread_name=20080508151609.GB9467%40pengutronix.de&forum_name=u-boot-users
> This is the second separate patch which introducing Machine dependent init lowlevel config.
> 
> Regards,
> Nishanth Menon
> 
> This introduces CONFIG_MACH_HAS_INIT_LOWLEVEL which is the opposite of the current CONFIG_SKIP_LOWLEVEL_INIT.  CONFIG_SKIP_LOWLEVEL_INIT which was used by ARM platform configurations previously, is made platform independent configuration.
> 
> CONFIG_MACH_HAS_INIT_LOWLEVEL can be enabled to do board level initialization and disabled to allow U-Boot to function as the second level boot loader in certain scenarios by skipping SDRAM initialization. 
> 
> Signed-off-by: Nishanth Menon <x0nishan at ti.com>
> 
> Index: u-boot-v2.git/arch/arm/cpu/start-arm.S
> ===================================================================
> --- u-boot-v2.git.orig/arch/arm/cpu/start-arm.S	2008-05-08 11:22:08.000000000 -0500
> +++ u-boot-v2.git/arch/arm/cpu/start-arm.S	2008-05-08 11:23:16.000000000 -0500
> @@ -156,7 +156,7 @@
>  	 * because memory timing is board-dependend, you will
>  	 * find a lowlevel_init.S in your board directory.
>  	 */
> -#ifndef CONFIG_SKIP_LOWLEVEL_INIT
> +#ifdef CONFIG_MACH_HAS_INIT_LOWLEVEL
>  	bl	board_init_lowlevel
>  #endif
>  
> Index: u-boot-v2.git/arch/m68k/cpu/start-mcfv4e.S
> ===================================================================
> --- u-boot-v2.git.orig/arch/m68k/cpu/start-mcfv4e.S	2008-05-08 11:23:17.000000000 -0500
> +++ u-boot-v2.git/arch/m68k/cpu/start-mcfv4e.S	2008-05-08 11:23:38.000000000 -0500
> @@ -448,7 +448,7 @@
>  	 *
>  	 * Do not jump/call other u-boot code here!
>  	 */
> -#ifndef CONFIG_SKIP_LOWLEVEL_INIT
> +#ifdef CONFIG_MACH_HAS_INIT_LOWLEVEL
>  	bsr.l	board_init_lowlevel
>  	nop
>  #endif
> @@ -512,7 +512,7 @@
>  	nop
>  #endif
>  
> -#ifndef CONFIG_SKIP_LOWLEVEL_INIT
> +#ifdef CONFIG_MACH_HAS_INIT_LOWLEVEL
>  	/*
>  	 * Call other half of initcode in relocated code
>  	 *
> Index: u-boot-v2.git/common/Kconfig
> ===================================================================
> --- u-boot-v2.git.orig/common/Kconfig	2008-05-08 11:24:02.000000000 -0500
> +++ u-boot-v2.git/common/Kconfig	2008-05-08 11:27:07.000000000 -0500
> @@ -72,6 +72,14 @@
>  	  Architectures that have additional initialization can enable
>  	  this functionality.
>  
> +config MACH_HAS_INIT_LOWLEVEL
> +	bool
> +	default y
> +	prompt "Board has low level init"
> +	help
> +	  This entry skips the SDRAM initialising on many platforms.
> +	  It enables using U-boot as a second stage bootloader.
> +

This has the same problems as stated in my last mail about
ARCH_HAS_INIT_LOWLEVEL, although the situation is slightly different
here.
The user cannot decide whether the machine actually _has_ a lowlevel
init function, it simply has or has not. The user only can decide
whether he wants to use it after reading the help text (which describes
the situation the wrong way around btw).

I have a feeling that this option is unnessecary anyway because when you
look at the board_init_lowlevel functions you'll see that the board code
detects at runtime whether or not they run from SDRAM and thus have to
skip initialization. This way you can start the same U-Boot binary from
SDRAM Flash or whatever which is a convenient thing to have.

I tend to remove these two options completely. Architectures and boards
which do not need lowlevel init functions can just provide an empty
function here. If we end up introducing many similar options on a board
or architecture level we can still decide to turn them into common options.

So far arch_init_lowlevel is unused. I only introduced it because the
original start.S had some S3C2400 #ifdefs here and I did not want to
encourage anyone to put more architecture dependent stuff here.

BTW you can skip the defconfig bits in your patches. It's probably
better when I regenerate them from time to time myself because
otherwise we'll increase the risk of merge conflicts.

Regards,
  Sascha

-- 
Pengutronix e.K. - Linux Solutions for Science and Industry
-----------------------------------------------------------
Kontakt-Informationen finden Sie im Header dieser Mail oder
auf der Webseite -> http://www.pengutronix.de/impressum/ <-