On 05.10.26 6:01 AM, Eric Chung wrote:
On Fri, Oct 2, 2026 at 8:58 PM Andre Heider <[email protected]> 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
