* [PATCH v13 1/7] spacemit: k1: select boot device via config registers
2026-09-12 12:36 [PATCH v13 0/7] spacemit mmc driver Eric Chung
@ 2026-09-12 12:36 ` Eric Chung
2026-09-12 12:36 ` [PATCH v13 2/7] mmc: k1: add sdhci platform driver Eric Chung
` (7 subsequent siblings)
8 siblings, 0 replies; 18+ messages in thread
From: Eric Chung @ 2026-09-12 12:36 UTC (permalink / raw)
To: u-boot-spacemit, u-boot, Yao Zi, u-boot
Cc: Tom Rini, Tim Ouyang, Leo Liang, Wei Fu, Scott Bambrough,
Huan Zhou, Eric Chung, Raymond Mao, Peng Fan, Jaehoon Chung,
Bastien Curutchet, Anshul Dalal, Siu Ming Tong, Johan Jonker
Add logic to determine the current boot device by reading the
SoC's configuration registers, rather than using a hardcoded
default.
Signed-off-by: Eric Chung <eric.chung@riscstar.com>
Reviewed-by: Yao Zi <me@ziyao.cc>
---
v11:
- Fix read_boot_mode() on returning both boot mode and boot device.
v9:
- Enhance detection on booting from SD card.
v5:
- Add blank lines around the switch statement.
v2:
- Use FIELD_GET() to parse boot strap mode.
- Remove comments on hacking. Since the sequence between eMMC
and SD device is exchanged in the upstream DTS. So it isn't
a hacking any more.
---
board/spacemit/k1/spl.c | 98 ++++++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 97 insertions(+), 1 deletion(-)
diff --git a/board/spacemit/k1/spl.c b/board/spacemit/k1/spl.c
index d749e21a2d57..374922573c98 100644
--- a/board/spacemit/k1/spl.c
+++ b/board/spacemit/k1/spl.c
@@ -13,6 +13,7 @@
#include <dm/device.h>
#include <dm/uclass.h>
#include <i2c.h>
+#include <linux/bitfield.h>
#include <linux/ctype.h>
#include <linux/delay.h>
#include <log.h>
@@ -22,6 +23,20 @@
#include <tlv_eeprom.h>
#include "tlv_codes.h"
+/* boot mode configs */
+#define BOOT_DEV_FLAG_REG 0xd4282d10
+#define BOOT_PIN_SEL_REG 0xd4282c20
+
+#define BOOT_STRAP_MODE_OFFSET 9
+#define BOOT_STRAP_MODE_MASK 3
+#define BOOT_STRAP_MODE_EMMC 0
+#define BOOT_STRAP_MODE_SPI 1
+#define BOOT_STRAP_MODE_NAND 2
+#define BOOT_STRAP_MODE_SD 3
+
+#define STORAGE_API_P_ADDR 0xc0838498
+#define SDCARD_API_ENTRY 0xffe0a548
+
#define MUX_MODE4 4
#define EDGE_NONE BIT(6)
#define PULL_UP (6 << 13) /* bit[15:13] 110 */
@@ -46,6 +61,17 @@ typedef void (*puts_func_t)(const char *s);
typedef int (*ddr_init_func_t)(u64 ddr_base, u32 cs_num, u32 data_rate,
puts_func_t puts);
+enum board_boot_mode {
+ BOOT_MODE_NONE = 0,
+ BOOT_MODE_USB = 0x55a,
+ BOOT_MODE_EMMC,
+ BOOT_MODE_NAND,
+ BOOT_MODE_SPI,
+ BOOT_MODE_SD,
+ BOOT_MODE_SHELL = 0x55f,
+ BOOT_MODE_BOOTSTRAP,
+};
+
struct ddr_cfg {
u32 data_rate;
u32 cs_num;
@@ -58,6 +84,47 @@ binman_sym_declare(ulong, ddr_fw, size);
char product_name[I2C_BUF_SIZE] = "k1";
+static u32 read_boot_mode(void)
+{
+ void __iomem *boot_dev = (void __iomem *)BOOT_DEV_FLAG_REG;
+ void __iomem *boot_strap = (void __iomem *)BOOT_PIN_SEL_REG;
+ void __iomem *storage_api = (void __iomem *)STORAGE_API_P_ADDR;
+ u32 mode, sel;
+
+ mode = readl(storage_api);
+ if (mode == SDCARD_API_ENTRY)
+ return BOOT_MODE_SD;
+
+ mode = readl(boot_dev);
+ if (mode == BOOT_MODE_NONE || mode > BOOT_MODE_SD) {
+ sel = FIELD_GET(BOOT_STRAP_MODE_MASK << BOOT_STRAP_MODE_OFFSET,
+ readl(boot_strap));
+ switch (sel) {
+ case BOOT_STRAP_MODE_EMMC:
+ mode = BOOT_MODE_EMMC;
+ break;
+ case BOOT_STRAP_MODE_NAND:
+ mode = BOOT_MODE_NAND;
+ break;
+ case BOOT_STRAP_MODE_SPI:
+ mode = BOOT_MODE_SPI;
+ break;
+ case BOOT_STRAP_MODE_SD:
+ default:
+ mode = BOOT_MODE_SD;
+ break;
+ }
+ }
+ return mode;
+}
+
+static void write_boot_mode(u32 mode)
+{
+ void __iomem *boot_dev = (void __iomem *)BOOT_DEV_FLAG_REG;
+
+ writel(mode, boot_dev);
+}
+
static void i2c_early_init(void)
{
struct udevice *bus;
@@ -327,8 +394,12 @@ void nor_early_init(void)
void board_init_f(ulong dummy)
{
+ u32 mode;
int ret;
+ mode = read_boot_mode();
+ write_boot_mode(mode);
+
ret = spl_early_init();
if (ret)
panic("spl_early_init() failed:%d\n", ret);
@@ -354,7 +425,32 @@ void board_init_f(ulong dummy)
u32 spl_boot_device(void)
{
- return BOOT_DEVICE_SPI;
+ u32 mode;
+ int ret;
+
+ mode = read_boot_mode();
+ switch (mode) {
+ case BOOT_MODE_EMMC:
+ ret = BOOT_DEVICE_MMC1;
+ break;
+ case BOOT_MODE_NAND:
+ ret = BOOT_DEVICE_NAND;
+ break;
+ case BOOT_MODE_SPI:
+ ret = BOOT_DEVICE_SPI;
+ break;
+ case BOOT_MODE_USB:
+ ret = BOOT_DEVICE_USB;
+ break;
+ case BOOT_MODE_SD:
+ ret = BOOT_DEVICE_MMC2;
+ break;
+ default:
+ ret = BOOT_DEVICE_MMC1;
+ break;
+ }
+
+ return ret;
}
void spl_board_init(void)
--
2.51.0
^ permalink raw reply related [flat|nested] 18+ messages in thread* [PATCH v13 2/7] mmc: k1: add sdhci platform driver
2026-09-12 12:36 [PATCH v13 0/7] spacemit mmc driver Eric Chung
2026-09-12 12:36 ` [PATCH v13 1/7] spacemit: k1: select boot device via config registers Eric Chung
@ 2026-09-12 12:36 ` Eric Chung
2026-09-16 12:40 ` Yixun Lan
2026-09-12 12:36 ` [PATCH v13 3/7] dts: k1: enable mmc devices in SPL Eric Chung
` (6 subsequent siblings)
8 siblings, 1 reply; 18+ messages in thread
From: Eric Chung @ 2026-09-12 12:36 UTC (permalink / raw)
To: u-boot-spacemit, u-boot, Yao Zi, u-boot
Cc: Tom Rini, Tim Ouyang, Leo Liang, Wei Fu, Scott Bambrough,
Huan Zhou, Eric Chung, Raymond Mao, Peng Fan, Jaehoon Chung,
Bastien Curutchet, Anshul Dalal, Siu Ming Tong, Johan Jonker
Add SDHCI platform driver support for SpacemiT K1 SoC. This driver
implements the necessary platform-specific operations for the SDHCI
controller, enabling MMC/SD card functionality on K1-based platforms.
Signed-off-by: Eric Chung <eric.chung@riscstar.com>
---
v13:
- Sync definition values from upstream mmc driver.
v9:
- Disable CMD18 (multiple-block read) for SD cards in SPL.
v6:
- Remove ".data = 0" in spacemit_sdhci_ids[].
v5:
- Remove MMC_CAP_CMD23 as the CMD23 support is now a separate series.
- Use tabs for macro definition alignment.
- Use read_poll_timeout().
- Set pinctrl state based on selected timing mode.
- Add the definition of SDHC_DLL_REG1_HS400_VAL.
- Remove the condition based on quirks.
v4:
- Add bulk release operations on reset and clock.
v3:
- Enable CMD23 in capability.
v2:
- Enable ADMA mode support.
- Use CMD23 for multi-block read/write.
- Move ASR/AIB register into pinctrl driver.
- Correct pinctrl state from "fast" to "uhs".
- Migrate tuning support from the spacemit linux driver.
---
drivers/mmc/Kconfig | 7 +
drivers/mmc/Makefile | 1 +
drivers/mmc/spacemit_sdhci.c | 684 +++++++++++++++++++++++++++++++++++++++++++
3 files changed, 692 insertions(+)
diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index 4ee56465c0fe..f3443cc9bed8 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -729,6 +729,13 @@ config MMC_SDHCI_SNPS
If unsure, say N.
+config MMC_SDHCI_SPACEMIT
+ bool "Spacemit SDHCI controller"
+ depends on MMC_SDHCI
+ help
+ Support for Secure Digital Host Controller Interface (SDHCI) on
+ Spacemit K1 SoC.
+
config MMC_SDHCI_STI
bool "SDHCI support for STMicroelectronics SoC"
depends on MMC_SDHCI && OF_CONTROL && ARCH_STI
diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
index f4a40ee10d5b..5130b46f29c0 100644
--- a/drivers/mmc/Makefile
+++ b/drivers/mmc/Makefile
@@ -72,6 +72,7 @@ obj-$(CONFIG_MMC_SDHCI_ROCKCHIP) += rockchip_sdhci.o
obj-$(CONFIG_MMC_SDHCI_ADI) += adi_sdhci.o
obj-$(CONFIG_MMC_SDHCI_S5P) += s5p_sdhci.o
obj-$(CONFIG_MMC_SDHCI_SNPS) += snps_sdhci.o
+obj-$(CONFIG_MMC_SDHCI_SPACEMIT) += spacemit_sdhci.o
obj-$(CONFIG_MMC_SDHCI_STI) += sti_sdhci.o
obj-$(CONFIG_MMC_SDHCI_TANGIER) += tangier_sdhci.o
obj-$(CONFIG_MMC_SDHCI_TEGRA) += tegra_mmc.o
diff --git a/drivers/mmc/spacemit_sdhci.c b/drivers/mmc/spacemit_sdhci.c
new file mode 100644
index 000000000000..f5578f38bdd1
--- /dev/null
+++ b/drivers/mmc/spacemit_sdhci.c
@@ -0,0 +1,684 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Driver for Spacemit K1 Mobile Storage Host Controller
+ *
+ * Copyright (C) 2023-2026 Spacemit Inc.
+ * Copyright (C) 2026 RISCstar Ltd.
+ */
+
+#define LOG_CATEGORY UCLASS_MMC
+
+#include <clk.h>
+#include <dm.h>
+#include <fdtdec.h>
+#include <log.h>
+#include <malloc.h>
+#include <sdhci.h>
+#include <reset-uclass.h>
+#include <mapmem.h>
+#include <dm/pinctrl.h>
+#include <linux/bitfield.h>
+#include <linux/iopoll.h>
+#include <linux/libfdt.h>
+#include <linux/delay.h>
+#include <power/regulator.h>
+
+/* SDH register definitions */
+#define SPACEMIT_SDHC_OP_EXT_REG 0x108
+#define SDHC_OVRRD_CLK_OEN BIT(11)
+#define SDHC_FORCE_CLK_ON BIT(12)
+
+#define SPACEMIT_SDHC_LEGACY_CTRL_REG 0x10C
+#define SDHC_GEN_PAD_CLK_ON BIT(6)
+
+#define SPACEMIT_SDHC_MMC_CTRL_REG 0x114
+#define SDHC_MISC_INT_EN BIT(1)
+#define SDHC_MISC_INT BIT(2)
+#define SDHC_ENHANCE_STROBE_EN BIT(8)
+#define SDHC_MMC_HS400 BIT(9)
+#define SDHC_MMC_HS200 BIT(10)
+#define SDHC_MMC_CARD_MODE BIT(12)
+
+#define SPACEMIT_SDHC_TX_CFG_REG 0x11C
+#define SDHC_TX_INT_CLK_SEL BIT(30)
+#define SDHC_TX_MUX_SEL BIT(31)
+
+#define SPACEMIT_SDHC_PHY_CTRL_REG 0x160
+#define SDHC_PHY_FUNC_EN BIT(0)
+#define SDHC_PHY_PLL_LOCK BIT(1)
+#define SDHC_HOST_LEGACY_MODE BIT(31)
+
+#define SPACEMIT_SDHC_PHY_FUNC_REG 0x164
+#define SDHC_PHY_TEST_EN BIT(7)
+#define SDHC_HS200_USE_RFIFO BIT(15)
+
+#define SPACEMIT_SDHC_PHY_DLLCFG 0x168
+#define SDHC_DLL_PREDLY_NUM GENMASK(3, 2)
+#define SDHC_DLL_FULLDLY_RANGE GENMASK(5, 4)
+#define SDHC_DLL_VREG_CTRL GENMASK(7, 6)
+#define SDHC_DLL_ENABLE BIT(31)
+
+#define SPACEMIT_SDHC_PHY_DLLCFG1 0x16C
+#define SDHC_DLL_REG1_CTRL GENMASK(7, 0)
+#define SDHC_DLL_REG2_CTRL GENMASK(15, 8)
+#define SDHC_DLL_REG3_CTRL GENMASK(23, 16)
+#define SDHC_DLL_REG4_CTRL GENMASK(31, 24)
+#define SDHC_DLL_REG1_HS400_VAL 0x92
+
+#define SPACEMIT_SDHC_PHY_DLLSTS 0x170
+#define SDHC_DLL_LOCK_STATE BIT(0)
+
+#define SPACEMIT_SDHC_PHY_PADCFG_REG 0x178
+#define SDHC_PHY_DRIVE_SEL GENMASK(2, 0)
+#define SDHC_RX_BIAS_CTRL BIT(5)
+
+#define SPACEMIT_SDHC_RX_CFG_REG 0x118
+#define SDHC_RX_SDCLK_SEL0_MASK GENMASK(1, 0)
+#define SDHC_RX_SDCLK_SEL1_MASK GENMASK(3, 2)
+#define SDHC_RX_SDCLK_SEL1 FIELD_PREP(SDHC_RX_SDCLK_SEL1_MASK, 1)
+
+#define SPACEMIT_SDHC_DLINE_CTRL_REG 0x130
+#define SDHC_DLINE_PU BIT(0)
+#define SDHC_RX_DLINE_CODE_MASK GENMASK(23, 16)
+#define SDHC_TX_DLINE_CODE_MASK GENMASK(31, 24)
+
+#define SPACEMIT_SDHC_DLINE_CFG_REG 0x134
+#define SDHC_RX_DLINE_REG_MASK GENMASK(7, 0)
+#define SDHC_RX_DLINE_GAIN BIT(8)
+#define SDHC_TX_DLINE_REG_MASK GENMASK(23, 16)
+
+#define SPACEMIT_RX_DLINE_REG 0
+#define SPACEMIT_RX_TUNE_DELAY_MIN 0x0
+#define SPACEMIT_RX_TUNE_DELAY_MAX 0xFF
+
+#define SPACEMIT_TX_TUNING_DLINE_REG 0x00
+#define SPACEMIT_TX_TUNING_DELAYCODE 127
+
+struct spacemit_sdhci_plat {
+ struct mmc_config cfg;
+ struct mmc mmc;
+ struct reset_ctl_bulk resets;
+ struct clk_bulk clks;
+};
+
+struct spacemit_sdhci_priv {
+ struct sdhci_host host;
+};
+
+/* All helper functions will update clr/set while preserve rest bits */
+static inline void spacemit_sdhci_setbits(struct sdhci_host *host, u32 val,
+ int reg)
+{
+ sdhci_writel(host, sdhci_readl(host, reg) | val, reg);
+}
+
+static inline void spacemit_sdhci_clrbits(struct sdhci_host *host, u32 val,
+ int reg)
+{
+ sdhci_writel(host, sdhci_readl(host, reg) & ~val, reg);
+}
+
+static inline void spacemit_sdhci_clrsetbits(struct sdhci_host *host, u32 clr,
+ u32 set, int reg)
+{
+ u32 val = sdhci_readl(host, reg);
+
+ val = (val & ~clr) | set;
+ sdhci_writel(host, val, reg);
+}
+
+#if CONFIG_IS_ENABLED(MMC_SUPPORTS_TUNING)
+static void spacemit_sdhci_set_rx_delay(struct sdhci_host *host, u8 delay)
+{
+ spacemit_sdhci_clrsetbits(host, SDHC_RX_DLINE_CODE_MASK,
+ FIELD_PREP(SDHC_RX_DLINE_CODE_MASK, delay),
+ SPACEMIT_SDHC_DLINE_CTRL_REG);
+}
+
+static void spacemit_sdhci_set_tx_delay(struct sdhci_host *host, u8 delay)
+{
+ spacemit_sdhci_clrsetbits(host, SDHC_TX_DLINE_CODE_MASK,
+ FIELD_PREP(SDHC_TX_DLINE_CODE_MASK, delay),
+ SPACEMIT_SDHC_DLINE_CTRL_REG);
+}
+
+static void spacemit_sdhci_set_tx_dline_reg(struct sdhci_host *host,
+ u8 dline_reg)
+{
+ spacemit_sdhci_clrsetbits(host, SDHC_TX_DLINE_REG_MASK,
+ FIELD_PREP(SDHC_TX_DLINE_REG_MASK, dline_reg),
+ SPACEMIT_SDHC_DLINE_CFG_REG);
+}
+
+static void spacemit_sdhci_tx_tuning_prepare(struct sdhci_host *host)
+{
+ spacemit_sdhci_setbits(host, SDHC_TX_MUX_SEL, SPACEMIT_SDHC_TX_CFG_REG);
+ spacemit_sdhci_setbits(host, SDHC_DLINE_PU,
+ SPACEMIT_SDHC_DLINE_CTRL_REG);
+ udelay(5);
+}
+
+static void spacemit_sdhci_prepare_tuning(struct sdhci_host *host)
+{
+ spacemit_sdhci_clrsetbits(host, SDHC_RX_DLINE_REG_MASK,
+ FIELD_PREP(SDHC_RX_DLINE_REG_MASK, SPACEMIT_RX_DLINE_REG),
+ SPACEMIT_SDHC_DLINE_CFG_REG);
+
+ spacemit_sdhci_setbits(host, SDHC_DLINE_PU,
+ SPACEMIT_SDHC_DLINE_CTRL_REG);
+ udelay(5);
+
+ spacemit_sdhci_clrsetbits(host, SDHC_RX_SDCLK_SEL1_MASK,
+ SDHC_RX_SDCLK_SEL1,
+ SPACEMIT_SDHC_RX_CFG_REG);
+
+ if (host->mmc->selected_mode == MMC_HS_200)
+ spacemit_sdhci_setbits(host, SDHC_HS200_USE_RFIFO,
+ SPACEMIT_SDHC_PHY_FUNC_REG);
+}
+#endif /* MMC_SUPPORTS_TUNING */
+
+/*
+ * Reference: PMU_SDH0_CLK_RES_CTRL (0x054), SDH0_CLK_SEL=0x0,
+ * SDH0_CLK_DIV=0x1. The default clock source is 204.8 MHz
+ * (pll1_d6_409p6Mhz / 2).
+ *
+ * During start-up, use a 200 kHz frequency.
+ */
+#define SDHC_MIN_CLOCK (200 * 1000)
+
+static void spacemit_sdhci_phy_init(struct udevice *dev,
+ struct sdhci_host *host)
+{
+ u32 reg = 0;
+
+ if (dev_read_bool(dev, "no-sd") && dev_read_bool(dev, "no-sdio")) {
+ /* MMC card mode */
+ reg = sdhci_readl(host, SPACEMIT_SDHC_MMC_CTRL_REG);
+ reg |= SDHC_MMC_CARD_MODE;
+ sdhci_writel(host, reg, SPACEMIT_SDHC_MMC_CTRL_REG);
+
+ /* Use PHY functional mode */
+ reg = sdhci_readl(host, SPACEMIT_SDHC_PHY_CTRL_REG);
+ reg |= (SDHC_PHY_FUNC_EN | SDHC_PHY_PLL_LOCK);
+ sdhci_writel(host, reg, SPACEMIT_SDHC_PHY_CTRL_REG);
+
+ reg = sdhci_readl(host, SPACEMIT_SDHC_PHY_PADCFG_REG);
+ reg |= SDHC_RX_BIAS_CTRL;
+ sdhci_writel(host, reg, SPACEMIT_SDHC_PHY_PADCFG_REG);
+ } else {
+ reg = sdhci_readl(host, SPACEMIT_SDHC_TX_CFG_REG);
+ reg |= SDHC_TX_INT_CLK_SEL;
+ sdhci_writel(host, reg, SPACEMIT_SDHC_TX_CFG_REG);
+ }
+
+ reg = sdhci_readl(host, SPACEMIT_SDHC_MMC_CTRL_REG);
+ reg &= ~SDHC_ENHANCE_STROBE_EN;
+ sdhci_writel(host, reg, SPACEMIT_SDHC_MMC_CTRL_REG);
+}
+
+static int spacemit_sdhci_set_vqmmc_voltage(struct mmc *mmc, int voltage)
+{
+#if CONFIG_IS_ENABLED(DM_REGULATOR)
+ int ret;
+
+ if (!mmc->vqmmc_supply)
+ return 0;
+
+ ret = regulator_set_value(mmc->vqmmc_supply, voltage);
+ if (ret)
+ return ret;
+ ret = regulator_set_enable_if_allowed(mmc->vqmmc_supply, true);
+ if (ret)
+ return ret;
+#endif
+ return 0;
+}
+
+static void spacemit_sdhci_set_voltage(struct sdhci_host *host)
+{
+ if (IS_ENABLED(CONFIG_MMC_IO_VOLTAGE)) {
+ struct mmc *mmc = host->mmc;
+ u32 ctrl;
+
+ ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
+
+ switch (mmc->signal_voltage) {
+ case MMC_SIGNAL_VOLTAGE_330:
+ case MMC_SIGNAL_VOLTAGE_180: {
+ bool to_180 = mmc->signal_voltage ==
+ MMC_SIGNAL_VOLTAGE_180;
+ bool ok;
+ int voltage_mv = to_180 ? 1800000 : 3300000;
+
+ if (spacemit_sdhci_set_vqmmc_voltage(mmc, voltage_mv))
+ return;
+ if (!IS_SD(mmc))
+ return;
+ if (to_180)
+ ctrl |= SDHCI_CTRL_VDD_180;
+ else
+ ctrl &= ~SDHCI_CTRL_VDD_180;
+ sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2);
+
+ mdelay(5);
+
+ ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
+ ok = !!(ctrl & SDHCI_CTRL_VDD_180) == to_180;
+ if (ok)
+ return;
+
+ log_err("%d.%dV regulator output not stable\n",
+ voltage_mv / 1000000,
+ (voltage_mv / 100000) % 10);
+ break;
+ }
+ default:
+ /* No signal voltage switch required */
+ return;
+ }
+ }
+}
+
+static void spacemit_sdhci_set_clk_gate(struct sdhci_host *host, int auto_gate)
+{
+ u32 reg;
+
+ reg = sdhci_readl(host, SPACEMIT_SDHC_OP_EXT_REG);
+ if (auto_gate)
+ reg &= ~(SDHC_OVRRD_CLK_OEN | SDHC_FORCE_CLK_ON);
+ else
+ reg |= (SDHC_OVRRD_CLK_OEN | SDHC_FORCE_CLK_ON);
+ sdhci_writel(host, reg, SPACEMIT_SDHC_OP_EXT_REG);
+}
+
+static bool spacemit_sdhci_is_voltage_switch_cmd(struct sdhci_host *host)
+{
+ struct mmc *mmc = host->mmc;
+ u32 cmd;
+
+ if (!IS_SD(mmc))
+ return false;
+
+ cmd = SDHCI_GET_CMD(sdhci_readw(host, SDHCI_COMMAND));
+ return cmd == SD_CMD_SWITCH_UHS18V &&
+ mmc->signal_voltage == MMC_SIGNAL_VOLTAGE_180;
+}
+
+static int spacemit_sdhci_wait_dat0(struct udevice *dev, int state,
+ int timeout_us)
+{
+ struct mmc *mmc = mmc_get_mmc_dev(dev);
+ struct sdhci_host *host = mmc->priv;
+ u32 tmp;
+ int ret;
+
+ ret = read_poll_timeout(sdhci_readl, tmp,
+ !!(tmp & SDHCI_DATA_0_LVL_MASK) == !!state,
+ 0, timeout_us, host, SDHCI_PRESENT_STATE);
+ if (ret)
+ return ret;
+
+ if (spacemit_sdhci_is_voltage_switch_cmd(host))
+ spacemit_sdhci_set_clk_gate(host, 1);
+ return 0;
+}
+
+static int spacemit_sdhci_get_b_max(struct udevice *dev, void *dst,
+ lbaint_t blkcnt)
+{
+ struct mmc *mmc = mmc_get_mmc_dev(dev);
+
+ if (IS_ENABLED(CONFIG_SPL_BUILD) && mmc && IS_SD(mmc))
+ return 1;
+ return mmc->cfg->b_max;
+}
+
+static void spacemit_sdhci_set_control_reg(struct sdhci_host *host)
+{
+ struct mmc *mmc = host->mmc;
+ u32 reg;
+
+ spacemit_sdhci_set_voltage(host);
+
+ if (spacemit_sdhci_is_voltage_switch_cmd(host))
+ spacemit_sdhci_set_clk_gate(host, 0);
+
+ /*
+ * Set TX_INT_CLK_SEL to guarantee hold time at default speed,
+ * HS, SDR12/SDR25/SDR50 modes. See SDHC_TX_CFG_REG (0x11c).
+ */
+ reg = sdhci_readl(host, SPACEMIT_SDHC_TX_CFG_REG);
+ if (mmc->selected_mode == MMC_LEGACY ||
+ mmc->selected_mode == MMC_HS ||
+ mmc->selected_mode == SD_HS ||
+ mmc->selected_mode == UHS_SDR12 ||
+ mmc->selected_mode == UHS_SDR25 ||
+ mmc->selected_mode == UHS_SDR50) {
+ reg |= SDHC_TX_INT_CLK_SEL;
+ } else {
+ reg &= ~SDHC_TX_INT_CLK_SEL;
+ }
+ sdhci_writel(host, reg, SPACEMIT_SDHC_TX_CFG_REG);
+
+ /* Set pinctrl state based on selected timing mode */
+ if (IS_ENABLED(CONFIG_PINCTRL)) {
+ switch (mmc->selected_mode) {
+ case UHS_SDR12:
+ case UHS_SDR25:
+ case UHS_SDR50:
+ case UHS_SDR104:
+ pinctrl_select_state(mmc->dev, "uhs");
+ break;
+ default:
+ pinctrl_select_state(mmc->dev, "default");
+ break;
+ }
+ }
+
+ if (mmc->selected_mode == MMC_HS_200 ||
+ mmc->selected_mode == MMC_HS_400 ||
+ mmc->selected_mode == MMC_HS_400_ES) {
+ reg = sdhci_readw(host, SPACEMIT_SDHC_MMC_CTRL_REG);
+ if (mmc->selected_mode == MMC_HS_200)
+ reg |= SDHC_MMC_HS200;
+ else
+ reg |= SDHC_MMC_HS400;
+ sdhci_writew(host, reg, SPACEMIT_SDHC_MMC_CTRL_REG);
+ } else {
+ reg = sdhci_readw(host, SPACEMIT_SDHC_MMC_CTRL_REG);
+ reg &= ~(SDHC_MMC_HS200 | SDHC_MMC_HS400 | SDHC_ENHANCE_STROBE_EN);
+ sdhci_writew(host, reg, SPACEMIT_SDHC_MMC_CTRL_REG);
+ }
+
+ sdhci_set_uhs_timing(host);
+}
+
+#if CONFIG_IS_ENABLED(MMC_SUPPORTS_TUNING)
+static int spacemit_sdhci_execute_tuning(struct mmc *mmc, u8 opcode)
+{
+ struct sdhci_host *host = mmc->priv;
+ int current_len = 0, current_start = 0;
+ int max_pass_len = 0, max_pass_start = 0;
+ u8 final_delay;
+ int ret = 0;
+ int i;
+
+ /*
+ * Tuning is required for SDR50/SDR104, HS200/HS400 cards and
+ * if clock frequency is greater than 100MHz in these modes.
+ */
+ if (host->clock < 100 * 1000 * 1000 ||
+ !(mmc->selected_mode == MMC_HS_200 ||
+ mmc->selected_mode == UHS_SDR50 ||
+ mmc->selected_mode == UHS_SDR104))
+ return 0;
+
+ if (IS_SD(host->mmc)) {
+ spacemit_sdhci_set_tx_dline_reg(host, SPACEMIT_TX_TUNING_DLINE_REG);
+ spacemit_sdhci_set_tx_delay(host, SPACEMIT_TX_TUNING_DELAYCODE);
+ spacemit_sdhci_tx_tuning_prepare(host);
+
+ log_debug("TX tuning: dline_reg=%d, delaycode=%d\n",
+ SPACEMIT_TX_TUNING_DLINE_REG, SPACEMIT_TX_TUNING_DELAYCODE);
+ }
+
+ spacemit_sdhci_prepare_tuning(host);
+
+ for (i = SPACEMIT_RX_TUNE_DELAY_MIN; i <= SPACEMIT_RX_TUNE_DELAY_MAX; i++) {
+ spacemit_sdhci_set_rx_delay(host, i);
+ ret = mmc_send_tuning(host->mmc, opcode);
+
+ log_debug("RX delay %d: %s\n",
+ i, ret == 0 ? "pass" : "fail");
+
+ if (ret == 0) {
+ /* Test passed - extend current window */
+ if (current_len == 0)
+ current_start = i;
+ current_len++;
+ } else {
+ /* Test failed - check if current window is best so far */
+ if (current_len > max_pass_len) {
+ max_pass_len = current_len;
+ max_pass_start = current_start;
+ }
+ current_len = 0;
+ }
+ }
+
+ if (current_len > max_pass_len) {
+ max_pass_len = current_len;
+ max_pass_start = current_start;
+ }
+
+ if (max_pass_len < 50) {
+ log_err("Tuning failed: no stable window found\n");
+ return -EIO;
+ }
+
+ final_delay = max_pass_start + max_pass_len / 2;
+ spacemit_sdhci_set_rx_delay(host, final_delay);
+ ret = mmc_send_tuning(host->mmc, opcode);
+ if (ret) {
+ u8 retry_delays[] = {
+ max_pass_start + max_pass_len / 4,
+ max_pass_start + (3 * max_pass_len) / 4,
+ max_pass_start,
+ max_pass_start + max_pass_len - 1
+ };
+ int retry_count = ARRAY_SIZE(retry_delays);
+
+ log_warning("Primary delay %d failed, trying alternatives\n",
+ final_delay);
+
+ for (i = 0; i < retry_count; i++) {
+ if (retry_delays[i] >= SPACEMIT_RX_TUNE_DELAY_MIN &&
+ retry_delays[i] <= SPACEMIT_RX_TUNE_DELAY_MAX) {
+ spacemit_sdhci_set_rx_delay(host, retry_delays[i]);
+ ret = mmc_send_tuning(host->mmc, opcode);
+ if (!ret) {
+ final_delay = retry_delays[i];
+ log_info("Retry successful with delay %d\n",
+ final_delay);
+ break;
+ }
+ }
+ }
+
+ if (ret) {
+ log_err("All retry attempts failed\n");
+ return -EIO;
+ }
+ }
+
+ log_debug("Tuning successful: window %d-%d, using delay %d\n",
+ max_pass_start, max_pass_start + max_pass_len - 1, final_delay);
+
+ return 0;
+}
+#endif /* MMC_SUPPORTS_TUNING */
+
+#if CONFIG_IS_ENABLED(MMC_HS400_ES_SUPPORT)
+static int spacemit_sdhci_phy_dll_init(struct sdhci_host *host)
+{
+ u32 reg, val;
+ int ret;
+
+ /* Configure DLL predly, fulldly, and vreg */
+ spacemit_sdhci_clrsetbits(host, SDHC_DLL_PREDLY_NUM |
+ SDHC_DLL_FULLDLY_RANGE |
+ SDHC_DLL_VREG_CTRL,
+ FIELD_PREP(SDHC_DLL_PREDLY_NUM, 1) |
+ FIELD_PREP(SDHC_DLL_FULLDLY_RANGE, 1) |
+ FIELD_PREP(SDHC_DLL_VREG_CTRL, 1),
+ SPACEMIT_SDHC_PHY_DLLCFG);
+
+ reg = sdhci_readl(host, SPACEMIT_SDHC_PHY_DLLCFG1);
+ reg |= FIELD_PREP(SDHC_DLL_REG1_CTRL, SDHC_DLL_REG1_HS400_VAL);
+ sdhci_writel(host, reg, SPACEMIT_SDHC_PHY_DLLCFG1);
+
+ /* Enable DLL */
+ reg = sdhci_readl(host, SPACEMIT_SDHC_PHY_DLLCFG);
+ reg |= SDHC_DLL_ENABLE;
+ sdhci_writel(host, reg, SPACEMIT_SDHC_PHY_DLLCFG);
+
+ /* Wait for DLL lock */
+ ret = read_poll_timeout(sdhci_readl, val, val & SDHC_DLL_LOCK_STATE,
+ 10, 1000, host, SPACEMIT_SDHC_PHY_DLLSTS);
+ if (ret) {
+ log_err("%s: phy dll lock timeout\n", host->name);
+ return -ETIMEDOUT;
+ }
+
+ return 0;
+}
+
+static int spacemit_sdhci_hs400_enhanced_strobe(struct sdhci_host *host)
+{
+ u32 reg;
+
+ reg = sdhci_readl(host, SPACEMIT_SDHC_MMC_CTRL_REG);
+ reg |= SDHC_ENHANCE_STROBE_EN;
+ sdhci_writel(host, reg, SPACEMIT_SDHC_MMC_CTRL_REG);
+
+ return spacemit_sdhci_phy_dll_init(host);
+}
+#endif
+
+const struct sdhci_ops spacemit_sdhci_ops = {
+ .set_control_reg = spacemit_sdhci_set_control_reg,
+#if CONFIG_IS_ENABLED(MMC_SUPPORTS_TUNING)
+ .platform_execute_tuning = spacemit_sdhci_execute_tuning,
+#endif
+#if CONFIG_IS_ENABLED(MMC_HS400_ES_SUPPORT)
+ .set_enhanced_strobe = spacemit_sdhci_hs400_enhanced_strobe,
+#endif
+};
+
+static struct dm_mmc_ops spacemit_mmc_ops;
+
+static int spacemit_sdhci_probe(struct udevice *dev)
+{
+ struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
+ struct spacemit_sdhci_priv *priv = dev_get_priv(dev);
+ struct spacemit_sdhci_plat *plat = dev_get_plat(dev);
+ struct sdhci_host *host = &priv->host;
+ struct clk clk;
+ int ret = 0;
+
+ host->mmc = &plat->mmc;
+ host->mmc->priv = host;
+ host->mmc->dev = dev;
+ upriv->mmc = host->mmc;
+
+ spacemit_mmc_ops = sdhci_ops;
+ spacemit_mmc_ops.wait_dat0 = spacemit_sdhci_wait_dat0;
+ spacemit_mmc_ops.get_b_max = spacemit_sdhci_get_b_max;
+
+ ret = clk_get_bulk(dev, &plat->clks);
+ if (ret) {
+ log_err("Can't get clk: %d\n", ret);
+ return ret;
+ }
+
+ ret = clk_enable_bulk(&plat->clks);
+ if (ret) {
+ log_err("Failed to enable clk: %d\n", ret);
+ goto err_clk;
+ }
+
+ ret = reset_get_bulk(dev, &plat->resets);
+ if (ret) {
+ log_err("Can't get reset: %d\n", ret);
+ goto err_clk;
+ }
+
+ ret = reset_deassert_bulk(&plat->resets);
+ if (ret) {
+ log_err("Failed to reset: %d\n", ret);
+ goto err_reset;
+ }
+
+ ret = clk_get_by_index(dev, 1, &clk);
+ if (ret) {
+ log_err("Can't get io clk: %d\n", ret);
+ goto err_reset;
+ }
+
+ ret = clk_set_rate(&clk, plat->cfg.f_max);
+ if (ret) {
+ log_err("Failed to set io clk: %d\n", ret);
+ goto err_reset;
+ }
+
+ /* Set quirks */
+ host->quirks = SDHCI_QUIRK_WAIT_SEND_CMD |
+ SDHCI_QUIRK_32BIT_DMA_ADDR;
+ host->host_caps = MMC_MODE_HS | MMC_MODE_HS_52MHz;
+ host->max_clk = plat->cfg.f_max;
+
+ plat->cfg.f_min = SDHC_MIN_CLOCK;
+ host->ops = &spacemit_sdhci_ops;
+
+ ret = sdhci_setup_cfg(&plat->cfg, host, plat->cfg.f_max,
+ SDHC_MIN_CLOCK);
+ if (ret)
+ goto err_reset;
+
+ ret = sdhci_probe(dev);
+ if (ret)
+ goto err_reset;
+
+ spacemit_sdhci_phy_init(dev, host);
+ return 0;
+
+err_reset:
+ reset_release_bulk(&plat->resets);
+err_clk:
+ clk_release_bulk(&plat->clks);
+ return ret;
+}
+
+static int spacemit_sdhci_of_to_plat(struct udevice *dev)
+{
+ struct spacemit_sdhci_plat *plat = dev_get_plat(dev);
+ struct spacemit_sdhci_priv *priv = dev_get_priv(dev);
+ struct sdhci_host *host = &priv->host;
+ int ret = 0;
+
+ host->name = dev->name;
+ host->ioaddr = (void *)dev_read_addr(dev);
+
+ ret = mmc_of_parse(dev, &plat->cfg);
+
+ return ret;
+}
+
+static int spacemit_sdhci_bind(struct udevice *dev)
+{
+ struct spacemit_sdhci_plat *drv_data;
+ struct spacemit_sdhci_plat *plat = dev_get_plat(dev);
+
+ drv_data = (struct spacemit_sdhci_plat *)dev_get_driver_data(dev);
+ if (drv_data)
+ memcpy(plat, drv_data, sizeof(struct spacemit_sdhci_plat));
+ return sdhci_bind(dev, &plat->mmc, &plat->cfg);
+}
+
+static const struct udevice_id spacemit_sdhci_ids[] = {
+ { .compatible = "spacemit,k1-sdhci" },
+ { }
+};
+
+U_BOOT_DRIVER(spacemit_sdhci_drv) = {
+ .name = "spacemit_sdhci",
+ .id = UCLASS_MMC,
+ .of_match = spacemit_sdhci_ids,
+ .of_to_plat = spacemit_sdhci_of_to_plat,
+ .ops = &spacemit_mmc_ops,
+ .bind = spacemit_sdhci_bind,
+ .probe = spacemit_sdhci_probe,
+ .priv_auto = sizeof(struct spacemit_sdhci_priv),
+ .plat_auto = sizeof(struct spacemit_sdhci_plat),
+};
--
2.51.0
^ permalink raw reply related [flat|nested] 18+ messages in thread* Re: [PATCH v13 2/7] mmc: k1: add sdhci platform driver
2026-09-12 12:36 ` [PATCH v13 2/7] mmc: k1: add sdhci platform driver Eric Chung
@ 2026-09-16 12:40 ` Yixun Lan
2026-09-23 13:23 ` Yixun Lan
0 siblings, 1 reply; 18+ messages in thread
From: Yixun Lan @ 2026-09-16 12:40 UTC (permalink / raw)
To: Peng Fan, Jaehoon Chung
Cc: u-boot-spacemit, u-boot, Eric Chung, Yao Zi, Tom Rini, Tim Ouyang,
Leo Liang, Wei Fu, Scott Bambrough, Huan Zhou, Raymond Mao,
Bastien Curutchet, Anshul Dalal, Siu Ming Tong, Johan Jonker
Hi Peng Fan, Jaehoon Chung,
On 20:36 Sat 12 Sep , Eric Chung wrote:
> Add SDHCI platform driver support for SpacemiT K1 SoC. This driver
> implements the necessary platform-specific operations for the SDHCI
> controller, enabling MMC/SD card functionality on K1-based platforms.
>
> Signed-off-by: Eric Chung <eric.chung@riscstar.com>
>
> ---
> v13:
> - Sync definition values from upstream mmc driver.
> v9:
> - Disable CMD18 (multiple-block read) for SD cards in SPL.
> v6:
> - Remove ".data = 0" in spacemit_sdhci_ids[].
> v5:
> - Remove MMC_CAP_CMD23 as the CMD23 support is now a separate series.
> - Use tabs for macro definition alignment.
> - Use read_poll_timeout().
> - Set pinctrl state based on selected timing mode.
> - Add the definition of SDHC_DLL_REG1_HS400_VAL.
> - Remove the condition based on quirks.
> v4:
> - Add bulk release operations on reset and clock.
> v3:
> - Enable CMD23 in capability.
> v2:
> - Enable ADMA mode support.
> - Use CMD23 for multi-block read/write.
> - Move ASR/AIB register into pinctrl driver.
> - Correct pinctrl state from "fast" to "uhs".
> - Migrate tuning support from the spacemit linux driver.
> ---
> drivers/mmc/Kconfig | 7 +
> drivers/mmc/Makefile | 1 +
> drivers/mmc/spacemit_sdhci.c | 684 +++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 692 insertions(+)
>
Ping mmc maintainer for this patch, would it be Ok if I take this patch via
spacemit's custodian tree [1], if yes, then I'd like to grant an Acked-by
Or, if you guys prefer to take it with mmc tree, then I could handle the rest..
Btw, FYI, I've already pushed for CI testing which looks good [2]
Thank you
Link: https://git.u-boot-project.org/u-boot/custodians/u-boot-spacemit.git [1]
Link: https://git.u-boot-project.org/u-boot/custodians/u-boot-spacemit/-/pipelines/1284 [2]
--
Yixun Lan (dlan)
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v13 2/7] mmc: k1: add sdhci platform driver
2026-09-16 12:40 ` Yixun Lan
@ 2026-09-23 13:23 ` Yixun Lan
0 siblings, 0 replies; 18+ messages in thread
From: Yixun Lan @ 2026-09-23 13:23 UTC (permalink / raw)
To: Peng Fan, Jaehoon Chung
Cc: u-boot-spacemit, u-boot, Eric Chung, Yao Zi, Tom Rini, Tim Ouyang,
Leo Liang, Wei Fu, Scott Bambrough, Huan Zhou, Raymond Mao,
Bastien Curutchet, Anshul Dalal, Siu Ming Tong, Johan Jonker
Hi Peng Fan, Jaehoon Chung,
On 12:40 Wed 16 Sep , Yixun Lan wrote:
> Hi Peng Fan, Jaehoon Chung,
>
> On 20:36 Sat 12 Sep , Eric Chung wrote:
> > Add SDHCI platform driver support for SpacemiT K1 SoC. This driver
> > implements the necessary platform-specific operations for the SDHCI
> > controller, enabling MMC/SD card functionality on K1-based platforms.
> >
> > Signed-off-by: Eric Chung <eric.chung@riscstar.com>
> >
> > ---
> > v13:
> > - Sync definition values from upstream mmc driver.
> > v9:
> > - Disable CMD18 (multiple-block read) for SD cards in SPL.
> > v6:
> > - Remove ".data = 0" in spacemit_sdhci_ids[].
> > v5:
> > - Remove MMC_CAP_CMD23 as the CMD23 support is now a separate series.
> > - Use tabs for macro definition alignment.
> > - Use read_poll_timeout().
> > - Set pinctrl state based on selected timing mode.
> > - Add the definition of SDHC_DLL_REG1_HS400_VAL.
> > - Remove the condition based on quirks.
> > v4:
> > - Add bulk release operations on reset and clock.
> > v3:
> > - Enable CMD23 in capability.
> > v2:
> > - Enable ADMA mode support.
> > - Use CMD23 for multi-block read/write.
> > - Move ASR/AIB register into pinctrl driver.
> > - Correct pinctrl state from "fast" to "uhs".
> > - Migrate tuning support from the spacemit linux driver.
> > ---
> > drivers/mmc/Kconfig | 7 +
> > drivers/mmc/Makefile | 1 +
> > drivers/mmc/spacemit_sdhci.c | 684 +++++++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 692 insertions(+)
> >
>
> Ping mmc maintainer for this patch, would it be Ok if I take this patch via
> spacemit's custodian tree [1], if yes, then I'd like to grant an Acked-by
>
> Or, if you guys prefer to take it with mmc tree, then I could handle the rest..
>
> Btw, FYI, I've already pushed for CI testing which looks good [2]
>
Ping again, otherwise I'd go ahead and proceed via spacemit custodian
tree
> Thank you
>
> Link: https://git.u-boot-project.org/u-boot/custodians/u-boot-spacemit.git [1]
> Link: https://git.u-boot-project.org/u-boot/custodians/u-boot-spacemit/-/pipelines/1284 [2]
>
--
Yixun Lan (dlan)
^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH v13 3/7] dts: k1: enable mmc devices in SPL
2026-09-12 12:36 [PATCH v13 0/7] spacemit mmc driver Eric Chung
2026-09-12 12:36 ` [PATCH v13 1/7] spacemit: k1: select boot device via config registers Eric Chung
2026-09-12 12:36 ` [PATCH v13 2/7] mmc: k1: add sdhci platform driver Eric Chung
@ 2026-09-12 12:36 ` Eric Chung
2026-09-12 12:36 ` [PATCH v13 4/7] configs: k1: enable SD and eMMC support Eric Chung
` (5 subsequent siblings)
8 siblings, 0 replies; 18+ messages in thread
From: Eric Chung @ 2026-09-12 12:36 UTC (permalink / raw)
To: u-boot-spacemit, u-boot, Yao Zi, u-boot
Cc: Tom Rini, Tim Ouyang, Leo Liang, Wei Fu, Scott Bambrough,
Huan Zhou, Eric Chung, Raymond Mao, Peng Fan, Jaehoon Chung,
Bastien Curutchet, Anshul Dalal, Siu Ming Tong, Johan Jonker
Enable eMMC and SD device nodes in SPL stage. And set the
bus frequency for mmc device nodes.
Remove the redundant device nodes that are delcared in upstream
DTS files.
Signed-off-by: Eric Chung <eric.chung@riscstar.com>
---
arch/riscv/dts/k1-bananapi-f3-u-boot.dtsi | 12 ++-
arch/riscv/dts/k1-musepi-pro-u-boot.dtsi | 136 +++---------------------------
2 files changed, 21 insertions(+), 127 deletions(-)
diff --git a/arch/riscv/dts/k1-bananapi-f3-u-boot.dtsi b/arch/riscv/dts/k1-bananapi-f3-u-boot.dtsi
index 7f9443d69510..3077cdee55d7 100644
--- a/arch/riscv/dts/k1-bananapi-f3-u-boot.dtsi
+++ b/arch/riscv/dts/k1-bananapi-f3-u-boot.dtsi
@@ -50,7 +50,6 @@
&i2c2 {
bootph-pre-ram;
- resets = <&syscon_apbc RESET_TWSI2>;
eeprom@50 {
bootph-pre-ram;
@@ -65,7 +64,6 @@
*/
&i2c8 {
bootph-pre-ram;
- resets = <&syscon_apbc RESET_TWSI8>;
pmic@41 {
bootph-pre-ram;
@@ -89,6 +87,16 @@
};
};
+&emmc {
+ bootph-pre-ram;
+ max-frequency = <204800000>;
+};
+
+&sdhci0 {
+ bootph-pre-ram;
+ max-frequency = <204800000>;
+};
+
&binman {
u-boot-spl-ddr {
type = "section";
diff --git a/arch/riscv/dts/k1-musepi-pro-u-boot.dtsi b/arch/riscv/dts/k1-musepi-pro-u-boot.dtsi
index 8a9a2a09de99..d6299c96949d 100644
--- a/arch/riscv/dts/k1-musepi-pro-u-boot.dtsi
+++ b/arch/riscv/dts/k1-musepi-pro-u-boot.dtsi
@@ -76,42 +76,15 @@
&i2c2 {
bootph-pre-ram;
- status = "okay";
- pinctrl-0 = <&i2c2_0_cfg>;
- pinctrl-names = "default";
- resets = <&syscon_apbc RESET_TWSI2>;
eeprom@50 {
bootph-pre-ram;
status = "okay";
- compatible = "atmel,24c02";
- reg = <0x50>;
- vcc-supply = <&buck3_1v8>; /* EEPROM_VCC1V8 */
- pagesize = <16>;
- read-only;
- size = <256>;
-
- nvmem-layout {
- compatible = "onie,tlv-layout";
-
- mac-address {
- #nvmem-cell-cells = <1>;
- };
-
- num-macs {
- };
-
- serial-number {
- };
- };
};
};
&i2c8 {
bootph-pre-ram;
- pinctrl-0 = <&i2c8_cfg>;
- pinctrl-names = "default";
- resets = <&syscon_apbc RESET_TWSI8>;
status = "okay";
pmic@41 {
@@ -125,130 +98,43 @@
buck1 {
bootph-pre-ram;
regulator-name = "vdd_core";
- regulator-min-microvolt = <500000>;
- regulator-max-microvolt = <3450000>;
- regulator-ramp-delay = <5000>;
- regulator-always-on;
- };
-
- buck2 {
- regulator-min-microvolt = <500000>;
- regulator-max-microvolt = <3450000>;
- regulator-ramp-delay = <5000>;
- regulator-always-on;
};
buck3_1v8: buck3 {
bootph-pre-ram;
regulator-name = "vdd_1v8";
- regulator-min-microvolt = <500000>;
- regulator-max-microvolt = <1800000>;
- regulator-ramp-delay = <5000>;
- regulator-always-on;
- };
-
- buck4 {
- regulator-min-microvolt = <500000>;
- regulator-max-microvolt = <3300000>;
- regulator-ramp-delay = <5000>;
- regulator-always-on;
- };
-
- buck5 {
- regulator-min-microvolt = <500000>;
- regulator-max-microvolt = <3450000>;
- regulator-ramp-delay = <5000>;
- regulator-always-on;
- };
-
- buck6 {
- regulator-min-microvolt = <500000>;
- regulator-max-microvolt = <3450000>;
- regulator-ramp-delay = <5000>;
- regulator-always-on;
};
aldo1 {
bootph-pre-ram;
regulator-name = "vdd_1v8_mmc";
- regulator-min-microvolt = <500000>;
- regulator-max-microvolt = <3400000>;
- regulator-boot-on;
- };
-
- aldo2 {
- regulator-min-microvolt = <500000>;
- regulator-max-microvolt = <3400000>;
- };
-
- aldo3 {
- regulator-min-microvolt = <500000>;
- regulator-max-microvolt = <3400000>;
};
- aldo4 {
- regulator-min-microvolt = <500000>;
- regulator-max-microvolt = <3400000>;
- };
-
- dldo1 {
- regulator-min-microvolt = <500000>;
- regulator-max-microvolt = <3400000>;
- regulator-boot-on;
- };
-
- dldo2 {
- regulator-min-microvolt = <500000>;
- regulator-max-microvolt = <3400000>;
- };
-
- dldo3 {
- regulator-min-microvolt = <500000>;
- regulator-max-microvolt = <3400000>;
- };
-
- dldo4 {
- regulator-min-microvolt = <500000>;
- regulator-max-microvolt = <3400000>;
- regulator-always-on;
- };
-
- dldo5 {
- regulator-min-microvolt = <500000>;
- regulator-max-microvolt = <3400000>;
- };
-
- dldo6 {
- regulator-min-microvolt = <500000>;
- regulator-max-microvolt = <3400000>;
- regulator-always-on;
- };
-
- dldo7 {
- regulator-min-microvolt = <500000>;
- regulator-max-microvolt = <3400000>;
- };
};
};
};
&qspi {
bootph-pre-ram;
- pinctrl-names = "default";
- pinctrl-0 = <&qspi_cfg>;
status = "okay";
flash@0 {
bootph-pre-ram;
- compatible = "jedec,spi-nor";
- reg = <0>;
- spi-max-frequency = <26500000>;
- m25p,fast-read;
- broken-flash-reset;
status = "okay";
};
};
+&emmc {
+ bootph-pre-ram;
+ max-frequency = <204800000>;
+};
+
+&sdhci0 {
+ bootph-pre-ram;
+ cd-gpios = <&gpio K1_GPIO(80) (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
+ max-frequency = <204800000>;
+};
+
&binman {
u-boot-spl-ddr {
type = "section";
--
2.51.0
^ permalink raw reply related [flat|nested] 18+ messages in thread* [PATCH v13 4/7] configs: k1: enable SD and eMMC support
2026-09-12 12:36 [PATCH v13 0/7] spacemit mmc driver Eric Chung
` (2 preceding siblings ...)
2026-09-12 12:36 ` [PATCH v13 3/7] dts: k1: enable mmc devices in SPL Eric Chung
@ 2026-09-12 12:36 ` Eric Chung
2026-09-12 12:36 ` [PATCH v13 5/7] MAINTAINER: update Spacemit K1 entry Eric Chung
` (4 subsequent siblings)
8 siblings, 0 replies; 18+ messages in thread
From: Eric Chung @ 2026-09-12 12:36 UTC (permalink / raw)
To: u-boot-spacemit, u-boot, Yao Zi, u-boot
Cc: Tom Rini, Tim Ouyang, Leo Liang, Wei Fu, Scott Bambrough,
Huan Zhou, Eric Chung, Raymond Mao, Peng Fan, Jaehoon Chung,
Bastien Curutchet, Anshul Dalal, Siu Ming Tong, Johan Jonker
Enable high-speed MMC modes.
Signed-off-by: Eric Chung <eric.chung@riscstar.com>
---
v7:
- Remove the change on MAINTAINERS.
- Force DM to use alias by CONFIG_DM_SEQ_ALIAS. Since the sequence
of mmc devices in DTS are inverted by alias.
v5:
- Remove ADMA support since it depends on CMD23 support.
- Enable PINCONF support for related power source setting.
v2:
- Enable ADMA support.
- Enable SYSCON support.
---
configs/spacemit_k1_defconfig | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/configs/spacemit_k1_defconfig b/configs/spacemit_k1_defconfig
index 0604c2feefc1..5f9923c7f470 100644
--- a/configs/spacemit_k1_defconfig
+++ b/configs/spacemit_k1_defconfig
@@ -23,6 +23,7 @@ CONFIG_DEBUG_UART_BASE=0xd4017000
CONFIG_DEBUG_UART_CLOCK=14700000
CONFIG_TARGET_SPACEMIT_K1=y
CONFIG_ARCH_RV64I=y
+CONFIG_RISCV_ISA_ZICBOM=y
CONFIG_RISCV_SMODE=y
CONFIG_SPL_RISCV_MMODE=y
# CONFIG_SPL_SMP is not set
@@ -48,6 +49,7 @@ CONFIG_SPL_CMD_TLV_EEPROM=y
CONFIG_OF_UPSTREAM=y
CONFIG_ENV_OVERWRITE=y
CONFIG_SPL_REGMAP=y
+CONFIG_SYSCON=y
CONFIG_SPL_SYSCON=y
CONFIG_CLK=y
CONFIG_CLK_CCF=y
@@ -61,6 +63,7 @@ CONFIG_MISC=y
CONFIG_I2C_EEPROM=y
CONFIG_SPL_I2C_EEPROM=y
CONFIG_PINCTRL=y
+CONFIG_PINCONF=y
CONFIG_PINCTRL_SPACEMIT_K1=y
CONFIG_GPIO=y
CONFIG_DM_GPIO=y
@@ -87,9 +90,28 @@ CONFIG_SPI_FLASH_WINBOND=y
CONFIG_SPI_MEM=y
CONFIG_SYS_SPI_U_BOOT_OFFS=0x000a0000
CONFIG_CMD_SPI=y
+CONFIG_DM_SEQ_ALIAS=y
+CONFIG_MMC=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_SPACEMIT=y
+CONFIG_MMC_IO_VOLTAGE=y
+CONFIG_MMC_HS200_SUPPORT=y
+CONFIG_MMC_HS400_SUPPORT=y
+CONFIG_MMC_HS400_ES_SUPPORT=y
+CONFIG_SUPPORT_EMMC_BOOT=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION=0x4
+CONFIG_CMD_MMC=y
+CONFIG_CMD_MEMINFO=y
+CONFIG_CMD_MEMINFO_MAP=y
+CONFIG_EFI_PARTITION=y
CONFIG_SPL_SPI=y
CONFIG_SPL_DM_SPI=y
CONFIG_SPL_DM_SPI_FLASH=y
CONFIG_SPL_SPI_LOAD=y
CONFIG_SPL_SPI_FLASH_TINY=y
CONFIG_SPL_SPI_FLASH_SUPPORT=y
+CONFIG_SPL_BOARD_INIT=y
+CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_SPL_MMC=y
+CONFIG_SPL_SYS_MMCSD_RAW_MODE=y
--
2.51.0
^ permalink raw reply related [flat|nested] 18+ messages in thread* [PATCH v13 5/7] MAINTAINER: update Spacemit K1 entry
2026-09-12 12:36 [PATCH v13 0/7] spacemit mmc driver Eric Chung
` (3 preceding siblings ...)
2026-09-12 12:36 ` [PATCH v13 4/7] configs: k1: enable SD and eMMC support Eric Chung
@ 2026-09-12 12:36 ` Eric Chung
2026-09-12 12:36 ` [PATCH v13 6/7] doc: spacemit: flash on K1 SoC based boards Eric Chung
` (3 subsequent siblings)
8 siblings, 0 replies; 18+ messages in thread
From: Eric Chung @ 2026-09-12 12:36 UTC (permalink / raw)
To: u-boot-spacemit, u-boot, Yao Zi, u-boot
Cc: Tom Rini, Tim Ouyang, Leo Liang, Wei Fu, Scott Bambrough,
Huan Zhou, Eric Chung, Raymond Mao, Peng Fan, Jaehoon Chung,
Bastien Curutchet, Anshul Dalal, Siu Ming Tong, Johan Jonker
Update the maintainer for Spacemit K1 from Guodong to Eric.
Add mmc driver to maintained files.
Signed-off-by: Eric Chung <eric.chung@riscstar.com>
---
v7:
- Add mmc driver to maintained files.
v4:
- Update the maintainer.
---
board/spacemit/k1/MAINTAINERS | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/board/spacemit/k1/MAINTAINERS b/board/spacemit/k1/MAINTAINERS
index 32d47ecc8f1e..4b2bc4ecfc10 100644
--- a/board/spacemit/k1/MAINTAINERS
+++ b/board/spacemit/k1/MAINTAINERS
@@ -1,6 +1,6 @@
BananaPi F3
M: Huan Zhou <pericycle.cc@gmail.com>
-M: Guodong Xu <guodong.xu@riscstar.com>
+M: Eric Chung <eric.chung@riscstar.com>
L: u-boot-spacemit@groups.io
S: Maintained
F: arch/riscv/dts/k1-*-u-boot.dtsi
@@ -9,6 +9,7 @@ F: configs/spacemit_k1_defconfig
F: doc/board/spacemit/bananapi-f3.rst
F: drivers/gpio/spacemit_gpio.c
F: drivers/i2c/k1_i2c.c
+F: drivers/mmc/spacemit_sdhci.c
F: drivers/pinctrl/spacemit/
F: drivers/power/pmic/pmic_spacemit_p1.c
F: drivers/power/regulator/spacemit_p1_regulator.c
--
2.51.0
^ permalink raw reply related [flat|nested] 18+ messages in thread* [PATCH v13 6/7] doc: spacemit: flash on K1 SoC based boards
2026-09-12 12:36 [PATCH v13 0/7] spacemit mmc driver Eric Chung
` (4 preceding siblings ...)
2026-09-12 12:36 ` [PATCH v13 5/7] MAINTAINER: update Spacemit K1 entry Eric Chung
@ 2026-09-12 12:36 ` Eric Chung
2026-09-12 12:37 ` [PATCH v13 7/7] spacemit: k1: fix product name detection and DTB matching in SPL Eric Chung
` (2 subsequent siblings)
8 siblings, 0 replies; 18+ messages in thread
From: Eric Chung @ 2026-09-12 12:36 UTC (permalink / raw)
To: u-boot-spacemit, u-boot, Yao Zi, u-boot
Cc: Tom Rini, Tim Ouyang, Leo Liang, Wei Fu, Scott Bambrough,
Huan Zhou, Eric Chung, Raymond Mao, Peng Fan, Jaehoon Chung,
Bastien Curutchet, Anshul Dalal, Siu Ming Tong, Johan Jonker
Add document on how to flash images into eMMC of K1 SoC based boards.
Signed-off-by: Eric Chung <eric.chung@riscstar.com>
---
v13:
- Only flash the minimized partitions for SD boot.
v9:
- Add to generate the partition table of SD card.
v3:
- Add document on how to flash images into SD card.
---
board/spacemit/k1/MAINTAINERS | 2 +-
doc/board/spacemit/index.rst | 1 +
doc/board/spacemit/k1-mmc.rst | 268 ++++++++++++++++++++++++++++++++++++++++++
3 files changed, 270 insertions(+), 1 deletion(-)
diff --git a/board/spacemit/k1/MAINTAINERS b/board/spacemit/k1/MAINTAINERS
index 4b2bc4ecfc10..e12288a206e0 100644
--- a/board/spacemit/k1/MAINTAINERS
+++ b/board/spacemit/k1/MAINTAINERS
@@ -6,7 +6,7 @@ S: Maintained
F: arch/riscv/dts/k1-*-u-boot.dtsi
F: board/spacemit/k1/
F: configs/spacemit_k1_defconfig
-F: doc/board/spacemit/bananapi-f3.rst
+F: doc/board/spacemit/
F: drivers/gpio/spacemit_gpio.c
F: drivers/i2c/k1_i2c.c
F: drivers/mmc/spacemit_sdhci.c
diff --git a/doc/board/spacemit/index.rst b/doc/board/spacemit/index.rst
index a5e35ee12ab6..71854e5735bd 100644
--- a/doc/board/spacemit/index.rst
+++ b/doc/board/spacemit/index.rst
@@ -6,5 +6,6 @@ SpacemiT
:maxdepth: 1
bananapi-f3
+ k1-mmc
k1-spl
diff --git a/doc/board/spacemit/k1-mmc.rst b/doc/board/spacemit/k1-mmc.rst
new file mode 100644
index 000000000000..4f35e836fcfd
--- /dev/null
+++ b/doc/board/spacemit/k1-mmc.rst
@@ -0,0 +1,268 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+SpacemiT K1 eMMC and SD Card Boot Guide
+=======================================
+
+This guide covers two separate methods for booting and flashing U-Boot on
+SpacemiT K1 based boards:
+
+1. **eMMC Flash**: Flashing U-Boot and SPL images to eMMC via USB fastboot.
+2. **SD Card Boot**: Creating a bootable Bianbu SD card and optionally
+ replacing U-Boot on the card.
+
+Tested boards: Banana Pi BPI-F3, MusePi Pro.
+
+
+Chapter 1: eMMC Flash (U-Boot via USB Fastboot)
+===============================================
+
+SpacemiT K1 U-Boot Flash Guide
+==============================
+
+This guide explains how to flash U-Boot on SpacemiT K1 based boards. It covers
+flashing images via USB fastboot.
+
+.. note::
+
+ This procedure flashes images to eMMC over USB fastboot. The fastboot
+ function is not enabled in our SPL yet, so the download stage runs the
+ SpacemiT released SPL; our built FSBL.bin and fit.itb are the images
+ written to eMMC and used on the next normal boot.
+
+Prerequisites to flash
+~~~~~~~~~~~~~~~~~~~~~~
+
+- A SpacemiT K1 board with USB Type-C and UART access
+- USB-to-UART adapter (3.3V TTL)
+- ``minicom`` or equivalent serial terminal, configured at 115200 8N1
+- ``fastboot`` and ``flashserver`` tool on the host
+
+Hardware Setup
+~~~~~~~~~~~~~~
+
+Refer to k1-spl.rst.
+
+Flash images on eMMC
+~~~~~~~~~~~~~~~~~~~~
+
+**1. Obtain the release images**
+
+Get the release package from Spacemit website. It contains SPL image, and so on.
+
+https://archive.spacemit.com/image/k1/version/bianbu/v2.3.3/Bianbu-Minimal-K1-V2.3.3-20260128183217.zip
+
+Unzip images and store them into a directory.
+
+**2. Obtain flashserver tool**
+
+Get ``flashserver`` from Spacemit website.
+
+.. code-block:: bash
+
+ $wget https://cdn-resource.spacemit.com/file/flash/flashserver
+ $chmod +x flashserver
+ $mv flashserver {flash image path}/
+
+**3. Copy built SPL and U-Boot images**
+
+Build U-Boot as mentioned in k1-spl.rst. Create a new directory to save.
+The official u-boot.itb is used to download images. So the built U-Boot should
+not replace the official one.
+
+.. code-block:: bash
+
+ $mkdir {flash image path}/build
+ $cd {flash image path}
+ $ln -sf {path to FSBL.bin} ./build/
+ $ln -sf {path to u-boot.itb} ./build/fit.itb
+
+``{path to FSBL.bin}`` is the signed FSBL produced by ``fsbl.sh`` in
+k1-spl.rst, e.g. ``~/uboot-2022.10/spl_bin/FSBL.bin``.
+``{path to u-boot.itb}`` is the U-Boot build output, e.g.
+``~/u-boot/u-boot.itb``.
+
+**4. Update configuration files**
+
+The ``partition_2M.json`` and ``partition_universal.json`` files come from
+the release package. Patch the ``fsbl`` and ``uboot`` entries to point at
+the images staged under ``build/`` (pick the layout that matches your eMMC):
+
+.. code-block:: diff
+
+ diff -puNr bianbu-25/partition_2M.json clean/partition_2M.json
+ --- bianbu-25/partition_2M.json 2026-03-02 11:55:58.631116807 +0800
+ +++ clean/partition_2M.json 2026-05-20 11:25:21.683801401 +0800
+ @@ -13,7 +13,7 @@
+ "name": "fsbl",
+ "offset": "128K",
+ "size": "256K",
+ - "image": "factory/FSBL.bin"
+ + "image": "build/FSBL.bin"
+ },
+ {
+ "name": "env",
+ @@ -31,7 +31,7 @@
+ "name": "uboot",
+ "offset": "640K",
+ "size": "-",
+ - "image": "u-boot.itb"
+ + "image": "build/fit.itb"
+ }
+ ]
+ }
+ diff -puNr bianbu-25/partition_universal.json clean/partition_universal.json
+ --- bianbu-25/partition_universal.json 2026-03-02 11:55:58.642116862 +0800
+ +++ clean/partition_universal.json 2026-05-20 11:26:23.932581853 +0800
+ @@ -14,7 +14,7 @@
+ "name": "fsbl",
+ "offset": "128K",
+ "size": "256K",
+ - "image": "factory/FSBL.bin"
+ + "image": "build/FSBL.bin"
+ },
+ {
+ "name": "env",
+ @@ -32,7 +32,7 @@
+ "name": "uboot",
+ "offset": "2M",
+ "size": "2M",
+ - "image": "u-boot.itb"
+ + "image": "build/fit.itb"
+ },
+ {
+ "name": "bootfs",
+
+Deploying via USB Fastboot
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+To enter BootROM fastboot mode:
+
+1. Power off the board by unplugging its power supply.
+2. **Press and hold** the FDL button (called "Boot Key" on some boards;
+ see the board layout above for the BPI-F3).
+3. While holding the button, use a USB cable to connect the OTG port to
+ your host. This cable is also used by fastboot to upload the firmware.
+4. Release the button.
+
+On the host, ``fastboot devices`` should list the board::
+
+ dfu-device DFU download
+
+The serial console shows the BootROM's USB download handler trace,
+including a line like::
+
+ usb2d_initialize : enter
+
+This indicates the board is ready to accept an image via USB.
+
+.. tip::
+
+ If you are worried about insufficient USB power, you can first plug
+ in the power, then release the button, and then plug in the USB
+ cable.
+
+On the host:
+
+.. code-block:: console
+
+ $sudo ./flashserver
+
+When ``flashserver`` is running, it lists the detected fastboot devices.
+Enter the corresponding number to select one.
+
+
+Chapter 2: SD Card Boot
+=======================
+
+
+SpacemiT K1 Bianbu SD Card Image Flashing and U-Boot Update Guide
+==================================================================
+
+This guide explains how to prepare a bootable SD card with Bianbu OS for
+SpacemiT K1 based boards and how to replace the U-Boot binary on the SD
+card with a custom build.
+
+Prerequisites to boot
+~~~~~~~~~~~~~~~~~~~~~
+
+- A SpacemiT K1 based development board
+- A microSD card (at least 4GB capacity recommended)
+- A card reader for your host computer
+- A Linux host system (for ``dd``, ``sgdisk``, ``lsblk`` commands)
+- The Bianbu release package from
+ <https://archive.spacemit.com/image/k1/version/bianbu/v2.3.3/Bianbu-Minimal-K1-V2.3.3-20260128183217.zip>
+- A custom ``FSBL.bin`` and ``u-boot.itb`` file to be written to the U-Boot
+ partition
+
+Prepare the SD Card & the image
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+**1. Obtain the release images**
+
+Unpack the release package to get the image files. Replace the ``FSBL.bin``
+and ``u-boot.itb`` with your custom builds.
+
+**2. Identify the SD card device**
+
+Insert the microSD card into your card reader, then run:
+
+.. code-block:: console
+
+ $ lsblk
+
+Compare the output before and after inserting the card to identify
+the new device. It will typically appear as ``/dev/sdb``, ``/dev/sdc``,
+or ``/dev/mmcblk0``.
+
+**3. Write the image to the SD card**
+
+Run ``sgdisk`` to generate the partition table, then use ``dd`` to write
+the images to the corresponding partitions.
+
+.. code-block:: console
+
+ $sudo sgdisk -o /dev/sdb
+ $sudo sgdisk -a 128 \
+ -n 1:256:767 -t 1:8300 \
+ -n 2:768:895 -t 2:8300 \
+ -n 3:2048:4095 -t 3:8300 \
+ -n 4:4096:8191 -t 4:8300 \
+ -n 5:8192:532479 -t 5:8300 \
+ -n 6:532480:4726783 -t 6:8300 \
+ /dev/sdb
+ $sudo dd if=FSBL.bin of=/dev/sdb1 bs=512 seek=0 status=progress
+ $sudo dd if=fw_dynamic.itb of=/dev/sdb3 bs=512 seek=0 status=progress
+ $sudo dd if=u-boot.itb of=/dev/sdb4 bs=512 seek=0 status=progress
+
+The SD card is now ready as a bootable system disk.
+
+Understanding the SD Card Partition Layout
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The role of each partition:
+
++----------+----------+------------------------------------+
+| Partition| Size | Purpose |
++==========+==========+====================================+
+| ``sdb1`` | 256 KB | FSBL (First Stage Bootloader) |
++----------+----------+------------------------------------+
+| ``sdb2`` | 64 KB | ENV |
++----------+----------+------------------------------------+
+| ``sdb3`` | 1 MB | OpenSBI |
++----------+----------+------------------------------------+
+| ``sdb4`` | 2 MB | U-Boot binary (``u-boot.itb``) |
++----------+----------+------------------------------------+
+| ``sdb5`` | 256 MB | Boot partition (kernel) |
++----------+----------+------------------------------------+
+| ``sdb6`` | 2 GB | Root filesystem (ext4) |
++----------+----------+------------------------------------+
+
+
+Booting and Testing
+~~~~~~~~~~~~~~~~~~~
+
+Insert the SD card into the development board, connect the serial
+console (115200 8N1), and power on the board.
+
+- If the board boots successfully, the new device tree or U-Boot image
+ is compatible with your hardware.
--
2.51.0
^ permalink raw reply related [flat|nested] 18+ messages in thread* [PATCH v13 7/7] spacemit: k1: fix product name detection and DTB matching in SPL
2026-09-12 12:36 [PATCH v13 0/7] spacemit mmc driver Eric Chung
` (5 preceding siblings ...)
2026-09-12 12:36 ` [PATCH v13 6/7] doc: spacemit: flash on K1 SoC based boards Eric Chung
@ 2026-09-12 12:37 ` Eric Chung
2026-10-02 12:58 ` Andre Heider
2026-09-16 12:27 ` [PATCH v13 0/7] spacemit mmc driver Yixun Lan
2026-09-29 10:14 ` Yixun Lan
8 siblings, 1 reply; 18+ messages in thread
From: Eric Chung @ 2026-09-12 12:37 UTC (permalink / raw)
To: u-boot-spacemit, u-boot, Yao Zi, u-boot
Cc: Tom Rini, Tim Ouyang, Leo Liang, Wei Fu, Scott Bambrough,
Huan Zhou, Eric Chung, Raymond Mao, Peng Fan, Jaehoon Chung,
Bastien Curutchet, Anshul Dalal, Siu Ming Tong, Johan Jonker
Use a table to handle DTB matching.
Signed-off-by: Eric Chung <eric.chung@riscstar.com>
---
v7:
- Abandon to load product name from ENV.
v6:
- Rebased onto latest upstream. Cleaned up board_fit_config_name_match()
to maintain consistentcy with v5.
---
board/spacemit/k1/spl.c | 50 +++++++++++++++++++++++++++++++------------------
1 file changed, 32 insertions(+), 18 deletions(-)
diff --git a/board/spacemit/k1/spl.c b/board/spacemit/k1/spl.c
index 374922573c98..ef23db62d6cc 100644
--- a/board/spacemit/k1/spl.c
+++ b/board/spacemit/k1/spl.c
@@ -141,6 +141,15 @@ static void i2c_early_init(void)
}
}
+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" },
+};
+
int read_product_name(char *name, int size)
{
u8 eeprom_data[TLV_TOTAL_LEN_MAX], *p;
@@ -174,6 +183,27 @@ int read_product_name(char *name, int size)
return -ENOENT;
}
+static void fixup_product_name(void)
+{
+ char fdt_name[I2C_BUF_SIZE];
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(k1_board_map); i++) {
+ memset(fdt_name, 0, I2C_BUF_SIZE);
+ if (!strncmp(product_name, k1_board_map[i].eeprom_name,
+ strlen(k1_board_map[i].eeprom_name))) {
+ snprintf(fdt_name, I2C_BUF_SIZE, "%s",
+ k1_board_map[i].fit_name);
+ break;
+ }
+ }
+ if (fdt_name[0] == '\0') {
+ /* set default board name */
+ sprintf(fdt_name, CONFIG_DEFAULT_DEVICE_TREE);
+ }
+ memcpy(product_name, fdt_name, I2C_BUF_SIZE);
+}
+
static void clk_early_init(void)
{
struct udevice *dev;
@@ -417,6 +447,7 @@ void board_init_f(ulong dummy)
log_info("Fail to detect board:%d\n", ret);
else
log_info("Get board name:%s\n", product_name);
+ fixup_product_name();
pmic_init();
ddr_early_init();
@@ -459,24 +490,7 @@ void spl_board_init(void)
int board_fit_config_name_match(const char *name)
{
- char fdt_name[I2C_BUF_SIZE];
- int i;
-
- memset(fdt_name, 0, I2C_BUF_SIZE);
- if (!strncmp(product_name, "k1-x_", 5)) {
- snprintf(fdt_name, I2C_BUF_SIZE, "%s-%s", "k1",
- &product_name[5]);
- }
- if (fdt_name[0] == '\0') {
- /* set default board name */
- sprintf(fdt_name, "k1-musepi-pro");
- }
- for (i = 0; i < I2C_BUF_SIZE; i++) {
- if (fdt_name[i] == '\0')
- break;
- fdt_name[i] = tolower(fdt_name[i]);
- }
- if (!strcmp(name, fdt_name))
+ if (!strcmp(name, product_name))
return 0;
return -ENOENT;
}
--
2.51.0
^ permalink raw reply related [flat|nested] 18+ messages in thread* Re: [PATCH v13 7/7] spacemit: k1: fix product name detection and DTB matching in SPL
2026-09-12 12:37 ` [PATCH v13 7/7] spacemit: k1: fix product name detection and DTB matching in SPL Eric Chung
@ 2026-10-02 12:58 ` Andre Heider
2026-10-05 4:01 ` Eric Chung
0 siblings, 1 reply; 18+ messages in thread
From: Andre Heider @ 2026-10-02 12:58 UTC (permalink / raw)
To: Eric Chung, u-boot-spacemit, u-boot, Yao Zi
Cc: Tom Rini, Tim Ouyang, Leo Liang, Wei Fu, Scott Bambrough,
Huan Zhou, Raymond Mao, Peng Fan, Jaehoon Chung,
Bastien Curutchet, Anshul Dalal, Siu Ming Tong, Johan Jonker
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
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH v13 7/7] spacemit: k1: fix product name detection and DTB matching in SPL
2026-10-02 12:58 ` Andre Heider
@ 2026-10-05 4:01 ` Eric Chung
2026-10-05 7:23 ` Andre Heider
0 siblings, 1 reply; 18+ messages in thread
From: Eric Chung @ 2026-10-05 4:01 UTC (permalink / raw)
To: Andre Heider
Cc: u-boot-spacemit, u-boot, Yao Zi, Tom Rini, Tim Ouyang, Leo Liang,
Wei Fu, Scott Bambrough, Huan Zhou, Raymond Mao, Peng Fan,
Jaehoon Chung, Bastien Curutchet, Anshul Dalal, Siu Ming Tong,
Johan Jonker
On Fri, Oct 2, 2026 at 8:58 PM Andre Heider <a.heider@gmail.com> 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
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH v13 7/7] spacemit: k1: fix product name detection and DTB matching in SPL
2026-10-05 4:01 ` Eric Chung
@ 2026-10-05 7:23 ` Andre Heider
2026-10-05 15:34 ` Eric Chung
0 siblings, 1 reply; 18+ messages in thread
From: Andre Heider @ 2026-10-05 7:23 UTC (permalink / raw)
To: Eric Chung
Cc: u-boot-spacemit, u-boot, Yao Zi, Tom Rini, Tim Ouyang, Leo Liang,
Wei Fu, Scott Bambrough, Huan Zhou, Raymond Mao, Peng Fan,
Jaehoon Chung, Bastien Curutchet, Anshul Dalal, Siu Ming Tong,
Johan Jonker
On 05.10.26 6:01 AM, Eric Chung wrote:
> On Fri, Oct 2, 2026 at 8:58 PM Andre Heider <a.heider@gmail.com> 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
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH v13 7/7] spacemit: k1: fix product name detection and DTB matching in SPL
2026-10-05 7:23 ` Andre Heider
@ 2026-10-05 15:34 ` Eric Chung
2026-10-05 21:33 ` E Shattow
0 siblings, 1 reply; 18+ messages in thread
From: Eric Chung @ 2026-10-05 15:34 UTC (permalink / raw)
To: Andre Heider
Cc: u-boot-spacemit, u-boot, Yao Zi, Tom Rini, Tim Ouyang, Leo Liang,
Wei Fu, Scott Bambrough, Huan Zhou, Raymond Mao, Peng Fan,
Jaehoon Chung, Bastien Curutchet, Anshul Dalal, Siu Ming Tong,
Johan Jonker
On Mon, Oct 5, 2026 at 3:23 PM Andre Heider <a.heider@gmail.com> wrote:
>
> On 05.10.26 6:01 AM, Eric Chung wrote:
> > On Fri, Oct 2, 2026 at 8:58 PM Andre Heider <a.heider@gmail.com> 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.
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH v13 7/7] spacemit: k1: fix product name detection and DTB matching in SPL
2026-10-05 15:34 ` Eric Chung
@ 2026-10-05 21:33 ` E Shattow
2026-10-06 6:57 ` Andre Heider
0 siblings, 1 reply; 18+ messages in thread
From: E Shattow @ 2026-10-05 21:33 UTC (permalink / raw)
To: Eric Chung, Andre Heider
Cc: u-boot-spacemit, u-boot, Yao Zi, Tom Rini, Tim Ouyang, Leo Liang,
Wei Fu, Scott Bambrough, Huan Zhou, Raymond Mao, Peng Fan,
Jaehoon Chung, Bastien Curutchet, Anshul Dalal, Siu Ming Tong,
Johan Jonker
On 10/5/26 08:34, Eric Chung wrote:
> On Mon, Oct 5, 2026 at 3:23 PM Andre Heider <a.heider@gmail.com> wrote:
>>
>> On 05.10.26 6:01 AM, Eric Chung wrote:
>>> On Fri, Oct 2, 2026 at 8:58 PM Andre Heider <a.heider@gmail.com> 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.
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.
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.
-E
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH v13 7/7] spacemit: k1: fix product name detection and DTB matching in SPL
2026-10-05 21:33 ` E Shattow
@ 2026-10-06 6:57 ` Andre Heider
0 siblings, 0 replies; 18+ messages in thread
From: Andre Heider @ 2026-10-06 6:57 UTC (permalink / raw)
To: E Shattow, Eric Chung
Cc: u-boot-spacemit, u-boot, Yao Zi, Tom Rini, Tim Ouyang, Leo Liang,
Wei Fu, Scott Bambrough, Huan Zhou, Raymond Mao, Peng Fan,
Jaehoon Chung, Bastien Curutchet, Anshul Dalal, Siu Ming Tong,
Johan Jonker, Yixun Lan
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 <a.heider@gmail.com> wrote:
>>>
>>> On 05.10.26 6:01 AM, Eric Chung wrote:
>>>> On Fri, Oct 2, 2026 at 8:58 PM Andre Heider <a.heider@gmail.com> 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v13 0/7] spacemit mmc driver
2026-09-12 12:36 [PATCH v13 0/7] spacemit mmc driver Eric Chung
` (6 preceding siblings ...)
2026-09-12 12:37 ` [PATCH v13 7/7] spacemit: k1: fix product name detection and DTB matching in SPL Eric Chung
@ 2026-09-16 12:27 ` Yixun Lan
2026-09-29 10:14 ` Yixun Lan
8 siblings, 0 replies; 18+ messages in thread
From: Yixun Lan @ 2026-09-16 12:27 UTC (permalink / raw)
To: Eric Chung
Cc: u-boot-spacemit, u-boot, Yao Zi, Tom Rini, Tim Ouyang, Leo Liang,
Wei Fu, Scott Bambrough, Huan Zhou, Raymond Mao, Peng Fan,
Jaehoon Chung, Bastien Curutchet, Anshul Dalal, Siu Ming Tong,
Johan Jonker
On 20:36 Sat 12 Sep , Eric Chung wrote:
> This series adds MMC support for the SpacemiT K1: an SDHCI platform
> driver, the SD card device-tree overlay, defconfig options, and SPL
> boot-device selection from the SoC strap/config registers. The SDHCI
> driver is usable in both SPL and U-Boot proper.
>
> A flashing guide (doc/board/spacemit/k1-flash.rst) describes how to
> write images to eMMC.
>
> ---
> Changes in v13:
> - mmc: Sync the definition values from upstream mmc driver.
> - doc: Only flash the minimised partitions for SD boot.
> - Link to v12: https://patch.msgid.link/20260906-m4-v12-0-89eb5a8f879d@riscstar.com
>
> Changes in v12:
> - dts: Drop all upstreamed DTS patches since they're merged now.
> - Link to v11: https://patch.msgid.link/20260905-m4-v11-0-235eacd94fe0@riscstar.com
>
> Changes in v11:
> - spl: Fix the read_boot_mode() that returns both boot mode and boot device.
> - Link to v10: https://patch.msgid.link/20260824-m4-v10-0-5e0adcb1edb9@riscstar.com
>
> Changes in v10:
> - pinctrl: Move all pinctrl patches into a new patch set.
> - Link to v9: https://patch.msgid.link/20260819-m4-v9-0-6e66016392b9@riscstar.com
>
> Changes in v9:
> - spl: Enhance detection on booting from SD.
> - dts: Synched upstream DTS files for K1.
> - doc: Create SD card image from scratch.
> - mmc: Avoid to use CMD18 on SD card in SPL.
> - pinctrl: Drop "fix drive strength configuration".
> - Link to v8: https://patch.msgid.link/20260802-m4-v8-4-e916643205f3@riscstar.com
>
> Changes in v8:
> - doc: Remove SD card.
> - Link to v7: https://patch.msgid.link/20260729-m4-v7-8-2cb04b4fe389@riscstar.com
>
> Changes in v7:
> - env: Drop env support on the mmc series.
> - dts: Sync upstream DTS files for spacemit.
> - pinctrl: Simply clrsetbits_le32() on pull-up/pull-down configuration.
> - spl: Fix DTB matching.
> - Link to v6: https://patch.msgid.link/20260727-m4-v6-0-2f58566d48ca@riscstar.com
>
> Changes in v6:
> - pinctrl: Fix drive strength configuration.
> - pinctrl: Fix pull-up/pull-down configuration.
> - pinctrl: Use dev_read_phandle_with_args() to fetch "spacemit,syscon" instead.
> - spacemit: rebase on latest upstream branch.
> - Link to v5: https://patch.msgid.link/20260722-m4-v5-0-c41a951e5157@riscstar.com
>
> Changes in v5:
> - mmc: Split CMD23 support out.
> - mmc: Use read_poll_timeout().
> - mmc: Set pinctrl state based on selected timing mode.
> - mmc: Remove the condition based on quirks.
> - pinctrl: Fix power source argument.
> - dts: Add missing power source on mmc pins.
> - Link to v4: https://patch.msgid.link/20260707-m4-v4-0-dbd01185f911@riscstar.com
>
> Changes in v4:
> - mmc: Add CMD23 for write.
> - mmc: Fix CMD23 only for CMD18.
> - mmc: Update bulk release operations on reset and clocks for spacemit
> platform driver.
> - MAINTAINER: update the maintainer of Spacemit K1.
> - Link to v3: https://patch.msgid.link/20260705-m4-v3-0-5a9bc7f25fc5@riscstar.com
>
> Changes in v3:
> - pinctrl: Fix "fast" by "uhs".
> - pinctrl: Add syscon dependency.
> - mmc: Fix quick by capability.
> - doc: Add SD boot support.
> - Link to v2: https://lore.kernel.org/u-boot/20260630-m1-v1-0-83f13347b3ba@riscstar.com/T/#m2aba875a2696a7bb9b704618d22ae2fd7f7f5acc
>
> Changes in v2:
> - cmd: drop patches on eminfo & tlv_eeprom.
> - configs: Enable ADMA and SYSCON support.
> - dts: Use vmmc-supply as vqmmc-supply on the SD card node.
> - mmc: k1: Enable ADMA mode support, use CMD23 for multi-block
> read/write, correct pinctrl state from "fast" to "uhs".
> - mmc: sdhci: Add new quirk patch to enable CMD23 for multi-block
> transfers.
> - pinctrl: k1: Add new IO power domain configuration support for
> dual-voltage GPIO banks.
> - spacemit: k1: Use FIELD_GET() to parse boot strap mode.
> - Link to v1: https://lore.kernel.org/u-boot/20260521-k1-spl-mmc-sdcard-v1-0-1bd14b8c4f9f@riscstar.com/
>
> To: u-boot-spacemit@groups.io
> To: u-boot@lists.u-boot-project.org
> To: Yao Zi <me@ziyao.cc>
> Cc: Huan Zhou <pericycle.cc@gmail.com>
> Cc: Eric Chung <eric.chung@riscstar.com>
> Cc: Tom Rini <trini@konsulko.com>
> Cc: Raymond Mao <raymond.mao@riscstar.com>
> Cc: Peng Fan <peng.fan@nxp.com>
> Cc: Jaehoon Chung <jh80.chung@samsung.com>
> Cc: Bastien Curutchet <bastien.curutchet@bootlin.com>
> Cc: Anshul Dalal <anshuld@ti.com>
> Cc: Siu Ming Tong <smtong@axiado.com>
> Cc: Johan Jonker <jbx6244@gmail.com>
> Cc: Tim Ouyang <tim609@andestech.com>
> Cc: Leo Liang <leo.liang@sifive.com>
>
> ---
> Eric Chung (7):
> spacemit: k1: select boot device via config registers
> mmc: k1: add sdhci platform driver
> dts: k1: enable mmc devices in SPL
> configs: k1: enable SD and eMMC support
> MAINTAINER: update Spacemit K1 entry
> doc: spacemit: flash on K1 SoC based boards
> spacemit: k1: fix product name detection and DTB matching in SPL
>
> arch/riscv/dts/k1-bananapi-f3-u-boot.dtsi | 12 +-
> arch/riscv/dts/k1-musepi-pro-u-boot.dtsi | 136 +-----
> board/spacemit/k1/MAINTAINERS | 5 +-
> board/spacemit/k1/spl.c | 148 ++++++-
> configs/spacemit_k1_defconfig | 22 +
> doc/board/spacemit/index.rst | 1 +
> doc/board/spacemit/k1-mmc.rst | 268 ++++++++++++
> drivers/mmc/Kconfig | 7 +
> drivers/mmc/Makefile | 1 +
> drivers/mmc/spacemit_sdhci.c | 684 ++++++++++++++++++++++++++++++
> 10 files changed, 1136 insertions(+), 148 deletions(-)
> ---
For this series, I've tested on Bananapi-F3 board, which works
on both eMMC and SD card, and so with
Tested-by: Yixun Lan <dlan@kernel.org>
Reviewed-by: Yixun Lan <dlan@kernel.org>
--
Yixun Lan (dlan)
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH v13 0/7] spacemit mmc driver
2026-09-12 12:36 [PATCH v13 0/7] spacemit mmc driver Eric Chung
` (7 preceding siblings ...)
2026-09-16 12:27 ` [PATCH v13 0/7] spacemit mmc driver Yixun Lan
@ 2026-09-29 10:14 ` Yixun Lan
8 siblings, 0 replies; 18+ messages in thread
From: Yixun Lan @ 2026-09-29 10:14 UTC (permalink / raw)
To: u-boot-spacemit, u-boot, Yao Zi, Eric Chung
Cc: Yixun Lan, Tom Rini, Tim Ouyang, Leo Liang, Wei Fu,
Scott Bambrough, Huan Zhou, Raymond Mao, Peng Fan, Jaehoon Chung,
Bastien Curutchet, Anshul Dalal, Siu Ming Tong, Johan Jonker
On Sat, 12 Sep 2026 20:36:53 +0800, Eric Chung wrote:
> This series adds MMC support for the SpacemiT K1: an SDHCI platform
> driver, the SD card device-tree overlay, defconfig options, and SPL
> boot-device selection from the SoC strap/config registers. The SDHCI
> driver is usable in both SPL and U-Boot proper.
>
> A flashing guide (doc/board/spacemit/k1-flash.rst) describes how to
> write images to eMMC.
>
> [...]
Applied, thanks!
[1/7] spacemit: k1: select boot device via config registers
https://git.u-boot-project.org/u-boot/custodians/u-boot-spacemit/-/commit/aa3091dcd7012ca77fae5854da62e360a9d4ddeb
[2/7] mmc: k1: add sdhci platform driver
https://git.u-boot-project.org/u-boot/custodians/u-boot-spacemit/-/commit/18e9745c932718335d0a8cf0223a00d216f71272
[3/7] dts: k1: enable mmc devices in SPL
https://git.u-boot-project.org/u-boot/custodians/u-boot-spacemit/-/commit/c8d4129cb9a4ef84fb167324a4fee1b2807e9219
[4/7] configs: k1: enable SD and eMMC support
https://git.u-boot-project.org/u-boot/custodians/u-boot-spacemit/-/commit/f570dfb74e7ddcd4063bec68e3e81a7063179700
[5/7] MAINTAINER: update Spacemit K1 entry
https://git.u-boot-project.org/u-boot/custodians/u-boot-spacemit/-/commit/a75e1ed839a31f8ae9e534fa76167290f1180d94
[6/7] doc: spacemit: flash on K1 SoC based boards
https://git.u-boot-project.org/u-boot/custodians/u-boot-spacemit/-/commit/69d82789fe6fdaea697fa124a934aa5e4a92b3d1
[7/7] spacemit: k1: fix product name detection and DTB matching in SPL
https://git.u-boot-project.org/u-boot/custodians/u-boot-spacemit/-/commit/6f8c134610b9d139ff3e104e4cdba3512c4ee7e1
Best regards,
--
Yixun Lan <dlan@kernel.org>
^ permalink raw reply [flat|nested] 18+ messages in thread