[U-Boot] Removing the need for boards.cfg

Simon Glass sjg at chromium.org
Fri Aug 8 13:06:03 CEST 2014


Hi Masahiro,

On 1 August 2014 06:22, Masahiro Yamada <yamada.m at jp.panasonic.com> wrote:
> Hi.
>
>
>
> On Fri, 1 Aug 2014 12:48:44 +0100
> Simon Glass <sjg at 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.

My understanding is that if you have a 'select' option in Kconfig then
it will be selected always, but it will still appear in the defconfig.
I think that is the way the kernel works. So there are options that
cannot be changed, and don't appear in the menu, but they are selected
just the same.

>
>
> We can easily do
>
> [1] Choose boards by arch
>
>   Just grep  CONFIG_ARM=y, CONFIG_MIPS=y, CONFIG_SANDBOX=y  in defconfigs

OK.

>
> [2] Choose boards by board name
>
>   It is the file name of defconfigs

Almost, as Wolfgang points out.

>
>
>
>
> 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.
>
>
>
> One possible idea I come up with is to have 'board group' in .buildman file
> so people can build only boards they are interested in.
>
>
> Something like this:
>
> ---------->8---------------
>
> [board-alisa]
> tegra20:  harmony seaboard ventana
> tegra30:  beaver
> tegra114: dalmore
> tegra124: venice2
> tegra:    tegra20 tegra30 tegra114 tegra124
>
> -----------8<---------------
>
>
> With the settings above,
>
>
> "tools/buildman/buildman  tegra20"
> is the same as
> "tools/buildman/buildman   harmony seaboard ventana"
>
>
> "tools/buildman/buildman   tegra"
> is the same as
> "tools/buildman/buildman    tegra20 tegra30 tegra114 tegra124"
> and also the same as
> "tools/buildman/buildman    harmony seaboard ventana beaver dalmore venice2"
>
>
>
> We have to setup  ~/.buildman at the first run.
> (and modify it when adding new boards)
>
> Better to provide a tool to auto-generate .buildman file?

That doesn't sound very different to having a boards.cfg file again.
If we really need it, it seems better to me to have an auto-generated
boards.cfg which is checked into the source tree, at least for now.
When people add boards they can re-run the generation script.

But I'd like to avoid that if possible, so will await your thoughts on
the above Kconfig question.

Regards,
Simon


More information about the U-Boot mailing list