From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Glass Date: Sun, 1 Jun 2014 22:30:50 -0600 Subject: [U-Boot] [RFC] Two sets of experimental Kconfig patches In-Reply-To: <20140527163250.4E51.AA925319@jp.panasonic.com> References: <20140527163250.4E51.AA925319@jp.panasonic.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Masahiro, On 27 May 2014 01:32, Masahiro Yamada wrote: > Hi. > > I've posted two sets of Kconfig RFC patches: "RFCv2a" and "RFCv2b" > > The difference from v1 is that > Full U-boot image, SPL and TPL share a single defconfig > and "make config" is done in one-shot. > > This approach dates back to Simon's following comments: > > On Thu, 20 Mar 2014 19:15:30 -0700 > Simon Glass wrote: > >> > But, our situation is a little more complicated. >> > We need to generate 3 images at most: main image, SPL and TPL. >> > And each of them can have a different set of CONFIGs. >> > >> > For example, we can describe a board header file like this: >> > >> > #if defined(CONFIG_TPL_BUILD) >> > # define CONFIG_FOO 100 >> > #elif defined(CONFIG_SPL_BUILD) >> > # define CONFIG_FOO 50 >> > #else >> > # define CONFIG_FOO 10 >> > # define CONFIG_BAR >> > #endif >> >> I wonder if we should drop this, and require that all have the same >> options? That would involve requiring that board config files are not >> permitted to use #ifdef CONFIG_SPL or #ifdef CONFIG_TPL. >> >> Does that seem like a bad restriction? The advantage is that we only >> need one defconfig for each board. It seems to me that things are >> going to get really painful if we have three different configs. >> >> Of course, this doesn't preclude #ifdefs in the Makefiles or actual >> source code, but we already have SPL-specific feature options. >> >> I'm not 100% clear on the constraints here. > > > In my opition, this approach might work, but will be painful. > > Anyway I just wanted to see what would happen > if multiple binary images had a single defconfig in common. > > We will have to duplicate many configs with CONFIG_SPL_ > and CONFIG_TPL_ prefixes. > > For example, > - CONFIG_SYS_TEXT_BASE (text base for the full image) > - CONFIG_SPL_TEXT_BASE (text base for SPL) > - CONFIG_TPL_TEXT_BASE (text base for TPL) > > - CONFIG_OF_CONTROL (enables OF control for the full image) > - CONFIG_SPL_OF_CONTROL (enables OF control for SPL) > - CONFIG_TPL_OF_CONTROL (enables OF control for TPL) > > Probably I will not adopt this approach, but your comments > are welcome. > > I have been thinking about this a lot, but it isn't 100% clear to me. While I agree that duplicating the CONFIGs is bad, in fact the opposite of what I was getting at, I do feel that things like CONFIG_TEGRA20 need to be set in one place. We don't want the SPL/TPL config to be changing things that make no sense given the board that is selected. It doesn't make sense to have an SPL for Tegra and a TPL for MX6. Similar to what Tom was saying I feel that there will come a time when the difference between U-Boot and SPL is just the options that are enabled - the code paths will be the same. For example, I did a CONFIG_CMD series which removed all commands from U-Boot and cut the size to <50KB. OK that is not SPL size, but I can see a point where they will merge. In that case we certainly don't want the option that you list above - instead we want CONFIG_OF_CONTROL to mean the same thing for U-Boot and SPL. Perhaps it will help if we can have options like: make menuconfig_main make menuconfig_spl make menuconfig_tpl to avoid chaining between configs? That was my main concern with series 1. [snip] It would be great if we could make a decision on this and merge it soon. To me the ARCH issue is minor but FWIW I think we should try to avoid needing ARCH= on the command line. So long as we get the general direction right we can make changes later. To me the general direction is towards getting rid of the special-case SPL code and SPL options. Anyone else have comments? Regards, Simon