在 2022/4/26 20:49, Andre Przywara 写道:

On Thu, 21 Apr 2022 11:32:11 +0800 qianfanguijin@163.com wrote:

Hi,

...

From: qianfan Zhao qianfanguijin@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.

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 and spi lcd. I need add somethings to toggle watchdog, prepare spi lcd and draw splash.

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

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@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"

在 2022/4/28 8:16, Andre Przywara 写道:

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

Hi,

...

在 2022/4/26 20:49, Andre Przywara 写道:

...

On Thu, 21 Apr 2022 11:32:11 +0800 qianfanguijin@163.com wrote:

Hi,

...

From: qianfan Zhao qianfanguijin@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/Docu...

Now I adding the gpio watchdog in BSP, enable CONFIG_HW_WATCHDOG option.

#if defined(CONFIG_HW_WATCHDOG) void hw_watchdog_reset(void) {     gpio_request(WATCHDOG_TRIGGER_GPIO, "watchdog_trigger");     gpio_direction_output(WATCHDOG_TRIGGER_GPIO, 1);     gpio_direction_output(WATCHDOG_TRIGGER_GPIO, 0);

#ifdef WATCHDOG_ENABLE_GPIO     gpio_request(WATCHDOG_ENABLE_GPIO, "watchdog_enable");     gpio_direction_output(WATCHDOG_ENABLE_GPIO, WATCHDOG_ENABLE_VALUE); #endif }

And I will think how to move those to dm_watchdog. The gpio should be done in pinctrl.

...

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.

Yes, I had implement the driver of spi lcd on drivers/video.

...

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.

The u-boot provide a way named SPLASH_SCREEN to show splash.  So I adding those code.

if we move this to the common sunxi board, we need add so much Kconfig options.

#ifdef CONFIG_SPLASH_SCREEN static struct splash_location default_splash_locations[] = {     {         .name        = "mmc1",         .storage    = SPLASH_STORAGE_MMC,         .flags        = SPLASH_STORAGE_RAW,         .devpart    = "logo",     }, };

int splash_screen_prepare(void) {     return splash_source_load(default_splash_locations,                   ARRAY_SIZE(default_splash_locations)); } #endif

Also the spi lcd on my board is very small, u-boot's default behaiver of version is not suit for me. So I disable CONFIG_HIDE_LOGO_VERSION and show git string when board_late_init:

static void lcdputs_git_version_string(void) {     /* plain_version format: 2022.01-rc1-00189-g66896b61c6-dirty */     char *p, plain_version[] = PLAIN_VERSION;     int dirty = 0, col = 16;     char scripts[128];

p = strrchr(plain_version, '-');     if (p && !strcmp(p, "-dirty")) {         *p = '\0'; /* remove "-dirty" string */         dirty = 1;         col -= 2; /* reserved space for ".d" */         p = strrchr(plain_version, '-');     }

if (p && !strncmp(p, "-g", 2) && strlen(p) == strlen("-g66896b61c6")) {         snprintf(scripts, sizeof(scripts),              "setcurs %d 19; lcdputs %s%s;",              col,              p + 2, /* skip "-g" */              dirty ? ".d" : " ");

run_command(scripts, 0);     } }

int board_late_init(void) { #ifdef CONFIG_USB_ETHER     usb_ether_init(); #endif

lcdputs_git_version_string();

return 0; }

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.

I look forward to your ideas.

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@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"