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

Sascha Hauer s.hauer at pengutronix.de
Fri May 9 17:12:32 CEST 2008


On Fri, May 09, 2008 at 07:08:12AM -0500, Menon, Nishanth wrote:
> 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.
> 

OK, can we agree on the following then?

config MACH_DO_LOWLEVEL_INIT
	bool "run machine lowlevel init"
	depends on MACH_HAS_LOWLEVEL_INIT
	default y

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

You're right.

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




More information about the U-Boot mailing list