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

[Menon, Nishanth]

Sascha,
> -----Original Message-----
> From: Sascha Hauer [mailto:s.hauer at pengutronix.de]
> Sent: Friday, May 09, 2008 3:08 AM
> To: Menon, Nishanth
> Cc: u-boot-users at lists.sourceforge.net
> Subject: Re: [Patch] U-Boot-V2: Replace CONFIG_SKIP_LOWLEVEL_INIT withCONFIG_MACH_HAS_INIT_LOWLEVEL
>
> 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. 

You are missing the requirement of having to do a second level boot. I may choose not to enable board level initialization in a specific configuration for the same platform. The requirement I have in OMAP is this: boot up tiny u-boot (very minimal functionality, which needs to be less than 32K) which does SDRAM init (among other things), load the normal u-boot (around 200-400K) from UART, USB, NAND or ONENAND to SDRAM, and give control to it. In the "Normal functionality" U-Boot I'd not want to do a SDRAM and additional arch and board initialization - something that is redundant as it is already done by the tiny u-boot. Now I can also have a configuration for U-Boot booting from NOR. In that case, I'd want SDRAM initialization to be done. In such a case, the user should have the flexibility to be able to enable/disable board low level initialization while creating multiple configurations. All of these configurations are for the same board and same architecture.

> 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).
Yep. will fix it.

> 
> 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.

It may not just be SDRAM initialization that I'd choose to do in a board level initialization. This could be a sizeable code in some cases. There is no need to duplicate functionality (in the case of two stage boot) if we can provide a method for a board developer to isolate his/her code out in the required configurations.

> 
> 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.
I do not agree to it. ARCH_INIT_LOWLEVEL makes complete sense in terms of a config option. Why would we want to force 50 odd ARM based developers to write dummy functions when just one or two folks need it? On MACH_INIT_LOWLEVEL I have explained above.

> 
> 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.
I provided it to handle the inverted case of SKIP_LOWLEVEL Vs HAS_LOWLEVEL. Just trying to be helpful ;)..

Regards,
Nishanth Menon