[U-Boot] [RFC PATCH] sunxi: support board-specific configuration options

Bernhard Nortmann bernhard.nortmann at web.de
Mon Aug 24 11:18:26 CEST 2015


Hi Hans!

I agree that picking user-defined LEDs as an example might not have been the
best choice. Stuff like that should probably go into more 'generic' 
frameworks,
e.g. a place to deal with those would be to define them in the device 
tree and
have a proper driver handling them.

Unfortunately I can't think of another prominent/convincing example for this
kind of tweaking... (maybe board-specific hardware quirks?)

IIRC, I started the whole thing while trying to incorporate some 'personal'
config changes (like support for the "led" command, a modified "bootcmd"
and netconsole activation). The difficulty I encountered with that was that
while the build system seems to accept certain options, it would happily
ignore other CONFIG_* settings from the *_defconfig (anything not in
Kconfig?), which led me to take the ".h include" route.

Many other boards seem to use a similar approach, often with quite
minimal .h files (e.g. include/configs/xilinx-ppc440.h or rpi.h)
I understand that this might be "old" U-Boot configuration style,
and thus deprecated - that's certainly a valid objection.

Regards, B. Nortmann


Am 22.08.2015 16:02, schrieb Hans de Goede:
>
> We want to move away from using CONFIG_SYS_EXTRA_OPTIONS, not start using
> more of them.
>
> The proper way to deal with this would be to allow defining one or more
> LED gpio pins in Kconfig, like e.g. the USB?_VBUS_PIN config options
> in board/sunxi/Kconfig, and then modify the generic code paths so that
> these will be used when set.
>
> This way we get led support for all boards in one go (once all the
> defconfig-s are updated to set the gpio pins), and we do not end up
> with board specific code.
>
> Regards,
>
> Hans



More information about the U-Boot mailing list