From: Tom Rini <trini@ti.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] Removing the need for boards.cfg
Date: Fri, 1 Aug 2014 09:38:03 -0400 [thread overview]
Message-ID: <20140801133803.GW19374@bill-the-cat> (raw)
In-Reply-To: <20140801212241.D536.AA925319@jp.panasonic.com>
On Fri, Aug 01, 2014 at 09:22:42PM +0900, Masahiro Yamada wrote:
> Hi.
>
>
>
> On Fri, 1 Aug 2014 12:48:44 +0100
> Simon Glass <sjg@chromium.org> wrote:
>
> > Hi,
> >
> > At present, as a work-around, we generate boards.cfg if needed. This
> > is quite a slow process since each board config must be fully
> > processed.
> >
> > What can we do to improve this? We only need a small number of options
> > in order to start buildman - things like CONFIG_SYS_ARCH,
> > CONFIG_SYS_CPU, etc.
> >
> > I wonder if we could run a script which adds these to the defconfigs
> > for each board and then apply a patch to mainline? Would that require
> > removing the options from the config.h files? Or could we do that
> > later as a separate step?
> >
>
>
> We cannot add CONFIG_SYS_ARCH, CONFIG_SYS_CPU, etc. to defconfigs
> because they are not user-editable options.
> (They must be always selected in correct combination.)
>
> This is already discussed when I posted the RFC version of the Kconfig series.
>
>
> We can easily do
>
> [1] Choose boards by arch
>
> Just grep CONFIG_ARM=y, CONFIG_MIPS=y, CONFIG_SANDBOX=y in defconfigs
>
> [2] Choose boards by board name
>
> It is the file name of defconfigs
>
>
>
>
> My question is, do we really need to choose by CPU, Vendor, SoC ?
> I know they are useful.
> For ex. nvidia developers probably want to build only Tegra boards.
For me, I don't see CPU or Vendor as super important but SoC is. I'll
often be doing some TI work for say am335x or am43xx and be checking
over those two board configs but once I'm done (or nearing done) I need
to build for SoC==am33xx to catch all of the other vendors that have
boards in the family.
--
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/20140801/879f1d4a/attachment.pgp>
next prev parent reply other threads:[~2014-08-01 13:38 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-01 11:48 [U-Boot] Removing the need for boards.cfg Simon Glass
2014-08-01 12:22 ` Masahiro Yamada
2014-08-01 13:38 ` Tom Rini [this message]
2014-08-01 13:53 ` Masahiro Yamada
2014-08-01 18:31 ` Wolfgang Denk
2014-08-04 20:45 ` Simon Glass
2014-08-04 18:58 ` York Sun
2014-08-05 1:22 ` Masahiro Yamada
2014-08-05 1:30 ` York Sun
2014-08-07 20:52 ` York Sun
2014-08-07 20:57 ` Jeroen Hofstee
2014-08-07 21:04 ` York Sun
2014-08-08 11:06 ` Simon Glass
2014-08-08 11:59 ` Tom Rini
2014-08-11 2:15 ` Simon Glass
2014-08-11 2:16 ` Simon Glass
2014-08-11 13:37 ` Tom Rini
2014-08-11 18:17 ` Simon Glass
2014-08-08 13:04 ` Tom Rini
2014-08-11 2:22 ` Simon Glass
2014-08-11 13:40 ` Tom Rini
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=20140801133803.GW19374@bill-the-cat \
--to=trini@ti.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox