[PATCH v1] sunxi: Make SYS_VENDOR, SYS_BOARD, SYS_CONFIG_NAME configurable
qianfan
qianfanguijin at 163.com
Thu Apr 28 03:41:41 CEST 2022
在 2022/4/28 8:16, 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
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 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"
More information about the U-Boot
mailing list