All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: Masahiro Yamada <yamada.m@jp.panasonic.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC] Two sets of experimental Kconfig patches
Date: Tue, 24 Jun 2014 13:55:51 +0900	[thread overview]
Message-ID: <20140624135550.935D.AA925319@jp.panasonic.com> (raw)
In-Reply-To: <CAPnjgZ3oXLt1VRHjBAxRd7=z1W_kFDH7X9X1GA0QqSWUHO5KTA@mail.gmail.com>

Hi Simon,

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

I agree.
But I think, in some cases,  it makes sense to build SPL only.
I want to drop Falcon boot as a special case.

In my rough view:
 -  <board>_defconfig    :  Normal boot sequence
 -  <board>_defconfig + <board>_spl_defconfig  :   SPL boot sequence
 -  <board>_spl_defconfig : Falcon boot


> 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

I have posted v3.

It is possible in v3.

make menuconfig         -->  edit  .config
make spl:menuconfig    -->  edit  spl/.config
make tpl:menuconfig    -->  edit  tpl/.config
make qpl:menuconfig   -->   edit  qpl/.config
etc.

Syntax is 
make  <output_dir>:<config_command>




Best Regards
Masahiro Yamada

      reply	other threads:[~2014-06-24  4:55 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-27  7:32 [U-Boot] [RFC] Two sets of experimental Kconfig patches Masahiro Yamada
2014-05-30 17:24 ` Tom Rini
2014-06-24 10:24   ` Masahiro Yamada
2014-06-02  4:30 ` Simon Glass
2014-06-24  4:55   ` Masahiro Yamada [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140624135550.935D.AA925319@jp.panasonic.com \
    --to=yamada.m@jp.panasonic.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.