* [PATCH v1] sunxi: Make SYS_VENDOR, SYS_BOARD, SYS_CONFIG_NAME configurable @ 2022-04-21 3:32 qianfanguijin 2022-04-26 12:49 ` Andre Przywara 0 siblings, 1 reply; 5+ messages in thread From: qianfanguijin @ 2022-04-21 3:32 UTC (permalink / raw) To: u-boot; +Cc: Jagan Teki, Andre Przywara, qianfan Zhao 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 ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH v1] sunxi: Make SYS_VENDOR, SYS_BOARD, SYS_CONFIG_NAME configurable 2022-04-21 3:32 [PATCH v1] sunxi: Make SYS_VENDOR, SYS_BOARD, SYS_CONFIG_NAME configurable qianfanguijin @ 2022-04-26 12:49 ` Andre Przywara 2022-04-27 0:42 ` qianfan 0 siblings, 1 reply; 5+ messages in thread From: Andre Przywara @ 2022-04-26 12:49 UTC (permalink / raw) To: qianfanguijin; +Cc: u-boot, Jagan Teki 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" ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v1] sunxi: Make SYS_VENDOR, SYS_BOARD, SYS_CONFIG_NAME configurable 2022-04-26 12:49 ` Andre Przywara @ 2022-04-27 0:42 ` qianfan 2022-04-28 0:16 ` Andre Przywara 0 siblings, 1 reply; 5+ messages in thread From: qianfan @ 2022-04-27 0:42 UTC (permalink / raw) To: Andre Przywara; +Cc: u-boot, Jagan Teki 在 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" ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v1] sunxi: Make SYS_VENDOR, SYS_BOARD, SYS_CONFIG_NAME configurable 2022-04-27 0:42 ` qianfan @ 2022-04-28 0:16 ` Andre Przywara 2022-04-28 1:41 ` qianfan 0 siblings, 1 reply; 5+ messages in thread From: Andre Przywara @ 2022-04-28 0:16 UTC (permalink / raw) To: qianfan; +Cc: u-boot, Jagan Teki 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" > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v1] sunxi: Make SYS_VENDOR, SYS_BOARD, SYS_CONFIG_NAME configurable 2022-04-28 0:16 ` Andre Przywara @ 2022-04-28 1:41 ` qianfan 0 siblings, 0 replies; 5+ messages in thread From: qianfan @ 2022-04-28 1:41 UTC (permalink / raw) To: Andre Przywara; +Cc: u-boot, Jagan Teki 在 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" ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2022-04-28 1:42 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-04-21 3:32 [PATCH v1] sunxi: Make SYS_VENDOR, SYS_BOARD, SYS_CONFIG_NAME configurable qianfanguijin 2022-04-26 12:49 ` Andre Przywara 2022-04-27 0:42 ` qianfan 2022-04-28 0:16 ` Andre Przywara 2022-04-28 1:41 ` qianfan
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.