在 2022/4/28 8:16, Andre Przywara 写道:
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
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 <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"

Reply via email to