[U-Boot] [PATCH 03/11] kconfig: add board Kconfig and defconfig files

[Tom Rini]

Wading in here later than I had wanted to, sorry.

On Mon, Apr 28, 2014 at 06:39:33PM +0900, Masahiro Yamada wrote:
> On Thu, 24 Apr 2014 14:36:33 -0600
> Stephen Warren <swarren at wwwdotorg.org> wrote:
> > On 04/23/2014 11:04 PM, Masahiro Yamada wrote:
> > > This commit adds
> > >  - arch/*/Kconfig: provide a menu to select target boards
> > >  - board/*/Kconfig: set CONFIG macros to the appropriate values
> > >         for each board
> > >  - configs/*_defconfig: default setting of each board
[snip]
> > Perhaps we can change the command-line used to build U-Boot, rather than
> > shoe-horning U-Boot's Kconfig usage to fit that current limitation.
> 
> I am afraid something like
>  make ARCH=arm seaboard_defconfig
>  make ARCH=arm  CROSS_COMPILE=arm-linux-gnueabi-
> is annoying for some users.
> 
> This item was an open discussion in the RFC version, but
> Simon was the only person who replyed this question.
> 
> See
> https://www.mail-archive.com/u-boot@lists.denx.de/msg134502.html
> "How ARCH should be given?"   section.
> 
> 
> Of course, this part is changable if other people accept
> Linux's ARCH=${ARCH} way.
> 
> Comments are still welcome.

To start with, I think we should try and keep things the way they are
and not have to specify ARCH at least.

> > > Besides, we must configure boards for SPL and TPL too
> > > if they are supported.
> > > For those boards, defconfig files with the same name are placed
> > > in configs/spl/, configs/tpl/ directories.
> > 
> > I really don't think we should have separate defconfig files for SPL/TPL/...
> > 
> > I don't think that the approach of a single huge Kconfig file (albeit
> > split into multiple included files per architecture and board) is going
> > to work; it requires a massive amount of irrelevant Kconfig to be
> > parsed, whereas scanning boards.cfg is a much simpler
> > scan-until-you-find-a-matching-line approach.
> > 
> > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > 
> > > +config TARGET_SEABOARD
> > > +	bool "Support seaboard"
> > 
> > If U-Boot is built like:
> > 
> > make seaboard_config
> > make
> > 
> > ... then I'm not sure why there is a Kconfig option for TARGET_SEABAORD.
> > Are you intending for the .config file to dictate that we're building
> > for Seaboard? If so, then presumably the make commands above will no
> > longer be valid, and if we can change that aspect, why couldn't we
> > require the user to add the architecture to the build command-line, just
> > like the kernel does?

While all of us kernel folks have well trained our fingers to add in
ARCH= when building something other than x86 (unless of course we're
doing native kernel compiles, which are a handy stress test of the
system at least), that the kernel happily tries to build for x86
generally isn't the nicest thing ever.  Which is why we've all trained
ourselves to pass in ARCH. </end old guy rant>

> TARGET_SEABOARD is used just for selecting hard-coded
> CONFIG_SYS_CPU="armv7"    (CONFIG_SYS_CPU="arm720t" in spl/.config)
> CONFIG_SYS_BOARD="seaboard"
> CONFIG_SYS_VENDOR="nvidia"
> etc.
> 
> You said adding non-user-editable CONFIG to defconfig is odd.
> So, this patch selects a board with CONFIG_TARGET_*  and then
> selects hard-coded macros.

So, here's my question / hope.  We can incrementally move from what this
patch provides us today of strict but not as flexible set of Kconfig
choices and options to something more flexible later.  For example, this
converts am335x_evm_uart[12345] directly but I would like to just drop
them all and make CONS_INDEX (the only thing different between _uartN
and am335x_evm itself) be a choice the user selects.  That's not
something I expect to be done at the start of the series of course.

[snip]
> > Should SPL/non-SPL be two build targets that get built when you ask to
> > build for Seaboard, not two entirely unrelated defconfig files?
> 
> This is another item worth discussion.
> 
> The idea in my mind is to not treat SPL and TPL as special cases.
> (This is an idea proposed by Simon.)
> 
> I was thinking of handling Non-SPL, SPL, TPL as generic images.
> 
> Currently, C sources and Makefiles are really dirty because of
> ifdef CONFIG_SPL_BUILD everywhere.
> 
> But, roughly, the difference among them is how many CONFIG_ macros
> are enabled.
> 
> Non-SPL:  enable hush command line, many useful commands,
>          many drivers, net work feature etc. But the image size is big.
> 
> SPL: disable hush command line & all commands
>        enable only some drivers enough for loading another image.
>        The image size is small.
> 
> So, in future, many user ediatable settings will be moved to Kconfig.
> And then, 
> 
> config/seaboard_defconfig will include
> CONFIG_SYS_HUSH_PARSER=y
> CONFIG_CMD_FOO=y
> CONFIG_CMD_BAR=y
> ...
> 
> but config/spl/seaboard_defconfig will disable most of them.
> 
> 
> But, if people don't like this,
> I can change this part as only one defconfig per board
> in the next version.
> (Instead, we may lose flexibility to some extent
> because SPL and non-SPL will share the same defconfig.)

So this I believe answers what I was hoping which is that yes, down the
line more things will be questions and less things selected, which means
defconfig are more about providing config options.

And then yes, we need to re-evaluate what we do for SPL/TPL and see if
really we can't just handle things with a user-selected CONFIG_SPL/TPL
(for the just very different parts) and perhaps decouple these parts of
the build.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140516/12470bd5/attachment.pgp>