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

[E Shattow <e@freeshell.de>]

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.

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.

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.

-E