Re: [PATCH v13 7/7] spacemit: k1: fix product name detection and DTB matching in SPL

[Andre Heider <a.heider@gmail.com>]

Hi,

just noticed that Yixuan wasn't part of cc:, adding.

On 05.10.26 11:33 PM, E Shattow wrote:
> On 10/5/26 08:34, Eric Chung wrote:
>> On Mon, Oct 5, 2026 at 3:23 PM Andre Heider <a.heider@gmail.com> wrote:
>>>
>>> On 05.10.26 6:01 AM, Eric Chung wrote:
>>>> On Fri, Oct 2, 2026 at 8:58 PM Andre Heider <a.heider@gmail.com> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> just a general question related to this patch, not about the patch itself, see below:
>>>>>
>>>>> On 12.09.26 2:37 PM, Eric Chung wrote:
>>>>>> +static const struct {
>>>>>> +     const char *eeprom_name;
>>>>>> +     const char *fit_name;
>>>>>> +} k1_board_map[] = {
>>>>>> +     { "k1-x_MUSE-Pi-Pro",   "spacemit/k1-musepi-pro"    },
>>>>>> +     { "k1-x_deb1",          "spacemit/k1-bananapi-f3"   },
>>>>>> +     { "k1-x_milkv-jupiter", "spacemit/k1-milkv-jupiter" },
>>>>>> +};
>>>>> This maps the EEPROMs product_name to the dtb, just like the vendor fork, nice.
>>>>>
>>>>> But does the BPI F3 really have "k1-x_deb1" in there?
>>>>> I know that's the fallback dtb of the vendor's fork [0][1], in case there's nothing there, and I thought that was the case for the F3?
>>>>>
>>>>
>>>> k1-x_deb1 means the internal development board. And it could work
>>>> smoothly on the Banana Pi F3.
>>>
>>> Yes, but maybe someone with a F3 board can verify via `tlv_eeprom` if that string is actually in there?
>>>
>>>>
>>>>
>>>>> Because it seems it's not set for BPI-CM6 IO board either [2], which then makes it impossible to distinguish, at least based on the EEPROM value :\
>>>>>
>>>>
>>>> What's BPI-CM6 IO board? Is the BPI-CM6 IO board similar to the Banana
>>>> Pi F3? Is it supported by linux kernel now?
>>>
>>> This one:
>>> https://docs.banana-pi.org/en/BPI-CM6/BananaPi_BPI-CM6
>>>
>>> Supported by mainline via:
>>> arch/riscv/boot/dts/spacemit/k1-bananapi-cm6-io.dts
>>>
>>> Apparently sinovoip *edited* k1-x_deb1.dts for CM6 and even ship that hack in their OS images (visible in the logs on that OpenWrt PR):
>>> https://github.com/BPI-SINOVOIP/pi-linux/commit/333b99e8cd9b18e98bf71821518548df345dbb61
>>> /o\
>>>
>>>>
>>>>> Are there any ideas how to handle that, yet?
>>>>>
>>>>> Can we distinguish between those boards in the SPL based on something different?
>>>>>
>>>>> Or can we make up our own strings and let users write that to EEPROM? Mainline and vendor technically allows it via e.g.:
>>>>>      tlv_eeprom set 0x21 "k1-x_BPI-CM6-IO"
>>>>>      tlv_eeprom write
>>>>> But that's assuming the EEPROM is writable, which I haven't checked.
>>>>> (And I neither have a F3 nor a CM6).
>>>>>
>>>>
>>>> tlv_eeprom should support to write EEPROM. If it fails, we could
>>>> enable ENV in SPL. I have a patch in the mailing list to enable ENV.
>>>> But that patch was abandoned. You could review the mailing list to
>>>> reuse it.
>>>
>>> In the meantime a board owner verified the EEPROM write as working:
>>> https://github.com/openwrt/openwrt/pull/23231#issuecomment-5972395785
>>>
>>> For the record, I made up "k1-x_BPI-CM6-IO" as product name with a matching vendor fork device-tree file name, which makes u-boot as well as the kernel pick up their matching device-trees via CONFIG_FIT_BEST_MATCH.
>>>
>>> In case mainline u-boot goes the same way (let CM6 owners add a value to EEPROM) to properly make multi-dtb fit images boot, can we agree on a value? Or maybe someone here has connections to sinovoip and ask them to put that/anything in there?
>>>
>>
>> Yes, adding "k1-x_BPI-CM6-IO" to the EEPROM sounds good to me. Feel
>> free to format a patch and send it to the mailing list.
> 
> If we are inventing EEPROM data based on vibes then I think it is
> appropriate to give at least one or two characters in the EEPROM data to
> the company names respectively; "BananaPi" and "OrangePi" are brands
> astroturfing the Raspbery Pi Foundation trademark.
> 
> "Orange Pi is an open source product brand of Shenzhen Xunlong Software
> Co., Ltd" from www.orangepi.org website.
> 
> FYI for the StarFive JH-7110 SoC Xunlong OrangePi RV board I made up
> this EEPROM value in board/starfive/visionfive2/spl.c:
> 
>          } else if (!strcmp(name, "starfive/jh7110-orangepi-rv") &&
>                      !strncmp(get_product_id_from_eeprom(), "XOPIRV", 6)) {
> 
> and in board/starfive/visionfive2/starfive_visionfive2.c:
> 
>          } else if (!strncmp(get_product_id_from_eeprom(), "XOPIRV", 6)) {
>                  fdtfile = "starfive/jh7110-orangepi-rv.dtb";
> 
> It is the situation that a few products on the market with JH-7110 SoC
> have shipped having an EEPROM product name data identical to the
> reference StarFive VisionFive2 1.3b board and where the vendor edits
> this corresponding dts file in their own u-boot fork. Eventually I would
> like this to be a bare-minimum default for boards in mainline u-boot
> that get it wrong to boot with just enough peripheral support to write a
> new EEPROM value. As it is now we fail the boot with a message for the
> user when no match is found.

Ack, that sounds like a good idea.

> While we're inventing new values for boards with SpacemiT SoC we should
> also add such for the Banana Pi F3 and not leave it with the generic
> reference board product name (unless that is in fact what its purpose is
> historically). I suggest a logical-or to the existing comparison for
> compatibility until a decision is formed about what should be the
> default when no match is found.
> 
> The EEPROM data examples are derived from vendor u-boot filenames so not
> necessary to arbitrarily upcase; Add for example "k1-x_svbpi-cm6" for
> the System-on module or "k1-x_svbpi-cm6-io" for the baseboard, whichever
> has the EEPROM device. In fact we might also derive this as
> "k1-bananapi-cm6" or "k1-bananapi-cm6-io" from upstream Linux. The
> pattern with "k1-x_" prefix appears to be representing vendor dts
> filenames for boards with the taped-out K1 SoC; and "k1-pro_" is
> pre-production dts filename related. That is very arbitrary and I don't
> see any reason why we should invent something on vibes about a filename
> that does not exist... but anyways it would be lowercase and not upcase.

While mainline u-boot for K1 progresses nicely, it's not ready yet (think bootstrapping spl/proper/kernel on all boards from bootrom via fastboot).
Which is why the OpenWrt PR has the vendor u-boot for now (with some patches and compatibles added to boot mainline opensbi/linux).
So I actually created a k1-x_BPI-CM6-IO.dts file in there. I just derived the name based on what else is in there:

k1-x_baton-camera.dts
k1-x_BPI-CM6-IO.dts
k1-x_deb1.dts
k1-x_deb2.dts
k1-x_evb.dts
k1-x_FusionOne.dts
k1-x_InnoBoard-Pi.dts
k1-x_lpi3a.dts
k1-x_LX-V10.dts
k1-x_milkv-jupiter.dts
k1-x_MINI-PC.dts
k1-x_MUSE-Book.dts
k1-x_MUSE-Card.dts
k1-x_MUSE-N1.dts
k1-x_MUSE-Paper2.dts
k1-x_MUSE-Paper-mini-4g.dts
k1-x_MUSE-Pi.dts
k1-x_MUSE-Pi-Pro.dts
k1-x_som.dts
k1-x_spl.dts
k1-x_uav.dts
k1-x_ZT001H.dts
k1-x_ZT_RVOH007.dts
x1_orangepi-r2s.dts
x1_orangepi-rv2.dts

- the k1-x_ prefix is to keep it in line
- there's a mix of upper and lower case
- the mainline dts has no "sv" or "sinovoip" either, it even uses the "bananapi" vendor for the compatible
- both orangepi boards are already covered. The patches are from armbian IIRC, but didn't require adding a product name to EEPROM

> Suggested thus any of:
> k1-x_bpi-cm6(-io)
> k1-x_svbpi-cm6(-io)
> k1-x_svbp-bpi-cm6(-io)
> k1-x_bpbpi-cm6(-io)
> k1-x_bpi-cm6(-io)
> k1-bananapi-cm6
> k1-bananapi-cm6-io
> k1-bananapi-f3
> 
> My strong preference is for referring to mainline Linux dts filenames if
> we are just making it up when the overwhelming trend is to refer to
> actual filenames, somewhere.
I don't really have a preference, the name I made up was the first thing that made sense to me. Whatever can be agreed upon ;)

Cheers,
Andre