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

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

[qianfanguijin]

From: qianfan Zhao <qianfanguijin@163.com>

The board is not configurable if use sunxi soc. Add Kconfig items and
make custom board available.

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

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

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

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

[qianfan]

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

Re: [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@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/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@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"
> 

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

[qianfan]

在 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/Documentation/devicetree/bindings/watchdog/gpio-wdt.txt
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"