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

[Simon Glass]

+Masahiro

Hi Tom,

On 11 August 2014 07:37, Tom Rini <trini at ti.com> wrote:
> On Sun, Aug 10, 2014 at 08:16:43PM -0600, Simon Glass wrote:
>> Hi Tom,
>>
>> On 8 August 2014 05:59, Tom Rini <trini at ti.com> wrote:
>> > On Fri, Aug 08, 2014 at 05:06:03AM -0600, Simon Glass wrote:
>> >> 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.
>> >
>> > Maybe we came up with the wrong answer during RFC on Kconfig then.  It's
>> > good if selecting say CONFIG_TARGET_AM335X_EVM results in
>> > CONFIG_SYS_ARCH="arm", CONFIG_SYS_CPU="armv7", etc.
>> >
>> > I _think_ the problem here is what I ran into with doing CONS_INDEX
>> > patches.  You cannot do 'select SYS_CPU="armv7"'.  So we would instead
>> > need to get rid of CONFIG_SYS_CPU and instead do CONFIG_SYS_CPU_ARMV7,
>> > etc, etc.
>>
>> Well I think we should run this one to ground first - if a 'select'
>> item doesn't appear in Kconfig then I think we have a bit of a
>> problem. Will await Masahiro's thoughts.
>
> It's not that we can't select, it's:
> board/ti/am335x/Kconfig:27:warning: 'CONS_INDEX' has wrong type.
> 'select' only accept arguments of boolean and tristate type
>
> So we'd have to modify Kconfig to accept int/hex/string as well so we
> could do:
> config SYS_CPU
>         default "armv7" if SOCA || SOCB || ...
>         default "ppc4xx' if SOCC || SOCD || ..
>
> And that also seems like a conflict-generating nightmare down the line
> too.

We currently have this in the Kconfig for snow:

if TARGET_SNOW

config SYS_CPU
string
default "armv7"

config SYS_BOARD
string
default "smdk5250"

config SYS_VENDOR
string
default "samsung"

config SYS_SOC
string
default "exynos"

config SYS_CONFIG_NAME
string
default "snow"

endif


so now I'm wondering why we can't just pick this up somehow. Sure we
might need to read all the Kconfig files (using the library you
mentioned) but then we could perhaps very quickly work out the CPU,
BOARD, etc. based on the target name. It makes me wonder if
genboardscfg.py could be a lot more efficient?

Regards,
Simon