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.
