From: Tom Rini <trini@ti.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] Removing the need for boards.cfg
Date: Mon, 11 Aug 2014 09:40:18 -0400 [thread overview]
Message-ID: <20140811134018.GS19374@bill-the-cat> (raw)
In-Reply-To: <CAPnjgZ22+PxXRwk_rAA1iG8TzXdZ-2jEKUWsGXL1iAbAFbOR4g@mail.gmail.com>
On Sun, Aug 10, 2014 at 08:22:35PM -0600, Simon Glass wrote:
> Hi Tom,
>
> On 8 August 2014 07:04, Tom Rini <trini@ti.com> wrote:
> > On Fri, Aug 01, 2014 at 12:48:44PM +0100, Simon Glass 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?
> >
> > I wonder (and I haven't had my coffee nor dug into this much more yet)
> > about using say https://github.com/ulfalizer/Kconfiglib to have buildman
> > parse all configs/ and then use that information to build what's been
> > asked (depending on how long the reading+parsing takes). If it's
> > relatively quick, that would be a big argument in favour of dropping
> > MAKEALL.
>
> Well I've had my wine but it seems to parse the Kconfig files rather
> than the #includes that are part of U-Boot's system. Unless I'm
> missing something, we would still need to find out things like the CPU
> type, even with that tool.
Well, my thought was:
foreach Kconfig file, read to build state machine
foreach defconfig, evaluate config, spl/config, tpl/config, store object
Now we can poke those objects for everything with CONFIG_SYS_CPU
whatever, and so forth. Or maybe that all takes longer than what we do
today.
--
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/20140811/7feb2617/attachment.pgp>
prev parent reply other threads:[~2014-08-11 13:40 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
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 [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=20140811134018.GS19374@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