Sascha,
-----Original Message----- From: Sascha Hauer [mailto:s.hauer@pengutronix.de] Sent: Friday, May 09, 2008 3:08 AM To: Menon, Nishanth Cc: u-boot-users@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