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

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

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?

> 
>> Cheers,
>> Andre
>>
>> [0] https://gitee.com/spacemit-buildroot/uboot-2022.10/blob/k1-bl-v2.2.y/include/configs/k1-x.h#L28
>> [1] https://gitee.com/spacemit-buildroot/uboot-2022.10/blob/k1-bl-v2.2.y/board/spacemit/k1-x/spl.c#L558
>> [2] https://github.com/openwrt/openwrt/pull/23231#issuecomment-5943699070