[PATCH v2 6/9] spacemit: k1: Add multiple device tree support

Guodong Xu guodong at riscstar.com
Tue May 26 15:24:18 CEST 2026


Hi, Aurelien

Thanks for the review.

On Mon, May 25, 2026 at 5:26 AM Aurelien Jarno <aurelien at aurel32.net> wrote:
>
> Hi,
>
> On 2026-05-20 06:45, Guodong Xu wrote:
> > Enable multiple DTB support in the FIT image for the Spacemit K1 SoC,
> > allowing a single U-Boot binary to support different board variants.
> >
> > @@ -363,3 +360,32 @@ u32 spl_boot_device(void)
> >  void spl_board_init(void)
> >  {
> >  }
> > +
> > +int board_fit_config_name_match(const char *name)
> > +{
> > +     char fdt_name[I2C_BUF_SIZE];
> > +     int i;
> > +
> > +     memset(fdt_name, 0, I2C_BUF_SIZE);
> > +     if (!strncmp(product_name, "k1-x_", 5)) {
> > +             snprintf(fdt_name, I2C_BUF_SIZE, "%s-%s", "k1",
> > +                      &product_name[5]);
> > +     }
>
> I wonder if any normalisation would be better in board_init_f() as
> board_fit_config_name_match() is basically called for each possible
> board. Same for the tolower() loop below.

Agree, will move both into board_init_f() in v3.

>
> > +     if (fdt_name[0] == '\0') {
> > +             /* set default board name */
> > +             sprintf(fdt_name, "k1-musepi-pro");
> > +     }
>
> I am not sure k1-musepi-pro is a good default. The experience is that
> the Banana-Pi F3 (known as k1-x_deb1 in the vendor code) doesn't  have a
> product name defined in the TLV EEPROM and thus should probably be the
> default.

Thank you for this observation. Agree.

Will change the default to spacemit/k1-bananapi-f3 in v3 so a
BPI-F3 with no TLV product name falls through to the correct DTB.

>
> > +     for (i = 0; i < I2C_BUF_SIZE; i++) {
> > +             if (fdt_name[i] == '\0')
> > +                     break;
> > +             fdt_name[i] = tolower(fdt_name[i]);
> > +     }
> > +     if (!strcmp(name, fdt_name))
> > +             return 0;
>
> I am not sure that all the vendor product names will match the linux dtb
> names, so maybe just using a table to do the mapping would be better.
> Anyway, as long as the musepi-pro is the only one supported that should
> be fine.

Agree. A table will be more flexible and easy-to-expand. In v3 I will use
an explicit per-board mapping:
  k1-x_MUSE-Pi-Pro -> spacemit/k1-musepi-pro
  k1-x_deb1 -> spacemit/k1-bananapi-f3
  k1-x_milkv-jupiter -> spacemit/k1-milkv-jupiter

, falling back to spacemit/k1-bananapi-f3 by default.

With these, tolower() will not be necessary.

BR,
Guodong / docularxu

> Regards
> Aurelien
>
> --
> Aurelien Jarno                          GPG: 4096R/1DDD8C9B
> aurelien at aurel32.net                     http://aurel32.net


More information about the U-Boot mailing list