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