[PATCH v1] sunxi: Make SYS_VENDOR, SYS_BOARD, SYS_CONFIG_NAME configurable

[Andre Przywara]

On Wed, 27 Apr 2022 08:42:09 +0800
qianfan <qianfanguijin at 163.com> wrote:

Hi,

> 在 2022/4/26 20:49, Andre Przywara 写道:
> > On Thu, 21 Apr 2022 11:32:11 +0800
> > qianfanguijin at 163.com wrote:
> >
> > Hi,
> >
> >> From: qianfan Zhao <qianfanguijin at 163.com>
> >>
> >> The board is not configurable if use sunxi soc. Add Kconfig items and
> >> make custom board available.
> > What problem does that solve?
> > And apart from that, I am afraid this is broken in several ways:
> > - The actual definition of those symbols is in arch/Kconfig. Having those
> > "config SYS_*" lines here is just to provide the various default values.
> > And changes to the definition should go there (and will be NAKed there).
> > - Those options are NOT meant to be user changeable, that's why their
> > original definition doesn't provide a prompt. The value of those options
> > have implications to the build system, so by just putting *something* in
> > here you will break the build. So any changes to those values would
> > require code and build system changes as well.
> > - The mainline Allwinner port is a bit special (and not in the worst
> > way!), in that it really doesn't use the generic U-Boot notion of "board
> > vendor code", for instance. So every board uses board/sunxi, despite the
>
> Yes, this is the problem I want to slove. All sunxi based board use 
> board/sunxi by default, I don't think it's a good way to adding other
> custom code to board/sunxi.c, so I want create another board and select it
> in Kconfig.

Well, as I hinted above, there really shouldn't be random custom code
for one particular board. There should be a DT based driver for your
hardware, and generic code to handle your tasks.

> > actual board manufacturer. And this makes a lot of sense, since the vast
> > majority of the code is really just SoC dependent, and the differences
> > between boards should be covered by the DT. There are some board specific
> It's better if the dependence can convert to dt, but not all of them.
> On my board there has an gpio watchdog

Have you checked drivers/watchdog/gpio_wdt.c? The DT binding in the
Linux kernel tree explains the options. It looks like the U-Boot driver
could use an update to handle everything the binding promises.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/watchdog/gpio-wdt.txt

> and spi lcd. I need add somethings to toggle watchdog,

For the watchdog you should be good with that UCLASS_WDT driver, once
this is enabled in your _defconfig, and the DT node is in, it should
work out of the box.

> prepare spi lcd

There are drivers for some SPI display chips in drivers/video/Kconfig,
maybe one of them can drive your hardware? If not, it would be good to
add some driver for it.

> and draw splash.

I don't know the exact procedure from the top of my head, but a splash
screen is a standard U-Boot feature, with a driver in place it should
work by just providing a bitmap.

If you need to trigger something custom for your board, put that into
your environment, either in a stored version, or through CONFIG symbols.

If you have something very simple (like flipping a GPIO), which is hard
to express otherwise, you could try to add this somewhere in
board/sunxi/board.c, and control this with a Kconfig symbol.
Alternatively you could use the built-in gpio command through some
custom boot script, for instance.

> So I want create a board dir and select it in Kconfig.

So I am very much against a per-board dir, especially given that we
survived with 160 boards without one so far. Having a SoC dir could
actually prove useful, but that won't help in your case.

If you show me more of your code, I could possibly direct you more
specifically.

Cheers,
Andre

> > hacks, which we cover by config options, like CONFIG_PINE64_DT_SELECTION.
> >
> > So I am afraid this is not going anywhere.
> > If this is solving some problem for you, please describe the problem here,
> > and I am sure we will find a much better solution.
> > Adding support for a new board (with the SoC already supported) would just
> > require a defconfig and the .dts file.
> >
> > Cheers,
> > Andre
> >
> >> Signed-off-by: qianfan Zhao <qianfanguijin at 163.com>
> >> ---
> >>   arch/arm/mach-sunxi/Kconfig | 17 +++++++++++++++++
> >>   1 file changed, 17 insertions(+)
> >>
> >> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> >> index 2c18cf02d1..03460870db 100644
> >> --- a/arch/arm/mach-sunxi/Kconfig
> >> +++ b/arch/arm/mach-sunxi/Kconfig
> >> @@ -598,6 +598,7 @@ config SYS_CLK_FREQ
> >>   	default 1008000000 if MACH_SUN50I_H616
> >>   
> >>   config SYS_CONFIG_NAME
> >> +	string "Board configuration name"
> >>   	default "sun4i" if MACH_SUN4I
> >>   	default "sun5i" if MACH_SUN5I
> >>   	default "sun6i" if MACH_SUN6I
> >> @@ -607,9 +608,25 @@ config SYS_CONFIG_NAME
> >>   	default "sun50i" if MACH_SUN50I
> >>   	default "sun50i" if MACH_SUN50I_H6
> >>   	default "sun50i" if MACH_SUN50I_H616
> >> +	help
> >> +	  This option contains information about board configuration name.
> >> +	  Based on this option include/configs/<CONFIG_SYS_CONFIG_NAME>.h header
> >> +	  will be used for board configuration.
> >>   
> >>   config SYS_BOARD
> >> +	string "Board name"
> >>   	default "sunxi"
> >> +	help
> >> +	  This option contains information about board name.
> >> +	  Based on this option board/<CONFIG_SYS_VENDOR>/<CONFIG_SYS_BOARD> will
> >> +	  be used.
> >> +
> >> +config SYS_VENDOR
> >> +	string "Vendor name"
> >> +	help
> >> +	  This option contains information about board name.
> >> +	  Based on this option board/<CONFIG_SYS_VENDOR>/<CONFIG_SYS_BOARD> will
> >> +	  be used.
> >>   
> >>   config SYS_SOC
> >>   	default "sunxi"
>