[U-Boot] Kconfig options for several boards

[U-Boot] Kconfig options for several boards

[Linder Pascal]

Hi everyone,


I would like to turn on configurations for several Keymile boards, which are all using the Kirkwood architecture. Now, I do not want to change every defconfig file one after the other. Until now, we have used a common header file, but with the conversion to Kconfig another method has to be elaborated.


While searching in the U-Boot source code, I found two different manners to fulfill our needs:


  *   in arch/arm/mach-kirkwood/Kconfig:

config TARGET_KM_KIRKWOOD
    bool "KM_KIRKWOOD Board"
    select BOARD_LATE_INIT
    select DM
    select DM_SPI
    select DM_SPI_FLASH
    imply CMD_CRAMFS
    imply CMD_DIAG
    imply FS_CRAMFS


  *   in board/keymile/km_arm/Kconfig:

config BOARD_SPECIFIC_OPTIONS # dummy
    def_bool y
    select DM
    select DM_SPI
    select DM_SPI_FLASH

Which one do you guys prefer and for what reasons? Also, I would like to know what the dummy keyword is doing in the second proposition (found that in every usage of BOARD_SPECIFIC_OPTIONS).

Many thanks in advance!


Sincerely,


Pascal Linder

Student Telekommunikation Netzwerke und Sicherheit

Klasse T-3b

[U-Boot] Kconfig options for several boards

[Tom Rini]

On Thu, Jun 06, 2019 at 11:40:08AM +0000, Linder Pascal wrote:

> Hi everyone,
> 
> 
> I would like to turn on configurations for several Keymile boards, which are all using the Kirkwood architecture. Now, I do not want to change every defconfig file one after the other. Until now, we have used a common header file, but with the conversion to Kconfig another method has to be elaborated.
> 
> 
> While searching in the U-Boot source code, I found two different manners to fulfill our needs:
> 
> 
>   *   in arch/arm/mach-kirkwood/Kconfig:
> 
> config TARGET_KM_KIRKWOOD
>     bool "KM_KIRKWOOD Board"
>     select BOARD_LATE_INIT
>     select DM
>     select DM_SPI
>     select DM_SPI_FLASH
>     imply CMD_CRAMFS
>     imply CMD_DIAG
>     imply FS_CRAMFS
> 
> 
>   *   in board/keymile/km_arm/Kconfig:
> 
> config BOARD_SPECIFIC_OPTIONS # dummy
>     def_bool y
>     select DM
>     select DM_SPI
>     select DM_SPI_FLASH
> 
> Which one do you guys prefer and for what reasons? Also, I would like to know what the dummy keyword is doing in the second proposition (found that in every usage of BOARD_SPECIFIC_OPTIONS).

In the second example, "dummy" is just a comment to note that it's not a
really user-visible option.  I'm not sure if (for end-user ability to
change things) it's better or worse than arch/.../Kconfig and doing
options under the TARGET_xxx part or the third option is something like
board/ti/common/Kconfig::TI_COMMON_CMD_OPTIONS where we ask the user if
they want to grab a bunch of other options for a consistent experience.

That said, it really depends on what the options in question are even
about.  If it's "the user should have the following commands enabled"
BOARD_SPECIFIC_OPTIONS and imply seems reasonable.  And maybe we should
make more use of this as an alternative to adding "default y if ..."
statements to various Kconfig files.  If we're talking about "in order
to function at all we need to enable .." that should be select'ed with
the TARGET_xxx option, and perhaps there should be a common symbol
between these platforms so N targets select that rather than N targets
select M options.

Hope that helps!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190607/583ad581/attachment.sig>