[U-Boot] Incomplete type declarations in arch/Kconfig (U-Boot-2014.10)

[Guilhem Malichier]

Hi Masahiro,

thank you for this very quick answer.
Thanks a lot for clarifying the grammar point too. If I got it correctly, the syntax is valid and meant to be used for non-user-controlled items, which seems to make a lot of sense now :).

Actually the only item I would really need to override in is SYS_CONFIG_NAME, in order to have the custom <board>.h being processed instead of the default one. (I have no intention in fiddling with SYS_ARCH or others.)
But I understand that this kind of extension model doesn't fall in the standard U-Boot usage, so I guess I'll then stick to the updated <board>.h technique...

Thanks again!

	GMal


> -----Message d'origine-----
> De : Masahiro Yamada [mailto:yamada.m at jp.panasonic.com] 
> Envoyé : 2 décembre 2014 04:01
> 
> Hi Guilhem,
> 
> 
> 
> On Tue, 2 Dec 2014 07:03:24 +0000
> Guilhem Malichier <gm at eco-counter.com> wrote:
> 
> > Hi,
> > 
> > I'm quite new to U-Boot as well as to the whole Kconfig system, so this may be a dumb question, in which case please forgive my ignorance.
> > 
> > I noticed that the type declarations of several items in the file arch/Kconfig are actually incomplete, lacking the "prompt" parameter:
> 
> Not incomplete.
> It is grammatically correct and used very often.
> 
> 
> > 
> > config SYS_ARCH
> >      string
> >      help
> >           (...)
> > config SYS_CPU
> >      string
> >      help
> >           (...)
> > etc. (same for SYS_SOC, SYS_VENDOR, SYS_BOARD and SYS_CONFIG_NAME) If 
> > I'm not mistaken, the string type declaration in Kconfig is supposed to look like either of the following:
> >
> > string "something"
> > or
> > 
> > string
> > 
> > prompt "something"
> 
> in case the option is supposed to be configured by users.
> 
> 
> 
> > 
> > In this case, again if I'm not mistaken, these incomplete declarations seem to prevent the items from being "created" at this step, thus preventing any possibility of overriding the default values directly in a _defconfig file.
> > So my question is: is this intentional (in which case I would probably recommend using comments for that purpose instead of incomplete declarations)? Or is this a bug (in which case I would be happy to submit a fix simply adding the prompt strings)?
> 
> It is intentional.
> 
> SYS_ARCH, SYS_CPU, ... should not directly touched.
> They should always be set to a combination of correct values.
> 
> For example, if you choose CONFIG_ARM in the architecture select menu, SYS_ARCH is automatically set to "arm".
> 
> 
> > 
> > Here is a bit of context if need be: I'm trying to find a way to compile a variant of U-Boot for an existing board (basically just overriding a few lines in <board>.h), but I would like to do it without _modifying_ any file in the U-Boot distribution, nor fiddling with .config, but rather by only adding files (namely configs/<myvariant>_defconfig, and configs/<board-myvariant>.h), so that there will be nothing to merge to support later U-Boot versions.
> 
> 
> Having your own configs/*_defconfig is easy, just add it, but I have no idea how to add your own include/configs/*.h without modifying any file.
> 
> 
> 
> > I've been struggling with this today, assuming that overriding CONFIG_SYS_CONFIG_NAME in my _defconfig would be enough (as it is for CONFIG_SYS_EXTRA_OPTIONS)... but I couldn't get it to work, as only the default value got from arch/<arch>/<board>/Kconfig was used, and I couldn't find any way to add my configuration without actually modifying something in U-Boot's core (either some Kconfig files, or the original <board>.h) or manually editing the generated .config.
> > 
> > This was until I noticed that type declaration problem. As soon as I added the prompt parameters, I was able to successfully build a .config with the desired CONFIG_SYS values, and then compile everything as expected.
> > Hence the aforementioned question...
> 
> We(I) have not taken such a usage into account.
> 
> 
> 
> Best Regards
> Masahiro Yamada