On Wed, 27 Apr 2022 08:42:09 +0800 qianfan <qianfangui...@163.com> wrote:
Hi, > 在 2022/4/26 20:49, Andre Przywara 写道: > > On Thu, 21 Apr 2022 11:32:11 +0800 > > qianfangui...@163.com wrote: > > > > Hi, > > > >> From: qianfan Zhao <qianfangui...@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 <qianfangui...@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" >
