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. > 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? > 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. > 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
