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 <[email protected]> wrote:
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?
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
