Hi Tom,
On 8 August 2014 05:59, Tom Rini trini@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@jp.panasonic.com 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.
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.
Regards, Simon