[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