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?
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 :\
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).
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
