[PATCH v6 00/11] spacemit mmc driver

[PATCH v6 00/11] spacemit mmc driver

[Eric Chung]

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 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.denx.de
To: u-boot@lists.u-boot-project.org
Cc: Huan Zhou <pericycle.cc@gmail.com>
Cc: Tom Rini <trini@konsulko.com>
Cc: Tim Ouyang <tim609@andestech.com>
Cc: Leo Liang <leo.liang@sifive.com>
Cc: Raymond Mao <raymond.mao@riscstar.com>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Cc: Bhimeswararao Matsa <bhimeswararao.matsa@gmail.com>
Cc: Tanmay Kathpalia <tanmay.kathpalia@altera.com>
Cc: Kaustabh Chakraborty <kauschluss@disroot.org>
Cc: Han Xu <han.xu@nxp.com>
Cc: Yanir Levin <yanir.levin@tandemg.com>
Cc: Christoph Stoidner <c.stoidner@phytec.de>
Cc: Balsundar Ponnusamy <balsundar.ponnusamy@altera.com>
Cc: Daniel Palmer <daniel@thingy.jp>
Cc: Anshul Dalal <anshuld@ti.com>
Cc: Bastien Curutchet <bastien.curutchet@bootlin.com>
Cc: Angelo Dureghello <angelo@kernel-space.org>
Cc: Johan Jonker <jbx6244@gmail.com>
Cc: Sam Protsenko <semen.protsenko@linaro.org>
Cc: Guodong Xu <guodong@riscstar.com>
Cc: Yao Zi <me@ziyao.cc>
Cc: Rick Chen <rick@andestech.com>
Cc: Leo <ycliang@andestech.com>
Signed-off-by: Eric Chung <eric.chung@riscstar.com>

---
Eric Chung (11):
      spacemit: k1: select boot device via config registers
      pinctrl: k1: fix drive strength configuration
      pinctrl: k1: fix pull-up/pull-down configuration
      pinctrl: k1: add IO power domain configuration support
      mmc: k1: add sdhci platform driver
      dts: k1: add SD card support in u-boot overlay
      configs: k1: enable SD and eMMC support
      MAINTAINER: update Spacemit K1 entry
      doc: spacemit: flash on K1 SoC based boards
      config: k1: enable ENV support for eMMC
      spacemit: k1: load product name from environment variable

 arch/riscv/dts/k1-bananapi-f3-u-boot.dtsi |  91 +++-
 arch/riscv/dts/k1-musepi-pro-u-boot.dtsi  |  86 +++-
 board/spacemit/k1/MAINTAINERS             |   5 +-
 board/spacemit/k1/spl.c                   | 160 ++++---
 configs/spacemit_k1_defconfig             |  27 +-
 doc/board/spacemit/index.rst              |   1 +
 doc/board/spacemit/k1-mmc.rst             | 320 ++++++++++++++
 drivers/mmc/Kconfig                       |   7 +
 drivers/mmc/Makefile                      |   1 +
 drivers/mmc/spacemit_sdhci.c              | 673 ++++++++++++++++++++++++++++++
 drivers/pinctrl/spacemit/Kconfig          |   2 +-
 drivers/pinctrl/spacemit/pinctrl-k1.c     | 118 +++++-
 12 files changed, 1422 insertions(+), 69 deletions(-)
---
base-commit: b635d43bca429500cb8ef20aa151cb5773b9a8a5
change-id: 20260629-m4-98e01659fefb

Best regards,
--  
Eric Chung <eric.chung@riscstar.com>

[PATCH v6 01/11] spacemit: k1: select boot device via config registers

[Eric Chung]

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>
---
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 | 71 ++++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 70 insertions(+), 1 deletion(-)

diff --git a/board/spacemit/k1/spl.c b/board/spacemit/k1/spl.c
index d749e21a2d5..613e8c4cf02 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,17 @@
 #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 MUX_MODE4		4
 #define EDGE_NONE		BIT(6)
 #define PULL_UP			(6 << 13)       /* bit[15:13] 110 */
@@ -46,6 +58,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;
@@ -354,7 +377,53 @@ void board_init_f(ulong dummy)
 
 u32 spl_boot_device(void)
 {
-	return BOOT_DEVICE_SPI;
+	void __iomem *boot_dev = (void __iomem *)BOOT_DEV_FLAG_REG;
+	void __iomem *boot_strap = (void __iomem *)BOOT_PIN_SEL_REG;
+	u32 mode, sel, ret = 0;
+
+	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;
+		}
+	}
+
+	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

[PATCH v6 02/11] pinctrl: k1: fix drive strength configuration

[Eric Chung]

Fix drive strength configuration by:
- Using FIELD_PREP() to properly set the PAD_DRIVE mask bits
- Not overriding io_type with IO_TYPE_EXTERNAL for external pins
- Returning the pin number instead of 0 from pinmux_property_set
- Removing redundant zero-initialization of the mask variable

Signed-off-by: Eric Chung <eric.chung@riscstar.com>

---
v6:
- Fix drive strength configuration.
---
 drivers/pinctrl/spacemit/pinctrl-k1.c | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/pinctrl/spacemit/pinctrl-k1.c b/drivers/pinctrl/spacemit/pinctrl-k1.c
index a6a22eacac7..6ed511879da 100644
--- a/drivers/pinctrl/spacemit/pinctrl-k1.c
+++ b/drivers/pinctrl/spacemit/pinctrl-k1.c
@@ -9,6 +9,7 @@
 #include <dm/device_compat.h>
 #include <dm/pinctrl.h>
 #include <dm/read.h>
+#include <linux/bitfield.h>
 #include <linux/bitops.h>
 #include <linux/errno.h>
 #include <linux/io.h>
@@ -386,10 +387,12 @@ static int spacemit_pinmux_set(struct udevice *dev, unsigned int pin,
 static int spacemit_pinmux_property_set(struct udevice *dev, u32 pinmux_group)
 {
 	u32 pin, mux;
+	int ret;
 
 	pin = spacemit_dt_get_pin(pinmux_group);
 	mux = spacemit_dt_get_pin_mux(pinmux_group);
-	return spacemit_pinmux_set(dev, pin, mux);
+	ret = spacemit_pinmux_set(dev, pin, mux);
+	return ret ? ret : pin;
 }
 
 static const struct pinconf_param spacemit_pinconf_params[] = {
@@ -406,7 +409,7 @@ static int spacemit_pinconf_set(struct udevice *dev, unsigned int pin_selector,
 	struct spacemit_pinctrl_data *data;
 	struct spacemit_pinctrl_priv *priv = dev_get_priv(dev);
 	void __iomem *addr;
-	u32 mask = 0;
+	u32 mask;
 	unsigned int io_type;
 	u8 ds;
 	bool found;
@@ -433,7 +436,8 @@ static int spacemit_pinconf_set(struct udevice *dev, unsigned int pin_selector,
 		for (i = 0; i < priv->nr_io_pins; i++) {
 			if (priv->io_pins[i].pin != pin_selector)
 				continue;
-			io_type = priv->io_pins[i].io_type;
+			if (priv->io_pins[i].io_type != IO_TYPE_EXTERNAL)
+				io_type = priv->io_pins[i].io_type;
 			break;
 		}
 		if (io_type != IO_TYPE_3V3 && io_type != IO_TYPE_1V8) {
@@ -441,7 +445,7 @@ static int spacemit_pinconf_set(struct udevice *dev, unsigned int pin_selector,
 			return -EINVAL;
 		}
 		ds = spacemit_get_drive_strength(io_type, argument);
-		clrsetbits_le32(addr, PAD_DRIVE, ds);
+		clrsetbits_le32(addr, PAD_DRIVE, FIELD_PREP(PAD_DRIVE, ds));
 		break;
 	case PIN_CONFIG_POWER_SOURCE:
 		for (i = 0, found = false; i < priv->nr_io_pins; i++) {

-- 
2.51.0

[PATCH v6 03/11] pinctrl: k1: fix pull-up/pull-down configuration

[Eric Chung]

Fix pull-up/pull-down configuration to honor the argument parameter:
when argument is non-zero, enable the requested pull direction;
when argument is zero, clear all pull bits to disable.

Signed-off-by: Eric Chung <eric.chung@riscstar.com>

---
v6:
- Fix pull-up/pull-down configuration.
---
 drivers/pinctrl/spacemit/pinctrl-k1.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/spacemit/pinctrl-k1.c b/drivers/pinctrl/spacemit/pinctrl-k1.c
index 6ed511879da..454bc307ba3 100644
--- a/drivers/pinctrl/spacemit/pinctrl-k1.c
+++ b/drivers/pinctrl/spacemit/pinctrl-k1.c
@@ -425,11 +425,17 @@ static int spacemit_pinconf_set(struct udevice *dev, unsigned int pin_selector,
 		break;
 	case PIN_CONFIG_BIAS_PULL_DOWN:
 		mask = PAD_PULLDOWN | PAD_PULLUP | PAD_PULL_EN;
-		clrsetbits_le32(addr, mask, PAD_PULLDOWN | PAD_PULL_EN);
+		if (argument)
+			clrsetbits_le32(addr, mask, PAD_PULLDOWN | PAD_PULL_EN);
+		else
+			clrbits_le32(addr, PAD_PULLDOWN | PAD_PULL_EN);
 		break;
 	case PIN_CONFIG_BIAS_PULL_UP:
 		mask = PAD_PULLDOWN | PAD_PULLUP | PAD_PULL_EN;
-		clrsetbits_le32(addr, mask, PAD_PULLUP | PAD_PULL_EN);
+		if (argument)
+			clrsetbits_le32(addr, mask, PAD_PULLUP | PAD_PULL_EN);
+		else
+			clrbits_le32(addr, PAD_PULLUP | PAD_PULL_EN);
 		break;
 	case PIN_CONFIG_DRIVE_STRENGTH:
 		io_type = IO_TYPE_1V8;

-- 
2.51.0

Re: [PATCH v6 03/11] pinctrl: k1: fix pull-up/pull-down configuration

[Yao Zi]

On Mon, Jul 27, 2026 at 02:59:05PM +0800, Eric Chung wrote:
> Fix pull-up/pull-down configuration to honor the argument parameter:
> when argument is non-zero, enable the requested pull direction;
> when argument is zero, clear all pull bits to disable.

Since this is a bug in a patch that hasn't been merged, please fix it in
place and re-spin the pinctrl/GPIO/SPI-NOR series.

> Signed-off-by: Eric Chung <eric.chung@riscstar.com>
> 
> ---
> v6:
> - Fix pull-up/pull-down configuration.
> ---
>  drivers/pinctrl/spacemit/pinctrl-k1.c | 10 ++++++++--
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/pinctrl/spacemit/pinctrl-k1.c b/drivers/pinctrl/spacemit/pinctrl-k1.c
> index 6ed511879da..454bc307ba3 100644
> --- a/drivers/pinctrl/spacemit/pinctrl-k1.c
> +++ b/drivers/pinctrl/spacemit/pinctrl-k1.c
> @@ -425,11 +425,17 @@ static int spacemit_pinconf_set(struct udevice *dev, unsigned int pin_selector,
>  		break;
>  	case PIN_CONFIG_BIAS_PULL_DOWN:
>  		mask = PAD_PULLDOWN | PAD_PULLUP | PAD_PULL_EN;
> -		clrsetbits_le32(addr, mask, PAD_PULLDOWN | PAD_PULL_EN);
> +		if (argument)
> +			clrsetbits_le32(addr, mask, PAD_PULLDOWN | PAD_PULL_EN);
> +		else
> +			clrbits_le32(addr, PAD_PULLDOWN | PAD_PULL_EN);

This could be simplified as

	clrsetbits_le32(addr, PAD_PULLDOWN | PAD_PULLUP | PAD_PULL_EN,
			      argument ? PAD_PULLDOWN | PAD_PULL_EN : 0);

similar for the pull-up case.

>  		break;
>  	case PIN_CONFIG_BIAS_PULL_UP:
>  		mask = PAD_PULLDOWN | PAD_PULLUP | PAD_PULL_EN;
> -		clrsetbits_le32(addr, mask, PAD_PULLUP | PAD_PULL_EN);
> +		if (argument)
> +			clrsetbits_le32(addr, mask, PAD_PULLUP | PAD_PULL_EN);
> +		else
> +			clrbits_le32(addr, PAD_PULLUP | PAD_PULL_EN);
>  		break;
>  	case PIN_CONFIG_DRIVE_STRENGTH:
>  		io_type = IO_TYPE_1V8;
> 
> -- 
> 2.51.0
> 

Best regards,
Yao Zi

Re: [PATCH v6 03/11] pinctrl: k1: fix pull-up/pull-down configuration

[Yao Zi]

On Mon, Jul 27, 2026 at 08:20:07AM +0000, Yao Zi wrote:
> On Mon, Jul 27, 2026 at 02:59:05PM +0800, Eric Chung wrote:
> > Fix pull-up/pull-down configuration to honor the argument parameter:
> > when argument is non-zero, enable the requested pull direction;
> > when argument is zero, clear all pull bits to disable.
> 
> Since this is a bug in a patch that hasn't been merged, please fix it in
> place and re-spin the pinctrl/GPIO/SPI-NOR series.

Oops, I forgot lore is out of synchronization now. Checked U-Boot main
again and it seems the pinctrl driver is already here. Please ignore this
comment.

Best regards,
Yao Zi

> > Signed-off-by: Eric Chung <eric.chung@riscstar.com>

[PATCH v6 04/11] pinctrl: k1: add IO power domain configuration support

[Eric Chung]

Dual-voltage GPIO banks default to 3.3V, but when externally supplied
with 1.8V the internal logic must be explicitly reconfigured to match.

Add the ability to program IO power domain control registers through the
APBC block. These registers require unlocking the AIB Secure Access
Register (ASAR) before every read/write, since configuring a 1.8V domain
while 3.3V is externally supplied can cause back-powering and pin damage.

Signed-off-by: Eric Chung <eric.chung@riscstar.com>
Reviewed-by: Yao Zi <me@ziyao.cc>

---
v6:
- Use dev_read_phandle_with_args() to fetch "spacemit,apbc" instead.
v5:
- Use tabs for macro definition alignment.
- Fix the missing power source argument.
v3:
- Add SYSCON dependency in Kconfig.
- Fix not sorted issue in the driver.
---
 drivers/pinctrl/spacemit/Kconfig      |  2 +-
 drivers/pinctrl/spacemit/pinctrl-k1.c | 96 +++++++++++++++++++++++++++++++++--
 2 files changed, 94 insertions(+), 4 deletions(-)

diff --git a/drivers/pinctrl/spacemit/Kconfig b/drivers/pinctrl/spacemit/Kconfig
index 6aab89e160c..ff754f5839c 100644
--- a/drivers/pinctrl/spacemit/Kconfig
+++ b/drivers/pinctrl/spacemit/Kconfig
@@ -1,6 +1,6 @@
 config PINCTRL_SPACEMIT_K1
 	bool "Spacemit K1 SoC pinctrl driver"
-	depends on PINCTRL_GENERIC && DM
+	depends on PINCTRL_GENERIC && DM && SYSCON
 	help
 	  Supports pin multiplexing control on Spacemit K1 SoCs.
 
diff --git a/drivers/pinctrl/spacemit/pinctrl-k1.c b/drivers/pinctrl/spacemit/pinctrl-k1.c
index 454bc307ba3..c5e71e902b4 100644
--- a/drivers/pinctrl/spacemit/pinctrl-k1.c
+++ b/drivers/pinctrl/spacemit/pinctrl-k1.c
@@ -13,6 +13,8 @@
 #include <linux/bitops.h>
 #include <linux/errno.h>
 #include <linux/io.h>
+#include <regmap.h>
+#include <syscon.h>
 
 /*
  * +---------+----------+-----------+--------+--------+----------+--------+
@@ -35,8 +37,23 @@
 #define PAD_PULLUP		BIT(14)
 #define PAD_PULL_EN		BIT(15)
 
-#define PIN_POWER_STATE_1V8		1800
-#define PIN_POWER_STATE_3V3		3300
+#define IO_PWR_DOMAIN_OFFSET	0x800
+
+#define IO_PWR_DOMAIN_GPIO2_Kx	0x0c
+#define IO_PWR_DOMAIN_GPIO3_K1	0x10
+#define IO_PWR_DOMAIN_MMC_Kx	0x1c
+#define IO_PWR_DOMAIN_QSPI_K1	0x20
+
+#define IO_PWR_DOMAIN_V18EN	BIT(2)
+
+#define APBC_ASFAR		0x50
+#define APBC_ASSAR		0x54
+
+#define APBC_ASFAR_AKEY		0xbaba
+#define APBC_ASSAR_AKEY		0xeb10
+
+#define PIN_POWER_STATE_1V8	1800
+#define PIN_POWER_STATE_3V3	3300
 
 enum spacemit_pin_io_type {
 	IO_TYPE_NONE = 0,
@@ -61,12 +78,14 @@ struct spacemit_pinctrl_data {
 	int (*get_pins)(struct udevice *dev);
 	int (*get_functions)(struct udevice *dev);
 	int (*get_io_type)(struct udevice *dev, unsigned int pin);
+	unsigned int (*pin_to_io_pd_offset)(unsigned int pin);
 };
 
 struct spacemit_pinctrl_priv {
 	void __iomem		*regs;
 	struct spacemit_pin_io	*io_pins;
 	int			nr_io_pins;
+	struct regmap		*regmap;
 };
 
 struct spacemit_pin_mux_config {
@@ -197,6 +216,28 @@ static int k1_get_io_type(struct udevice *dev, unsigned int selector)
 	return -EINVAL;
 }
 
+static unsigned int spacemit_k1_pin_to_io_pd_offset(unsigned int pin)
+{
+	unsigned int offset = 0;
+
+	switch (pin) {
+	case 47 ... 52:
+		offset = IO_PWR_DOMAIN_GPIO3_K1;
+		break;
+	case 75 ... 80:
+		offset = IO_PWR_DOMAIN_GPIO2_Kx;
+		break;
+	case 98 ... 103:
+		offset = IO_PWR_DOMAIN_QSPI_K1;
+		break;
+	case 104 ... 109:
+		offset = IO_PWR_DOMAIN_MMC_Kx;
+		break;
+	}
+
+	return offset;
+}
+
 /* use IO high level output current as the table */
 static struct spacemit_pin_drv_strength spacemit_ds_1v8_tbl[4] = {
 	{ 0, 11 },
@@ -403,6 +444,35 @@ static const struct pinconf_param spacemit_pinconf_params[] = {
 	{ "power-source",	PIN_CONFIG_POWER_SOURCE,	U32_MAX },
 };
 
+static void spacemit_set_io_power_domain(struct udevice *dev,
+					 unsigned int pin,
+					 unsigned int io_type)
+{
+	struct spacemit_pinctrl_priv *priv = dev_get_priv(dev);
+	struct spacemit_pinctrl_data *data;
+	unsigned int offset;
+	u32 val = 0;
+
+	if (!priv->regmap)
+		return;
+
+	data = (struct spacemit_pinctrl_data *)dev_get_driver_data(dev);
+	if (!data || !data->pin_to_io_pd_offset)
+		return;
+
+	offset = data->pin_to_io_pd_offset(pin);
+	if (!offset)
+		return;
+
+	if (io_type == IO_TYPE_1V8)
+		val = IO_PWR_DOMAIN_V18EN;
+
+	regmap_write(priv->regmap, APBC_ASFAR, APBC_ASFAR_AKEY);
+	regmap_write(priv->regmap, APBC_ASSAR, APBC_ASSAR_AKEY);
+
+	writel(val, priv->regs + IO_PWR_DOMAIN_OFFSET + offset);
+}
+
 static int spacemit_pinconf_set(struct udevice *dev, unsigned int pin_selector,
 				unsigned int param, unsigned int argument)
 {
@@ -418,6 +488,7 @@ static int spacemit_pinconf_set(struct udevice *dev, unsigned int pin_selector,
 	data = (struct spacemit_pinctrl_data *)dev_get_driver_data(dev);
 	if (!data || !data->pin_to_reg)
 		return -EINVAL;
+
 	addr = data->pin_to_reg(dev, pin_selector);
 	switch (param) {
 	case PIN_CONFIG_BIAS_DISABLE:
@@ -466,10 +537,14 @@ static int spacemit_pinconf_set(struct udevice *dev, unsigned int pin_selector,
 			}
 			break;
 		}
-		if (!found && argument != PIN_POWER_STATE_1V8) {
+		if (!found && argument != PIN_POWER_STATE_1V8 &&
+		    argument != PIN_POWER_STATE_3V3) {
 			dev_err(dev, "Invalid power source (%d)\n", argument);
 			return -EINVAL;
 		}
+		if (found)
+			spacemit_set_io_power_domain(dev, pin_selector,
+						     priv->io_pins[i].io_type);
 		break;
 	default:
 		return -EOPNOTSUPP;
@@ -482,6 +557,7 @@ static int spacemit_pinctrl_probe(struct udevice *dev)
 	struct spacemit_pinctrl_data *data;
 	struct spacemit_pinctrl_priv *priv;
 	struct clk_bulk clks;
+	struct ofnode_phandle_args args;
 	size_t size;
 	int ret;
 
@@ -499,6 +575,19 @@ static int spacemit_pinctrl_probe(struct udevice *dev)
 		dev_err(dev, "Fail to allocate memory\n");
 		return -ENOMEM;
 	}
+	ret = dev_read_phandle_with_args(dev, "spacemit,apbc",
+					 NULL, 0, 0, &args);
+	if (ret) {
+		dev_warn(dev, "no APBC phandle found, disable IO power domain switching\n");
+		priv->regmap = NULL;
+	} else {
+		ret = regmap_init_mem(args.node, &priv->regmap);
+		if (ret) {
+			dev_warn(dev, "failed to get APBC regmap,"
+				 " disable IO power domain switching\n");
+			priv->regmap = NULL;
+		}
+	}
 
 	ret = clk_get_bulk(dev, &clks);
 	if (ret) {
@@ -526,6 +615,7 @@ static const struct spacemit_pinctrl_data k1_pinctrl_data = {
 	.get_pins	= k1_get_pins,
 	.get_functions	= k1_get_functions,
 	.get_io_type	= k1_get_io_type,
+	.pin_to_io_pd_offset = spacemit_k1_pin_to_io_pd_offset,
 };
 
 static const struct udevice_id spacemit_pinctrl_ids[] = {

-- 
2.51.0

Re: [PATCH v6 04/11] pinctrl: k1: add IO power domain configuration support

[Junhui Liu]

Hi Eric,

I wasn't included in the To/Cc list, and lore has not been working
properly recently, so I had some difficulty replying to this thread.

> -	depends on PINCTRL_GENERIC && DM
> +	depends on PINCTRL_GENERIC && DM && SYSCON

Since v6 uses dev_read_phandle_with_args() followed by
regmap_init_mem(), the driver no longer uses the syscon uclass or any
syscon_* API. Therefore, the SYSCON dependency is unnecessary.

> +#include <regmap.h>
> +#include <syscon.h>

This include is unnecessary as well.

Best regards,
Junhui

[PATCH v6 05/11] mmc: k1: add sdhci platform driver

[Eric Chung]

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>

---
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 | 673 +++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 681 insertions(+)

diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index f9f7aa5cf97..b991a5931c0 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -722,6 +722,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 a23336d7d8d..aa05cec23be 100644
--- a/drivers/mmc/Makefile
+++ b/drivers/mmc/Makefile
@@ -71,6 +71,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 00000000000..3e1948eb3e5
--- /dev/null
+++ b/drivers/mmc/spacemit_sdhci.c
@@ -0,0 +1,673 @@
+// 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		9
+#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 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 < 3) {
+		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;
+
+	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

[PATCH v6 06/11] dts: k1: add SD card support in u-boot overlay

[Eric Chung]

Add the SDH0 controller node and its pinctrl groups to the u-boot
overlay. The upstream DTS only contains the eMMC node; the SD card
controller (sdhci@d4280000) and its MMC1 pinctrl configuration are
missing. Place the new node inside the storage-bus via path-based
merge so it inherits the dma-ranges from the parent bus.

Signed-off-by: Eric Chung <eric.chung@riscstar.com>

---
v5:
- Append power source field on eMMC/SD pinctrl.
v3:
- Fix SD pinctrl as uhs.
v2:
- Use vmmc-supply as vqmmc-supply on SD node.
- Add alias of mmc0 and mmc1.
---
 arch/riscv/dts/k1-bananapi-f3-u-boot.dtsi | 91 ++++++++++++++++++++++++++++++-
 arch/riscv/dts/k1-musepi-pro-u-boot.dtsi  | 86 ++++++++++++++++++++++++++++-
 2 files changed, 173 insertions(+), 4 deletions(-)

diff --git a/arch/riscv/dts/k1-bananapi-f3-u-boot.dtsi b/arch/riscv/dts/k1-bananapi-f3-u-boot.dtsi
index 7f9443d6951..4823cbc1f33 100644
--- a/arch/riscv/dts/k1-bananapi-f3-u-boot.dtsi
+++ b/arch/riscv/dts/k1-bananapi-f3-u-boot.dtsi
@@ -6,6 +6,11 @@
 #include "binman.dtsi"
 
 / {
+	aliases {
+		mmc0 = &emmc;
+		mmc1 = &sdhci0;
+	};
+
 	memory@0 {
 		device_type = "memory";
 		reg = <0x00000000 0x00000000 0x00000000 0x80000000>;
@@ -76,12 +81,14 @@
 				bootph-pre-ram;
 			};
 
-			buck3 {
+			buck3_1v8: buck3 {
 				regulator-name = "vdd_1v8";
 				bootph-pre-ram;
 			};
 
-			aldo1 {
+			buck4_3v3: buck4 { };
+
+			aldo1: aldo1 {
 				regulator-name = "vdd_1v8_mmc";
 				bootph-pre-ram;
 			};
@@ -89,6 +96,86 @@
 	};
 };
 
+/ {
+	soc {
+		storage-bus {
+			sdhci0: mmc@d4280000 {
+				bootph-pre-ram;
+				compatible = "spacemit,k1-sdhci";
+				reg = <0x0 0xd4280000 0x0 0x200>;
+				clocks = <&syscon_apmu CLK_SDH_AXI>,
+					 <&syscon_apmu CLK_SDH0>;
+				clock-names = "core", "io";
+				interrupts = <99>;
+				resets = <&syscon_apmu RESET_SDH_AXI>,
+					 <&syscon_apmu RESET_SDH0>;
+				reset-names = "sdh_axi", "sdh0";
+				bus-width = <4>;
+				max-frequency = <204800000>;
+				cd-gpios = <&gpio K1_GPIO(80) GPIO_ACTIVE_LOW>;
+				pinctrl-names = "default", "uhs";
+				pinctrl-0 = <&sdhci0_0_cfg>;
+				pinctrl-1 = <&sdhci0_1_cfg>;
+				status = "okay";
+			};
+		};
+	};
+};
+
+/* SD card pinctrl groups -- not present in upstream k1-pinctrl.dtsi */
+&pinctrl {
+	sdhci0_0_cfg: sdhci0-0-cfg {
+		grp_cmd_data {
+			pinmux = <K1_PADCONF(104, 0)>,  /* MMC1_DAT3 */
+				 <K1_PADCONF(105, 0)>,  /* MMC1_DAT2 */
+				 <K1_PADCONF(106, 0)>,  /* MMC1_DAT1 */
+				 <K1_PADCONF(107, 0)>,  /* MMC1_DAT0 */
+				 <K1_PADCONF(108, 0)>;  /* MMC1_CMD */
+			bias-pull-up = <1>;
+			drive-strength = <19>;
+			power-source = <3300>;
+		};
+		grp_clk {
+			pinmux = <K1_PADCONF(109, 0)>;  /* MMC1_CLK */
+			bias-pull-down = <1>;
+			drive-strength = <19>;
+			power-source = <3300>;
+		};
+	};
+
+	sdhci0_1_cfg: sdhci0-1-cfg {			/* uhs */
+		grp_cmd_data {
+			pinmux = <K1_PADCONF(104, 0)>,  /* MMC1_DAT3 */
+				 <K1_PADCONF(105, 0)>,  /* MMC1_DAT2 */
+				 <K1_PADCONF(106, 0)>,  /* MMC1_DAT1 */
+				 <K1_PADCONF(107, 0)>,  /* MMC1_DAT0 */
+				 <K1_PADCONF(108, 0)>;  /* MMC1_CMD */
+			bias-pull-up = <1>;
+			drive-strength = <42>;
+			power-source = <1800>;
+		};
+		grp_clk {
+			pinmux = <K1_PADCONF(109, 0)>;  /* MMC1_CLK */
+			bias-pull-down = <1>;
+			drive-strength = <42>;
+			power-source = <1800>;
+		};
+	};
+};
+
+&emmc {
+	bootph-pre-ram;
+	resets = <&syscon_apmu RESET_SDH_AXI>, <&syscon_apmu RESET_SDH2>;
+	reset-names = "sdh_axi", "sdh2";
+	vqmmc-supply = <&buck3_1v8>;
+	vmmc-supply = <&aldo1>;
+	max-frequency = <204800000>;
+};
+
+&sdhci0 {
+	vmmc-supply = <&buck4_3v3>;
+};
+
 &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 8a9a2a09de9..f730f79e3e7 100644
--- a/arch/riscv/dts/k1-musepi-pro-u-boot.dtsi
+++ b/arch/riscv/dts/k1-musepi-pro-u-boot.dtsi
@@ -10,6 +10,8 @@
 	aliases {
 		console = &uart0;
 		serial0 = &uart0;
+		mmc0 = &emmc;
+		mmc1 = &sdhci0;
 	};
 
 	chosen {
@@ -147,7 +149,7 @@
 				regulator-always-on;
 			};
 
-			buck4 {
+			buck4_3v3: buck4 {
 				regulator-min-microvolt = <500000>;
 				regulator-max-microvolt = <3300000>;
 				regulator-ramp-delay = <5000>;
@@ -168,7 +170,7 @@
 				regulator-always-on;
 			};
 
-			aldo1 {
+			aldo1: aldo1 {
 				bootph-pre-ram;
 				regulator-name = "vdd_1v8_mmc";
 				regulator-min-microvolt = <500000>;
@@ -249,6 +251,86 @@
 	};
 };
 
+/ {
+	soc {
+		storage-bus {
+			sdhci0: mmc@d4280000 {
+				bootph-pre-ram;
+				compatible = "spacemit,k1-sdhci";
+				reg = <0x0 0xd4280000 0x0 0x200>;
+				clocks = <&syscon_apmu CLK_SDH_AXI>,
+					 <&syscon_apmu CLK_SDH0>;
+				clock-names = "core", "io";
+				interrupts = <99>;
+				resets = <&syscon_apmu RESET_SDH_AXI>,
+					 <&syscon_apmu RESET_SDH0>;
+				reset-names = "sdh_axi", "sdh0";
+				bus-width = <4>;
+				max-frequency = <204800000>;
+				cd-gpios = <&gpio K1_GPIO(80) GPIO_ACTIVE_LOW>;
+				pinctrl-names = "default", "uhs";
+				pinctrl-0 = <&sdhci0_0_cfg>;
+				pinctrl-1 = <&sdhci0_1_cfg>;
+				status = "okay";
+			};
+		};
+	};
+};
+
+/* SD card pinctrl groups -- not present in upstream k1-pinctrl.dtsi */
+&pinctrl {
+	sdhci0_0_cfg: sdhci0-0-cfg {
+		grp_cmd_data {
+			pinmux = <K1_PADCONF(104, 0)>,  /* MMC1_DAT3 */
+				 <K1_PADCONF(105, 0)>,  /* MMC1_DAT2 */
+				 <K1_PADCONF(106, 0)>,  /* MMC1_DAT1 */
+				 <K1_PADCONF(107, 0)>,  /* MMC1_DAT0 */
+				 <K1_PADCONF(108, 0)>;  /* MMC1_CMD */
+			bias-pull-up = <1>;
+			drive-strength = <19>;
+			power-source = <3300>;
+		};
+		grp_clk {
+			pinmux = <K1_PADCONF(109, 0)>;  /* MMC1_CLK */
+			bias-pull-down = <1>;
+			drive-strength = <19>;
+			power-source = <3300>;
+		};
+	};
+
+	sdhci0_1_cfg: sdhci0-1-cfg {			/* uhs */
+		grp_cmd_data {
+			pinmux = <K1_PADCONF(104, 0)>,  /* MMC1_DAT3 */
+				 <K1_PADCONF(105, 0)>,  /* MMC1_DAT2 */
+				 <K1_PADCONF(106, 0)>,  /* MMC1_DAT1 */
+				 <K1_PADCONF(107, 0)>,  /* MMC1_DAT0 */
+				 <K1_PADCONF(108, 0)>;  /* MMC1_CMD */
+			bias-pull-up = <1>;
+			drive-strength = <42>;
+			power-source = <1800>;
+		};
+		grp_clk {
+			pinmux = <K1_PADCONF(109, 0)>;  /* MMC1_CLK */
+			bias-pull-down = <1>;
+			drive-strength = <42>;
+			power-source = <1800>;
+		};
+	};
+};
+
+&emmc {
+	bootph-pre-ram;
+	resets = <&syscon_apmu RESET_SDH_AXI>, <&syscon_apmu RESET_SDH2>;
+	reset-names = "sdh_axi", "sdh2";
+	vqmmc-supply = <&buck3_1v8>;
+	vmmc-supply = <&aldo1>;
+	max-frequency = <204800000>;
+};
+
+&sdhci0 {
+	vmmc-supply = <&buck4_3v3>;
+};
+
 &binman {
 	u-boot-spl-ddr {
 		type = "section";

-- 
2.51.0

Re: [PATCH v6 06/11] dts: k1: add SD card support in u-boot overlay

[Yao Zi]

On Mon, Jul 27, 2026 at 02:59:08PM +0800, Eric Chung wrote:
> Add the SDH0 controller node and its pinctrl groups to the u-boot
> overlay. The upstream DTS only contains the eMMC node; the SD card
> controller (sdhci@d4280000) and its MMC1 pinctrl configuration are
> missing. Place the new node inside the storage-bus via path-based
> merge so it inherits the dma-ranges from the parent bus.
> 
> Signed-off-by: Eric Chung <eric.chung@riscstar.com>

Please cherry-pick upstream devicetree changes from Linux upstream with
tools/update-subtree.sh instead of adding our own copies. Changes for
k1-bananapi-f3 and k1-muse-pi-pro have both landed in Linux v7.2.

Best regards,
Yao Zi

> ---
> v5:
> - Append power source field on eMMC/SD pinctrl.
> v3:
> - Fix SD pinctrl as uhs.
> v2:
> - Use vmmc-supply as vqmmc-supply on SD node.
> - Add alias of mmc0 and mmc1.
> ---
>  arch/riscv/dts/k1-bananapi-f3-u-boot.dtsi | 91 ++++++++++++++++++++++++++++++-
>  arch/riscv/dts/k1-musepi-pro-u-boot.dtsi  | 86 ++++++++++++++++++++++++++++-
>  2 files changed, 173 insertions(+), 4 deletions(-)

Re: [PATCH v6 06/11] dts: k1: add SD card support in u-boot overlay

[Eric Chung]

Hi Yao,

I'm not familiar with the policy for syncing DTS files from the Linux upstream.
Could you clarify how this script works?

Does it sync all DTS files from Linux upstream at once, or is it
possible to sync
only the Spacemit DTS file?

If I choose to sync only the Spacemit DTS file and include it in my patch set,
would that cause conflicts later when others try to sync all DTS files?

Best Regards
Eric

On Mon, Jul 27, 2026 at 7:52 PM Yao Zi <me@ziyao.cc> wrote:
>
> On Mon, Jul 27, 2026 at 02:59:08PM +0800, Eric Chung wrote:
> > Add the SDH0 controller node and its pinctrl groups to the u-boot
> > overlay. The upstream DTS only contains the eMMC node; the SD card
> > controller (sdhci@d4280000) and its MMC1 pinctrl configuration are
> > missing. Place the new node inside the storage-bus via path-based
> > merge so it inherits the dma-ranges from the parent bus.
> >
> > Signed-off-by: Eric Chung <eric.chung@riscstar.com>
>
> Please cherry-pick upstream devicetree changes from Linux upstream with
> tools/update-subtree.sh instead of adding our own copies. Changes for
> k1-bananapi-f3 and k1-muse-pi-pro have both landed in Linux v7.2.
>
> Best regards,
> Yao Zi
>
> > ---
> > v5:
> > - Append power source field on eMMC/SD pinctrl.
> > v3:
> > - Fix SD pinctrl as uhs.
> > v2:
> > - Use vmmc-supply as vqmmc-supply on SD node.
> > - Add alias of mmc0 and mmc1.
> > ---
> >  arch/riscv/dts/k1-bananapi-f3-u-boot.dtsi | 91 ++++++++++++++++++++++++++++++-
> >  arch/riscv/dts/k1-musepi-pro-u-boot.dtsi  | 86 ++++++++++++++++++++++++++++-
> >  2 files changed, 173 insertions(+), 4 deletions(-)

Re: [PATCH v6 06/11] dts: k1: add SD card support in u-boot overlay

[Yao Zi]

On Mon, Jul 27, 2026 at 09:08:52PM +0800, Eric Chung wrote:
> Hi Yao,
> 
> I'm not familiar with the policy for syncing DTS files from the Linux upstream.
> Could you clarify how this script works?
> 
> Does it sync all DTS files from Linux upstream at once, or is it
> possible to sync
> only the Spacemit DTS file?

update-subtree.sh cherry-picks a commit from the upstream, or
merge an upstream tag into the subtree. Cherry-picking SD-related
commits from Linux upstream suits for your case.

> If I choose to sync only the Spacemit DTS file and include it in my patch set,
> would that cause conflicts later when others try to sync all DTS files?

Tom synchronizes the dts subtree with Linux upstream irregularly, there
should be no conflict or relatively small ones if you cherry-pick the
changes, while adding downstream nodes in *-u-boot.dtsi might suffer
from duplication, too, during synchronization.

> Best Regards
> Eric

By the way, please avoid top-posting if possible.

Thanks,
Yao Zi

> On Mon, Jul 27, 2026 at 7:52 PM Yao Zi <me@ziyao.cc> wrote:
> >
> > On Mon, Jul 27, 2026 at 02:59:08PM +0800, Eric Chung wrote:
> > > Add the SDH0 controller node and its pinctrl groups to the u-boot
> > > overlay. The upstream DTS only contains the eMMC node; the SD card
> > > controller (sdhci@d4280000) and its MMC1 pinctrl configuration are
> > > missing. Place the new node inside the storage-bus via path-based
> > > merge so it inherits the dma-ranges from the parent bus.
> > >
> > > Signed-off-by: Eric Chung <eric.chung@riscstar.com>
> >
> > Please cherry-pick upstream devicetree changes from Linux upstream with
> > tools/update-subtree.sh instead of adding our own copies. Changes for
> > k1-bananapi-f3 and k1-muse-pi-pro have both landed in Linux v7.2.
> >
> > Best regards,
> > Yao Zi
> >
> > > ---
> > > v5:
> > > - Append power source field on eMMC/SD pinctrl.
> > > v3:
> > > - Fix SD pinctrl as uhs.
> > > v2:
> > > - Use vmmc-supply as vqmmc-supply on SD node.
> > > - Add alias of mmc0 and mmc1.
> > > ---
> > >  arch/riscv/dts/k1-bananapi-f3-u-boot.dtsi | 91 ++++++++++++++++++++++++++++++-
> > >  arch/riscv/dts/k1-musepi-pro-u-boot.dtsi  | 86 ++++++++++++++++++++++++++++-
> > >  2 files changed, 173 insertions(+), 4 deletions(-)

Re: [PATCH v6 06/11] dts: k1: add SD card support in u-boot overlay

[Eric Chung]

On Tue, Jul 28, 2026 at 1:08 AM Yao Zi <me@ziyao.cc> wrote:
>
> On Mon, Jul 27, 2026 at 09:08:52PM +0800, Eric Chung wrote:
> > Hi Yao,
> >
> > I'm not familiar with the policy for syncing DTS files from the Linux upstream.
> > Could you clarify how this script works?
> >
> > Does it sync all DTS files from Linux upstream at once, or is it
> > possible to sync
> > only the Spacemit DTS file?
>
> update-subtree.sh cherry-picks a commit from the upstream, or
> merge an upstream tag into the subtree. Cherry-picking SD-related
> commits from Linux upstream suits for your case.
>
> > If I choose to sync only the Spacemit DTS file and include it in my patch set,
> > would that cause conflicts later when others try to sync all DTS files?
>
> Tom synchronizes the dts subtree with Linux upstream irregularly, there
> should be no conflict or relatively small ones if you cherry-pick the
> changes, while adding downstream nodes in *-u-boot.dtsi might suffer
> from duplication, too, during synchronization.
>

The process is a bit complex. Since my main issue is that the DTS
files are out of
date, would it be simpler if I just copy the relevant Spacemit DTS
files directly
from the Linux upstream into the dts/upstream folder?

> > Best Regards
> > Eric
>
> By the way, please avoid top-posting if possible.
>
> Thanks,
> Yao Zi
>
> > On Mon, Jul 27, 2026 at 7:52 PM Yao Zi <me@ziyao.cc> wrote:
> > >
> > > On Mon, Jul 27, 2026 at 02:59:08PM +0800, Eric Chung wrote:
> > > > Add the SDH0 controller node and its pinctrl groups to the u-boot
> > > > overlay. The upstream DTS only contains the eMMC node; the SD card
> > > > controller (sdhci@d4280000) and its MMC1 pinctrl configuration are
> > > > missing. Place the new node inside the storage-bus via path-based
> > > > merge so it inherits the dma-ranges from the parent bus.
> > > >
> > > > Signed-off-by: Eric Chung <eric.chung@riscstar.com>
> > >
> > > Please cherry-pick upstream devicetree changes from Linux upstream with
> > > tools/update-subtree.sh instead of adding our own copies. Changes for
> > > k1-bananapi-f3 and k1-muse-pi-pro have both landed in Linux v7.2.
> > >
> > > Best regards,
> > > Yao Zi
> > >
> > > > ---
> > > > v5:
> > > > - Append power source field on eMMC/SD pinctrl.
> > > > v3:
> > > > - Fix SD pinctrl as uhs.
> > > > v2:
> > > > - Use vmmc-supply as vqmmc-supply on SD node.
> > > > - Add alias of mmc0 and mmc1.
> > > > ---
> > > >  arch/riscv/dts/k1-bananapi-f3-u-boot.dtsi | 91 ++++++++++++++++++++++++++++++-
> > > >  arch/riscv/dts/k1-musepi-pro-u-boot.dtsi  | 86 ++++++++++++++++++++++++++++-
> > > >  2 files changed, 173 insertions(+), 4 deletions(-)

Re: [PATCH v6 06/11] dts: k1: add SD card support in u-boot overlay

[Yao Zi]

On Tue, Jul 28, 2026 at 09:04:52AM +0800, Eric Chung wrote:
> On Tue, Jul 28, 2026 at 1:08 AM Yao Zi <me@ziyao.cc> wrote:
> >
> > On Mon, Jul 27, 2026 at 09:08:52PM +0800, Eric Chung wrote:
> > > Hi Yao,
> > >
> > > I'm not familiar with the policy for syncing DTS files from the Linux upstream.
> > > Could you clarify how this script works?
> > >
> > > Does it sync all DTS files from Linux upstream at once, or is it
> > > possible to sync
> > > only the Spacemit DTS file?
> >
> > update-subtree.sh cherry-picks a commit from the upstream, or
> > merge an upstream tag into the subtree. Cherry-picking SD-related
> > commits from Linux upstream suits for your case.
> >
> > > If I choose to sync only the Spacemit DTS file and include it in my patch set,
> > > would that cause conflicts later when others try to sync all DTS files?
> >
> > Tom synchronizes the dts subtree with Linux upstream irregularly, there
> > should be no conflict or relatively small ones if you cherry-pick the
> > changes, while adding downstream nodes in *-u-boot.dtsi might suffer
> > from duplication, too, during synchronization.
> >
> 
> The process is a bit complex. Since my main issue is that the DTS
> files are out of
> date, would it be simpler if I just copy the relevant Spacemit DTS
> files directly
> from the Linux upstream into the dts/upstream folder?

The answer is simply no.

> > > Best Regards
> > > Eric

Regards,
Yao Zi

> > By the way, please avoid top-posting if possible.
> >
> > Thanks,
> > Yao Zi
> >
> > > On Mon, Jul 27, 2026 at 7:52 PM Yao Zi <me@ziyao.cc> wrote:
> > > >
> > > > On Mon, Jul 27, 2026 at 02:59:08PM +0800, Eric Chung wrote:
> > > > > Add the SDH0 controller node and its pinctrl groups to the u-boot
> > > > > overlay. The upstream DTS only contains the eMMC node; the SD card
> > > > > controller (sdhci@d4280000) and its MMC1 pinctrl configuration are
> > > > > missing. Place the new node inside the storage-bus via path-based
> > > > > merge so it inherits the dma-ranges from the parent bus.
> > > > >
> > > > > Signed-off-by: Eric Chung <eric.chung@riscstar.com>
> > > >
> > > > Please cherry-pick upstream devicetree changes from Linux upstream with
> > > > tools/update-subtree.sh instead of adding our own copies. Changes for
> > > > k1-bananapi-f3 and k1-muse-pi-pro have both landed in Linux v7.2.
> > > >
> > > > Best regards,
> > > > Yao Zi
> > > >
> > > > > ---
> > > > > v5:
> > > > > - Append power source field on eMMC/SD pinctrl.
> > > > > v3:
> > > > > - Fix SD pinctrl as uhs.
> > > > > v2:
> > > > > - Use vmmc-supply as vqmmc-supply on SD node.
> > > > > - Add alias of mmc0 and mmc1.
> > > > > ---
> > > > >  arch/riscv/dts/k1-bananapi-f3-u-boot.dtsi | 91 ++++++++++++++++++++++++++++++-
> > > > >  arch/riscv/dts/k1-musepi-pro-u-boot.dtsi  | 86 ++++++++++++++++++++++++++++-
> > > > >  2 files changed, 173 insertions(+), 4 deletions(-)

Re: [PATCH v6 06/11] dts: k1: add SD card support in u-boot overlay

[Eric Chung]

On Tue, Jul 28, 2026 at 5:11 PM Yao Zi <me@ziyao.cc> wrote:
>
> On Tue, Jul 28, 2026 at 09:04:52AM +0800, Eric Chung wrote:
> > On Tue, Jul 28, 2026 at 1:08 AM Yao Zi <me@ziyao.cc> wrote:
> > >
> > > On Mon, Jul 27, 2026 at 09:08:52PM +0800, Eric Chung wrote:
> > > > Hi Yao,
> > > >
> > > > I'm not familiar with the policy for syncing DTS files from the Linux upstream.
> > > > Could you clarify how this script works?
> > > >
> > > > Does it sync all DTS files from Linux upstream at once, or is it
> > > > possible to sync
> > > > only the Spacemit DTS file?
> > >
> > > update-subtree.sh cherry-picks a commit from the upstream, or
> > > merge an upstream tag into the subtree. Cherry-picking SD-related
> > > commits from Linux upstream suits for your case.
> > >
> > > > If I choose to sync only the Spacemit DTS file and include it in my patch set,
> > > > would that cause conflicts later when others try to sync all DTS files?
> > >
> > > Tom synchronizes the dts subtree with Linux upstream irregularly, there
> > > should be no conflict or relatively small ones if you cherry-pick the
> > > changes, while adding downstream nodes in *-u-boot.dtsi might suffer
> > > from duplication, too, during synchronization.
> > >
> >
> > The process is a bit complex. Since my main issue is that the DTS
> > files are out of
> > date, would it be simpler if I just copy the relevant Spacemit DTS
> > files directly
> > from the Linux upstream into the dts/upstream folder?
>
> The answer is simply no.
>

OK. I'll keep using my own overlay DTS file.
I tried upstream DTS file. It only gave me more bugs. I could switch to
upstream DTS file when Tom syncs it.

> > > > Best Regards
> > > > Eric
>
> Regards,
> Yao Zi
>
> > > By the way, please avoid top-posting if possible.
> > >
> > > Thanks,
> > > Yao Zi
> > >
> > > > On Mon, Jul 27, 2026 at 7:52 PM Yao Zi <me@ziyao.cc> wrote:
> > > > >
> > > > > On Mon, Jul 27, 2026 at 02:59:08PM +0800, Eric Chung wrote:
> > > > > > Add the SDH0 controller node and its pinctrl groups to the u-boot
> > > > > > overlay. The upstream DTS only contains the eMMC node; the SD card
> > > > > > controller (sdhci@d4280000) and its MMC1 pinctrl configuration are
> > > > > > missing. Place the new node inside the storage-bus via path-based
> > > > > > merge so it inherits the dma-ranges from the parent bus.
> > > > > >
> > > > > > Signed-off-by: Eric Chung <eric.chung@riscstar.com>
> > > > >
> > > > > Please cherry-pick upstream devicetree changes from Linux upstream with
> > > > > tools/update-subtree.sh instead of adding our own copies. Changes for
> > > > > k1-bananapi-f3 and k1-muse-pi-pro have both landed in Linux v7.2.
> > > > >
> > > > > Best regards,
> > > > > Yao Zi
> > > > >
> > > > > > ---
> > > > > > v5:
> > > > > > - Append power source field on eMMC/SD pinctrl.
> > > > > > v3:
> > > > > > - Fix SD pinctrl as uhs.
> > > > > > v2:
> > > > > > - Use vmmc-supply as vqmmc-supply on SD node.
> > > > > > - Add alias of mmc0 and mmc1.
> > > > > > ---
> > > > > >  arch/riscv/dts/k1-bananapi-f3-u-boot.dtsi | 91 ++++++++++++++++++++++++++++++-
> > > > > >  arch/riscv/dts/k1-musepi-pro-u-boot.dtsi  | 86 ++++++++++++++++++++++++++++-
> > > > > >  2 files changed, 173 insertions(+), 4 deletions(-)

Re: [PATCH v6 06/11] dts: k1: add SD card support in u-boot overlay

[Yao Zi]

On Wed, Jul 29, 2026 at 10:05:14PM +0800, Eric Chung wrote:
> On Tue, Jul 28, 2026 at 5:11 PM Yao Zi <me@ziyao.cc> wrote:
> >
> > On Tue, Jul 28, 2026 at 09:04:52AM +0800, Eric Chung wrote:
> > > On Tue, Jul 28, 2026 at 1:08 AM Yao Zi <me@ziyao.cc> wrote:
> > > >
> > > > On Mon, Jul 27, 2026 at 09:08:52PM +0800, Eric Chung wrote:
> > > > > Hi Yao,
> > > > >
> > > > > I'm not familiar with the policy for syncing DTS files from the Linux upstream.
> > > > > Could you clarify how this script works?
> > > > >
> > > > > Does it sync all DTS files from Linux upstream at once, or is it
> > > > > possible to sync
> > > > > only the Spacemit DTS file?
> > > >
> > > > update-subtree.sh cherry-picks a commit from the upstream, or
> > > > merge an upstream tag into the subtree. Cherry-picking SD-related
> > > > commits from Linux upstream suits for your case.
> > > >
> > > > > If I choose to sync only the Spacemit DTS file and include it in my patch set,
> > > > > would that cause conflicts later when others try to sync all DTS files?
> > > >
> > > > Tom synchronizes the dts subtree with Linux upstream irregularly, there
> > > > should be no conflict or relatively small ones if you cherry-pick the
> > > > changes, while adding downstream nodes in *-u-boot.dtsi might suffer
> > > > from duplication, too, during synchronization.
> > > >
> > >
> > > The process is a bit complex. Since my main issue is that the DTS
> > > files are out of
> > > date, would it be simpler if I just copy the relevant Spacemit DTS
> > > files directly
> > > from the Linux upstream into the dts/upstream folder?
> >
> > The answer is simply no.
> >
> 
> OK. I'll keep using my own overlay DTS file.
> I tried upstream DTS file. It only gave me more bugs. I could switch to
> upstream DTS file when Tom syncs it.

So first of all, please note switching to upstream devicetree doesn't
mean you must remove all the dts overlays, you could keep small pieces
like these adding bootph-pre-ram properties, which are
bootloader-specific and might not get upstreamed in a short period.

And I noticed there have been quite a lot code in the overlays, like the
PMIC code, thus changes to overlays might be huge when cherry-picking,
if it's the case, this patch is then acceptable, but please mention it
in the commit message.

But, if switching to the devicetree with cherry-picked patches for MMC
leads to bugs, there are likely ABI compatibility issues in your driver,
which would persist even after the synchronization with upstream v7.2
tag. Please fix them. From the very start, it's agreed compatibility
with Linux devicetree ABI is important[1].

So here's my NAK for this series, including v7 of it.

Thanks,
Yao Zi

[1]: https://lore.kernel.org/all/20260429-glare-anybody-16c98d01184e@spud/

> > > > > Best Regards
> > > > > Eric
> >
> > Regards,
> > Yao Zi
> >
> > > > By the way, please avoid top-posting if possible.
> > > >
> > > > Thanks,
> > > > Yao Zi
> > > >
> > > > > On Mon, Jul 27, 2026 at 7:52 PM Yao Zi <me@ziyao.cc> wrote:
> > > > > >
> > > > > > On Mon, Jul 27, 2026 at 02:59:08PM +0800, Eric Chung wrote:
> > > > > > > Add the SDH0 controller node and its pinctrl groups to the u-boot
> > > > > > > overlay. The upstream DTS only contains the eMMC node; the SD card
> > > > > > > controller (sdhci@d4280000) and its MMC1 pinctrl configuration are
> > > > > > > missing. Place the new node inside the storage-bus via path-based
> > > > > > > merge so it inherits the dma-ranges from the parent bus.
> > > > > > >
> > > > > > > Signed-off-by: Eric Chung <eric.chung@riscstar.com>
> > > > > >
> > > > > > Please cherry-pick upstream devicetree changes from Linux upstream with
> > > > > > tools/update-subtree.sh instead of adding our own copies. Changes for
> > > > > > k1-bananapi-f3 and k1-muse-pi-pro have both landed in Linux v7.2.
> > > > > >
> > > > > > Best regards,
> > > > > > Yao Zi
> > > > > >
> > > > > > > ---
> > > > > > > v5:
> > > > > > > - Append power source field on eMMC/SD pinctrl.
> > > > > > > v3:
> > > > > > > - Fix SD pinctrl as uhs.
> > > > > > > v2:
> > > > > > > - Use vmmc-supply as vqmmc-supply on SD node.
> > > > > > > - Add alias of mmc0 and mmc1.
> > > > > > > ---
> > > > > > >  arch/riscv/dts/k1-bananapi-f3-u-boot.dtsi | 91 ++++++++++++++++++++++++++++++-
> > > > > > >  arch/riscv/dts/k1-musepi-pro-u-boot.dtsi  | 86 ++++++++++++++++++++++++++++-
> > > > > > >  2 files changed, 173 insertions(+), 4 deletions(-)

Re: [PATCH v6 06/11] dts: k1: add SD card support in u-boot overlay

[Eric Chung]

On Wed, Jul 29, 2026 at 11:58 PM Yao Zi <me@ziyao.cc> wrote:
>
> On Wed, Jul 29, 2026 at 10:05:14PM +0800, Eric Chung wrote:
> > On Tue, Jul 28, 2026 at 5:11 PM Yao Zi <me@ziyao.cc> wrote:
> > >
> > > On Tue, Jul 28, 2026 at 09:04:52AM +0800, Eric Chung wrote:
> > > > On Tue, Jul 28, 2026 at 1:08 AM Yao Zi <me@ziyao.cc> wrote:
> > > > >
> > > > > On Mon, Jul 27, 2026 at 09:08:52PM +0800, Eric Chung wrote:
> > > > > > Hi Yao,
> > > > > >
> > > > > > I'm not familiar with the policy for syncing DTS files from the Linux upstream.
> > > > > > Could you clarify how this script works?
> > > > > >
> > > > > > Does it sync all DTS files from Linux upstream at once, or is it
> > > > > > possible to sync
> > > > > > only the Spacemit DTS file?
> > > > >
> > > > > update-subtree.sh cherry-picks a commit from the upstream, or
> > > > > merge an upstream tag into the subtree. Cherry-picking SD-related
> > > > > commits from Linux upstream suits for your case.
> > > > >
> > > > > > If I choose to sync only the Spacemit DTS file and include it in my patch set,
> > > > > > would that cause conflicts later when others try to sync all DTS files?
> > > > >
> > > > > Tom synchronizes the dts subtree with Linux upstream irregularly, there
> > > > > should be no conflict or relatively small ones if you cherry-pick the
> > > > > changes, while adding downstream nodes in *-u-boot.dtsi might suffer
> > > > > from duplication, too, during synchronization.
> > > > >
> > > >
> > > > The process is a bit complex. Since my main issue is that the DTS
> > > > files are out of
> > > > date, would it be simpler if I just copy the relevant Spacemit DTS
> > > > files directly
> > > > from the Linux upstream into the dts/upstream folder?
> > >
> > > The answer is simply no.
> > >
> >
> > OK. I'll keep using my own overlay DTS file.
> > I tried upstream DTS file. It only gave me more bugs. I could switch to
> > upstream DTS file when Tom syncs it.
>
> So first of all, please note switching to upstream devicetree doesn't
> mean you must remove all the dts overlays, you could keep small pieces
> like these adding bootph-pre-ram properties, which are
> bootloader-specific and might not get upstreamed in a short period.
>
> And I noticed there have been quite a lot code in the overlays, like the
> PMIC code, thus changes to overlays might be huge when cherry-picking,
> if it's the case, this patch is then acceptable, but please mention it
> in the commit message.
>
Yes, it's one of the reasons. Too many related commits exist. I prefer to keep
the process simple. When someone syncs the whole DTS, the process is
much easier and avoids commit conflicts.

> But, if switching to the devicetree with cherry-picked patches for MMC
> leads to bugs, there are likely ABI compatibility issues in your driver,
> which would persist even after the synchronization with upstream v7.2
> tag. Please fix them. From the very start, it's agreed compatibility
> with Linux devicetree ABI is important[1].

There are several commits on DTS. Cherry-picking only a few commits is
not ideal.
I'm using upstream DTS. I just keep minimal changes in the overlay DTS file.

The cd-gpios property isn't even consistent between bananapi f3 and musepi pro
board.

The sequence of mmc nodes is also inconsistent. SD node is declared
first, and the
eMMC node is declared second. However, there is an alias that reverses
this order.
In order to make it work, I have to enable CONFIG_DM_SEQ_ALIAS.

As I said they could be fixed. And I failed to cherry-pick only a few
commits. So I don't
want to import commit conflicts when I synchronizing DTS files. I
prefer it could be
handled by maintainers. When it's done, I can continue to submit new
patches for fixes.

It should be fixed in Linux. But that doesn't mean I must fix the
error in Linux first.
Then I submit this patch set after 6 months, waiting for the fix to
merge in Linux.

>
> So here's my NAK for this series, including v7 of it.
>
> Thanks,
> Yao Zi
>
> [1]: https://lore.kernel.org/all/20260429-glare-anybody-16c98d01184e@spud/
>
> > > > > > Best Regards
> > > > > > Eric
> > >
> > > Regards,
> > > Yao Zi
> > >
> > > > > By the way, please avoid top-posting if possible.
> > > > >
> > > > > Thanks,
> > > > > Yao Zi
> > > > >
> > > > > > On Mon, Jul 27, 2026 at 7:52 PM Yao Zi <me@ziyao.cc> wrote:
> > > > > > >
> > > > > > > On Mon, Jul 27, 2026 at 02:59:08PM +0800, Eric Chung wrote:
> > > > > > > > Add the SDH0 controller node and its pinctrl groups to the u-boot
> > > > > > > > overlay. The upstream DTS only contains the eMMC node; the SD card
> > > > > > > > controller (sdhci@d4280000) and its MMC1 pinctrl configuration are
> > > > > > > > missing. Place the new node inside the storage-bus via path-based
> > > > > > > > merge so it inherits the dma-ranges from the parent bus.
> > > > > > > >
> > > > > > > > Signed-off-by: Eric Chung <eric.chung@riscstar.com>
> > > > > > >
> > > > > > > Please cherry-pick upstream devicetree changes from Linux upstream with
> > > > > > > tools/update-subtree.sh instead of adding our own copies. Changes for
> > > > > > > k1-bananapi-f3 and k1-muse-pi-pro have both landed in Linux v7.2.
> > > > > > >
> > > > > > > Best regards,
> > > > > > > Yao Zi
> > > > > > >
> > > > > > > > ---
> > > > > > > > v5:
> > > > > > > > - Append power source field on eMMC/SD pinctrl.
> > > > > > > > v3:
> > > > > > > > - Fix SD pinctrl as uhs.
> > > > > > > > v2:
> > > > > > > > - Use vmmc-supply as vqmmc-supply on SD node.
> > > > > > > > - Add alias of mmc0 and mmc1.
> > > > > > > > ---
> > > > > > > >  arch/riscv/dts/k1-bananapi-f3-u-boot.dtsi | 91 ++++++++++++++++++++++++++++++-
> > > > > > > >  arch/riscv/dts/k1-musepi-pro-u-boot.dtsi  | 86 ++++++++++++++++++++++++++++-
> > > > > > > >  2 files changed, 173 insertions(+), 4 deletions(-)

[PATCH v6 07/11] configs: k1: enable SD and eMMC support

[Eric Chung]

Enable high-speed MMC modes.

Signed-off-by: Eric Chung <eric.chung@riscstar.com>

---
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.
---
 board/spacemit/k1/MAINTAINERS |  1 +
 configs/spacemit_k1_defconfig | 20 ++++++++++++++++++++
 2 files changed, 21 insertions(+)

diff --git a/board/spacemit/k1/MAINTAINERS b/board/spacemit/k1/MAINTAINERS
index 32d47ecc8f1..ca994e2a1fb 100644
--- a/board/spacemit/k1/MAINTAINERS
+++ b/board/spacemit/k1/MAINTAINERS
@@ -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
diff --git a/configs/spacemit_k1_defconfig b/configs/spacemit_k1_defconfig
index 0604c2feefc..c0ee3a29f23 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,26 @@ CONFIG_SPI_FLASH_WINBOND=y
 CONFIG_SPI_MEM=y
 CONFIG_SYS_SPI_U_BOOT_OFFS=0x000a0000
 CONFIG_CMD_SPI=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_MMC=y
+CONFIG_SPL_SYS_MMCSD_RAW_MODE=y

-- 
2.51.0

Re: [PATCH v6 07/11] configs: k1: enable SD and eMMC support

[Yao Zi]

On Mon, Jul 27, 2026 at 02:59:09PM +0800, Eric Chung wrote:
> Enable high-speed MMC modes.
> 
> Signed-off-by: Eric Chung <eric.chung@riscstar.com>
> 
> ---
> 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.
> ---
>  board/spacemit/k1/MAINTAINERS |  1 +

This change doesn't seem to match the commit description. Please create
a separate commit for the MAINTAINERS file, or at least move the change
to the commit adding the driver.

Also, I don't think it's the reasonable place for board MAINTAINERS file
to keep the entry for drivers. Please consider creating an entry for
your platform in /MAINTAINERS later. You don't need to do so in this
series, though.

>  configs/spacemit_k1_defconfig | 20 ++++++++++++++++++++
>  2 files changed, 21 insertions(+)

Best regards,
Yao Zi

[PATCH v6 08/11] MAINTAINER: update Spacemit K1 entry

[Eric Chung]

Update the maintainer for Spacemit K1 from Guodong to Eric.

Signed-off-by: Eric Chung <eric.chung@riscstar.com>

---
v4:
- Update the maintainer.
---
 board/spacemit/k1/MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/spacemit/k1/MAINTAINERS b/board/spacemit/k1/MAINTAINERS
index ca994e2a1fb..4b2bc4ecfc1 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

-- 
2.51.0

[PATCH v6 09/11] doc: spacemit: flash on K1 SoC based boards

[Eric Chung]

Add document on how to flash images into eMMC of K1 SoC based boards.

Signed-off-by: Eric Chung <eric.chung@riscstar.com>

---
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 | 320 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 322 insertions(+), 1 deletion(-)

diff --git a/board/spacemit/k1/MAINTAINERS b/board/spacemit/k1/MAINTAINERS
index 4b2bc4ecfc1..e12288a206e 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 a5e35ee12ab..71854e5735b 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 00000000000..b0fe78c75ce
--- /dev/null
+++ b/doc/board/spacemit/k1-mmc.rst
@@ -0,0 +1,320 @@
+.. 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
+~~~~~~~~~~~~~
+
+- 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
+~~~~~~~~~~~~~
+
+- A SpacemiT K1 based development board
+- A microSD card (at least 8 GB capacity recommended)
+- A card reader for your host computer
+- A Linux host system (for ``dd``, ``fdisk``, ``lsblk`` commands)
+- The Bianbu SD card image from
+   <https://spacemit.com/community/resources-download/Images%20Collects/K1/Bianbu>
+- A custom ``u-boot.itb`` file (device tree blob or U-Boot FIT image) to be
+  written to the U-Boot partition
+
+Prepare the SD Card & the image
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+**1. Download the image**
+
+Download the released package from the official SpacemiT website:
+
+<https://archive.spacemit.com/image/k1/version/bianbu/v2.3.5/Bianbu-Minimal-K1-sdcard-V2.3.5-20260601180942.img.zip>
+
+**2. Extract the image**
+
+.. code-block:: console
+
+   $ unzip Bianbu-Minimal-K1-sdcard-V2.3.5-20260601180942.img.zip
+
+**3. 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``.
+
+**4. Write the image to the SD card**
+
+.. code-block:: console
+
+   $ sudo dd if=./Bianbu-Minimal-K1-sdcard-V2.3.5-20260601180942.img of=/dev/sdb bs=1M status=progress
+
+The SD card is now ready as a bootable Bianbu system disk.
+
+
+Understanding the SD Card Partition Layout
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+After writing the image, the SD card has the following partition structure
+(verified with ``sudo fdisk -l /dev/sdb``):
+
+.. code-block:: text
+
+   Device      Start     End Sectors  Size Type
+   /dev/sdb1     256     767     512  256K Linux filesystem
+   /dev/sdb2     768     895     128   64K Linux filesystem
+   /dev/sdb3    2048    4095    2048    1M Linux filesystem
+   /dev/sdb4    4096    8191    4096    2M Linux filesystem
+   /dev/sdb5    8192  532479  524288  256M Linux filesystem
+   /dev/sdb6  532480 4726783 4194304    2G Linux filesystem
+
+The role of each partition:
+
++----------+----------+--------------------------------------------------+
+| Partition| Size     | Purpose                                          |
++==========+==========+==================================================+
+| ``sdb1`` | 256 KB   | Boot information for Boot ROM                    |
++----------+----------+--------------------------------------------------+
+| ``sdb2`` | 64 KB    | FSBL (First Stage Bootloader)                    |
++----------+----------+--------------------------------------------------+
+| ``sdb3`` | 1 MB     | OpenSBI / U-Boot environment                     |
++----------+----------+--------------------------------------------------+
+| ``sdb4`` | 2 MB     | **U-Boot binary (``u-boot.itb``)**               |
++----------+----------+--------------------------------------------------+
+| ``sdb5`` | 256 MB   | Boot partition (FAT32, kernel + device tree)     |
++----------+----------+--------------------------------------------------+
+| ``sdb6`` | 2 GB     | Root filesystem (ext4)                           |
++----------+----------+--------------------------------------------------+
+
+
+Replacing U-Boot on the SD Card
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+This section explains how to replace the U-Boot binary on the SD card
+with your own custom ``u-boot.itb`` file. For this guide, the custom file
+is a ``Device Tree Blob`` , which fits within
+the 2 MB ``/dev/sdb4`` partition.
+
+
+**1. Confirm the SD card device and partition**
+
+.. code-block:: console
+
+   $ sudo fdisk -l /dev/sdb
+
+Ensure that ``/dev/sdb4`` exists and has the expected size (2 MB),
+and that the replacement ``u-boot.itb`` is no larger than the size.
+
+
+**2. Write the new U-Boot image**
+
+.. code-block:: console
+
+   $ sudo dd if=./u-boot.itb of=/dev/sdb4 bs=1M status=progress
+
+Example successful output:
+
+.. code-block:: text
+
+   0+1 records in
+   0+1 records out
+   873033 bytes (873 kB, 853 KiB) copied, 1.22109 s, 715 kB/s
+
+
+**3. Synchronize**
+
+.. code-block:: console
+
+   $ sync
+
+**4. Eject the SD card**
+
+.. code-block:: console
+
+   $ sudo eject /dev/sdb
+
+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

Re: [PATCH v6 09/11] doc: spacemit: flash on K1 SoC based boards

[Yao Zi]

On Mon, Jul 27, 2026 at 02:59:11PM +0800, Eric Chung wrote:
> Add document on how to flash images into eMMC of K1 SoC based boards.
> 
> Signed-off-by: Eric Chung <eric.chung@riscstar.com>
> 
> ---
> 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 | 320 ++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 322 insertions(+), 1 deletion(-)

...

> diff --git a/doc/board/spacemit/k1-mmc.rst b/doc/board/spacemit/k1-mmc.rst
> new file mode 100644
> index 00000000000..b0fe78c75ce
> --- /dev/null
> +++ b/doc/board/spacemit/k1-mmc.rst
> @@ -0,0 +1,320 @@

...

> +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
> +~~~~~~~~~~~~~
> +
> +- A SpacemiT K1 based development board
> +- A microSD card (at least 8 GB capacity recommended)
> +- A card reader for your host computer
> +- A Linux host system (for ``dd``, ``fdisk``, ``lsblk`` commands)
> +- The Bianbu SD card image from
> +   <https://spacemit.com/community/resources-download/Images%20Collects/K1/Bianbu>
> +- A custom ``u-boot.itb`` file (device tree blob or U-Boot FIT image) to be
> +  written to the U-Boot partition
> +
> +Prepare the SD Card & the image
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +**1. Download the image**
> +
> +Download the released package from the official SpacemiT website:
> +
> +<https://archive.spacemit.com/image/k1/version/bianbu/v2.3.5/Bianbu-Minimal-K1-sdcard-V2.3.5-20260601180942.img.zip>
> +
> +**2. Extract the image**
> +
> +.. code-block:: console
> +
> +   $ unzip Bianbu-Minimal-K1-sdcard-V2.3.5-20260601180942.img.zip
> +
> +**3. 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``.
> +
> +**4. Write the image to the SD card**
> +
> +.. code-block:: console
> +
> +   $ sudo dd if=./Bianbu-Minimal-K1-sdcard-V2.3.5-20260601180942.img of=/dev/sdb bs=1M status=progress
> +
> +The SD card is now ready as a bootable Bianbu system disk.

This looks out of scope of describing how to create a bootable SD card
with U-Boot. In my opinion, you'd better describe the requirements of
parition layout and image position for SD-card booting, to allow readers
to create their own images/bootable medium from scratch more easily,
instead of sticking to the vendored image.

Best regards,
Yao Zi

Re: [PATCH v6 09/11] doc: spacemit: flash on K1 SoC based boards

[Eric Chung]

On Tue, Jul 28, 2026 at 1:26 AM Yao Zi <me@ziyao.cc> wrote:
>
> On Mon, Jul 27, 2026 at 02:59:11PM +0800, Eric Chung wrote:
> > Add document on how to flash images into eMMC of K1 SoC based boards.
> >
> > Signed-off-by: Eric Chung <eric.chung@riscstar.com>
> >
> > ---
> > 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 | 320 ++++++++++++++++++++++++++++++++++++++++++
> >  3 files changed, 322 insertions(+), 1 deletion(-)
>
> ...
>
> > diff --git a/doc/board/spacemit/k1-mmc.rst b/doc/board/spacemit/k1-mmc.rst
> > new file mode 100644
> > index 00000000000..b0fe78c75ce
> > --- /dev/null
> > +++ b/doc/board/spacemit/k1-mmc.rst
> > @@ -0,0 +1,320 @@
>
> ...
>
> > +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
> > +~~~~~~~~~~~~~
> > +
> > +- A SpacemiT K1 based development board
> > +- A microSD card (at least 8 GB capacity recommended)
> > +- A card reader for your host computer
> > +- A Linux host system (for ``dd``, ``fdisk``, ``lsblk`` commands)
> > +- The Bianbu SD card image from
> > +   <https://spacemit.com/community/resources-download/Images%20Collects/K1/Bianbu>
> > +- A custom ``u-boot.itb`` file (device tree blob or U-Boot FIT image) to be
> > +  written to the U-Boot partition
> > +
> > +Prepare the SD Card & the image
> > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > +
> > +**1. Download the image**
> > +
> > +Download the released package from the official SpacemiT website:
> > +
> > +<https://archive.spacemit.com/image/k1/version/bianbu/v2.3.5/Bianbu-Minimal-K1-sdcard-V2.3.5-20260601180942.img.zip>
> > +
> > +**2. Extract the image**
> > +
> > +.. code-block:: console
> > +
> > +   $ unzip Bianbu-Minimal-K1-sdcard-V2.3.5-20260601180942.img.zip
> > +
> > +**3. 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``.
> > +
> > +**4. Write the image to the SD card**
> > +
> > +.. code-block:: console
> > +
> > +   $ sudo dd if=./Bianbu-Minimal-K1-sdcard-V2.3.5-20260601180942.img of=/dev/sdb bs=1M status=progress
> > +
> > +The SD card is now ready as a bootable Bianbu system disk.
>
> This looks out of scope of describing how to create a bootable SD card
> with U-Boot. In my opinion, you'd better describe the requirements of
> parition layout and image position for SD-card booting, to allow readers
> to create their own images/bootable medium from scratch more easily,
> instead of sticking to the vendored image.
>

Creating a bootable SD card from scratch would be valuable, but I'll address
it later due to time constraints.

Re: [PATCH v6 09/11] doc: spacemit: flash on K1 SoC based boards

[Yao Zi]

On Tue, Jul 28, 2026 at 08:53:02AM +0800, Eric Chung wrote:
> On Tue, Jul 28, 2026 at 1:26 AM Yao Zi <me@ziyao.cc> wrote:
> >
> > On Mon, Jul 27, 2026 at 02:59:11PM +0800, Eric Chung wrote:
> > > Add document on how to flash images into eMMC of K1 SoC based boards.
> > >
> > > Signed-off-by: Eric Chung <eric.chung@riscstar.com>
> > >
> > > ---
> > > 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 | 320 ++++++++++++++++++++++++++++++++++++++++++
> > >  3 files changed, 322 insertions(+), 1 deletion(-)
> >
> > ...
> >
> > > diff --git a/doc/board/spacemit/k1-mmc.rst b/doc/board/spacemit/k1-mmc.rst
> > > new file mode 100644
> > > index 00000000000..b0fe78c75ce
> > > --- /dev/null
> > > +++ b/doc/board/spacemit/k1-mmc.rst
> > > @@ -0,0 +1,320 @@
> >
> > ...
> >
> > > +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
> > > +~~~~~~~~~~~~~
> > > +
> > > +- A SpacemiT K1 based development board
> > > +- A microSD card (at least 8 GB capacity recommended)
> > > +- A card reader for your host computer
> > > +- A Linux host system (for ``dd``, ``fdisk``, ``lsblk`` commands)
> > > +- The Bianbu SD card image from
> > > +   <https://spacemit.com/community/resources-download/Images%20Collects/K1/Bianbu>
> > > +- A custom ``u-boot.itb`` file (device tree blob or U-Boot FIT image) to be
> > > +  written to the U-Boot partition
> > > +
> > > +Prepare the SD Card & the image
> > > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > +
> > > +**1. Download the image**
> > > +
> > > +Download the released package from the official SpacemiT website:
> > > +
> > > +<https://archive.spacemit.com/image/k1/version/bianbu/v2.3.5/Bianbu-Minimal-K1-sdcard-V2.3.5-20260601180942.img.zip>
> > > +
> > > +**2. Extract the image**
> > > +
> > > +.. code-block:: console
> > > +
> > > +   $ unzip Bianbu-Minimal-K1-sdcard-V2.3.5-20260601180942.img.zip
> > > +
> > > +**3. 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``.
> > > +
> > > +**4. Write the image to the SD card**
> > > +
> > > +.. code-block:: console
> > > +
> > > +   $ sudo dd if=./Bianbu-Minimal-K1-sdcard-V2.3.5-20260601180942.img of=/dev/sdb bs=1M status=progress
> > > +
> > > +The SD card is now ready as a bootable Bianbu system disk.
> >
> > This looks out of scope of describing how to create a bootable SD card
> > with U-Boot. In my opinion, you'd better describe the requirements of
> > parition layout and image position for SD-card booting, to allow readers
> > to create their own images/bootable medium from scratch more easily,
> > instead of sticking to the vendored image.
> >
> 
> Creating a bootable SD card from scratch would be valuable, but I'll address
> it later due to time constraints.

In case I didn't make myself clear enough, the documentation *SHOULD*
describe how to create bootable devices from scratch, instead of
alternating an existing OS image to use mainline U-Boot. I don't think
the current documentation helps much for downstream users/distributions
to adapt U-Boot for their own use cases, or at least it could be written
in a much more clear, vendor-neutral way.

So here's my NAK for this patch. I'm not sure what you mean by "time
constraints", but please keep submitted patches in a good shape.

Thanks,
Yao Zi

Re: [PATCH v6 09/11] doc: spacemit: flash on K1 SoC based boards

[Eric Chung]

On Tue, Jul 28, 2026 at 5:45 PM Yao Zi <me@ziyao.cc> wrote:
>
> On Tue, Jul 28, 2026 at 08:53:02AM +0800, Eric Chung wrote:
> > On Tue, Jul 28, 2026 at 1:26 AM Yao Zi <me@ziyao.cc> wrote:
> > >
> > > On Mon, Jul 27, 2026 at 02:59:11PM +0800, Eric Chung wrote:
> > > > Add document on how to flash images into eMMC of K1 SoC based boards.
> > > >
> > > > Signed-off-by: Eric Chung <eric.chung@riscstar.com>
> > > >
> > > > ---
> > > > 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 | 320 ++++++++++++++++++++++++++++++++++++++++++
> > > >  3 files changed, 322 insertions(+), 1 deletion(-)
> > >
> > > ...
> > >
> > > > diff --git a/doc/board/spacemit/k1-mmc.rst b/doc/board/spacemit/k1-mmc.rst
> > > > new file mode 100644
> > > > index 00000000000..b0fe78c75ce
> > > > --- /dev/null
> > > > +++ b/doc/board/spacemit/k1-mmc.rst
> > > > @@ -0,0 +1,320 @@
> > >
> > > ...
> > >
> > > > +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
> > > > +~~~~~~~~~~~~~
> > > > +
> > > > +- A SpacemiT K1 based development board
> > > > +- A microSD card (at least 8 GB capacity recommended)
> > > > +- A card reader for your host computer
> > > > +- A Linux host system (for ``dd``, ``fdisk``, ``lsblk`` commands)
> > > > +- The Bianbu SD card image from
> > > > +   <https://spacemit.com/community/resources-download/Images%20Collects/K1/Bianbu>
> > > > +- A custom ``u-boot.itb`` file (device tree blob or U-Boot FIT image) to be
> > > > +  written to the U-Boot partition
> > > > +
> > > > +Prepare the SD Card & the image
> > > > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > +
> > > > +**1. Download the image**
> > > > +
> > > > +Download the released package from the official SpacemiT website:
> > > > +
> > > > +<https://archive.spacemit.com/image/k1/version/bianbu/v2.3.5/Bianbu-Minimal-K1-sdcard-V2.3.5-20260601180942.img.zip>
> > > > +
> > > > +**2. Extract the image**
> > > > +
> > > > +.. code-block:: console
> > > > +
> > > > +   $ unzip Bianbu-Minimal-K1-sdcard-V2.3.5-20260601180942.img.zip
> > > > +
> > > > +**3. 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``.
> > > > +
> > > > +**4. Write the image to the SD card**
> > > > +
> > > > +.. code-block:: console
> > > > +
> > > > +   $ sudo dd if=./Bianbu-Minimal-K1-sdcard-V2.3.5-20260601180942.img of=/dev/sdb bs=1M status=progress
> > > > +
> > > > +The SD card is now ready as a bootable Bianbu system disk.
> > >
> > > This looks out of scope of describing how to create a bootable SD card
> > > with U-Boot. In my opinion, you'd better describe the requirements of
> > > parition layout and image position for SD-card booting, to allow readers
> > > to create their own images/bootable medium from scratch more easily,
> > > instead of sticking to the vendored image.
> > >
> >
> > Creating a bootable SD card from scratch would be valuable, but I'll address
> > it later due to time constraints.
>
> In case I didn't make myself clear enough, the documentation *SHOULD*
> describe how to create bootable devices from scratch, instead of
> alternating an existing OS image to use mainline U-Boot. I don't think
> the current documentation helps much for downstream users/distributions
> to adapt U-Boot for their own use cases, or at least it could be written
> in a much more clear, vendor-neutral way.
>
> So here's my NAK for this patch. I'm not sure what you mean by "time
> constraints", but please keep submitted patches in a good shape.
>

I’m not sure why the documentation insists on walking users through creating a
bootable SD card from scratch, especially when, at this stage, it
still depends on
the vendor’s tools. In practice, we’re required to use the vendor’s
flashing tool for
both eMMC and SD devices, and we must adhere to the provided partition table.

If users prefer to define their own partition layout, nothing prevents
them from doing
so on their own. That’s entirely up to them.

The default SD image already includes the vendor’s U-Boot. My
instructions simply
explain how to replace it with the upstream version—nothing more.

Re: [PATCH v6 09/11] doc: spacemit: flash on K1 SoC based boards

[Yao Zi]

On Wed, Jul 29, 2026 at 09:49:26PM +0800, Eric Chung wrote:
> On Tue, Jul 28, 2026 at 5:45 PM Yao Zi <me@ziyao.cc> wrote:
> >
> > On Tue, Jul 28, 2026 at 08:53:02AM +0800, Eric Chung wrote:
> > > On Tue, Jul 28, 2026 at 1:26 AM Yao Zi <me@ziyao.cc> wrote:
> > > >
> > > > On Mon, Jul 27, 2026 at 02:59:11PM +0800, Eric Chung wrote:
> > > > > Add document on how to flash images into eMMC of K1 SoC based boards.
> > > > >
> > > > > Signed-off-by: Eric Chung <eric.chung@riscstar.com>
> > > > >
> > > > > ---
> > > > > 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 | 320 ++++++++++++++++++++++++++++++++++++++++++
> > > > >  3 files changed, 322 insertions(+), 1 deletion(-)
> > > >
> > > > ...
> > > >
> > > > > diff --git a/doc/board/spacemit/k1-mmc.rst b/doc/board/spacemit/k1-mmc.rst
> > > > > new file mode 100644
> > > > > index 00000000000..b0fe78c75ce
> > > > > --- /dev/null
> > > > > +++ b/doc/board/spacemit/k1-mmc.rst
> > > > > @@ -0,0 +1,320 @@
> > > >
> > > > ...
> > > >
> > > > > +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
> > > > > +~~~~~~~~~~~~~
> > > > > +
> > > > > +- A SpacemiT K1 based development board
> > > > > +- A microSD card (at least 8 GB capacity recommended)
> > > > > +- A card reader for your host computer
> > > > > +- A Linux host system (for ``dd``, ``fdisk``, ``lsblk`` commands)
> > > > > +- The Bianbu SD card image from
> > > > > +   <https://spacemit.com/community/resources-download/Images%20Collects/K1/Bianbu>
> > > > > +- A custom ``u-boot.itb`` file (device tree blob or U-Boot FIT image) to be
> > > > > +  written to the U-Boot partition
> > > > > +
> > > > > +Prepare the SD Card & the image
> > > > > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > > +
> > > > > +**1. Download the image**
> > > > > +
> > > > > +Download the released package from the official SpacemiT website:
> > > > > +
> > > > > +<https://archive.spacemit.com/image/k1/version/bianbu/v2.3.5/Bianbu-Minimal-K1-sdcard-V2.3.5-20260601180942.img.zip>
> > > > > +
> > > > > +**2. Extract the image**
> > > > > +
> > > > > +.. code-block:: console
> > > > > +
> > > > > +   $ unzip Bianbu-Minimal-K1-sdcard-V2.3.5-20260601180942.img.zip
> > > > > +
> > > > > +**3. 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``.
> > > > > +
> > > > > +**4. Write the image to the SD card**
> > > > > +
> > > > > +.. code-block:: console
> > > > > +
> > > > > +   $ sudo dd if=./Bianbu-Minimal-K1-sdcard-V2.3.5-20260601180942.img of=/dev/sdb bs=1M status=progress
> > > > > +
> > > > > +The SD card is now ready as a bootable Bianbu system disk.
> > > >
> > > > This looks out of scope of describing how to create a bootable SD card
> > > > with U-Boot. In my opinion, you'd better describe the requirements of
> > > > parition layout and image position for SD-card booting, to allow readers
> > > > to create their own images/bootable medium from scratch more easily,
> > > > instead of sticking to the vendored image.
> > > >
> > >
> > > Creating a bootable SD card from scratch would be valuable, but I'll address
> > > it later due to time constraints.
> >
> > In case I didn't make myself clear enough, the documentation *SHOULD*
> > describe how to create bootable devices from scratch, instead of
> > alternating an existing OS image to use mainline U-Boot. I don't think
> > the current documentation helps much for downstream users/distributions
> > to adapt U-Boot for their own use cases, or at least it could be written
> > in a much more clear, vendor-neutral way.
> >
> > So here's my NAK for this patch. I'm not sure what you mean by "time
> > constraints", but please keep submitted patches in a good shape.
> >

In case that I still didn't make myself clear enough, by "bootable SD
card", I mean a minimal medium with only a bootable U-Boot, you could
refer to Rockchip or StarFive's documentation.

> I’m not sure why the documentation insists on walking users through creating a
> bootable SD card from scratch, especially when, at this stage, it
> still depends on
> the vendor’s tools.

Please explain which tools it depends on. Now U-Boot for your platform
already has its SPL ported, and according to your instructions of
replacing the vendor U-Boot, it seems no extra post-processing is
required for the SoC to identify it.

And after re-reading the documentation, it seems you don't make use of
the upstream SPL when creating the SD-card image, is this intended, and
why?

> In practice, we’re required to use the vendor’s
> flashing tool for
> both eMMC and SD devices,

Please explain the constraints, it's okay to depend on vendor's tools,
but for creating a SD-card image, I couldn't come up with a reason to
do so, at least by inferring from the current documentation.

> and we must adhere to the provided partition table.

Thus please clearly describe which part of the partition table must be
preserved for the SoC to boot.

> If users prefer to define their own partition layout, nothing prevents
> them from doing
> so on their own. That’s entirely up to them.
> 
> The default SD image already includes the vendor’s U-Boot. My
> instructions simply
> explain how to replace it with the upstream version—nothing more.

Best regards,
Yao Zi

Re: [PATCH v6 09/11] doc: spacemit: flash on K1 SoC based boards

[Eric Chung]

On Wed, Jul 29, 2026 at 11:33 PM Yao Zi <me@ziyao.cc> wrote:
>
> On Wed, Jul 29, 2026 at 09:49:26PM +0800, Eric Chung wrote:
> > On Tue, Jul 28, 2026 at 5:45 PM Yao Zi <me@ziyao.cc> wrote:
> > >
> > > On Tue, Jul 28, 2026 at 08:53:02AM +0800, Eric Chung wrote:
> > > > On Tue, Jul 28, 2026 at 1:26 AM Yao Zi <me@ziyao.cc> wrote:
> > > > >
> > > > > On Mon, Jul 27, 2026 at 02:59:11PM +0800, Eric Chung wrote:
> > > > > > Add document on how to flash images into eMMC of K1 SoC based boards.
> > > > > >
> > > > > > Signed-off-by: Eric Chung <eric.chung@riscstar.com>
> > > > > >
> > > > > > ---
> > > > > > 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 | 320 ++++++++++++++++++++++++++++++++++++++++++
> > > > > >  3 files changed, 322 insertions(+), 1 deletion(-)
> > > > >
> > > > > ...
> > > > >
> > > > > > diff --git a/doc/board/spacemit/k1-mmc.rst b/doc/board/spacemit/k1-mmc.rst
> > > > > > new file mode 100644
> > > > > > index 00000000000..b0fe78c75ce
> > > > > > --- /dev/null
> > > > > > +++ b/doc/board/spacemit/k1-mmc.rst
> > > > > > @@ -0,0 +1,320 @@
> > > > >
> > > > > ...
> > > > >
> > > > > > +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
> > > > > > +~~~~~~~~~~~~~
> > > > > > +
> > > > > > +- A SpacemiT K1 based development board
> > > > > > +- A microSD card (at least 8 GB capacity recommended)
> > > > > > +- A card reader for your host computer
> > > > > > +- A Linux host system (for ``dd``, ``fdisk``, ``lsblk`` commands)
> > > > > > +- The Bianbu SD card image from
> > > > > > +   <https://spacemit.com/community/resources-download/Images%20Collects/K1/Bianbu>
> > > > > > +- A custom ``u-boot.itb`` file (device tree blob or U-Boot FIT image) to be
> > > > > > +  written to the U-Boot partition
> > > > > > +
> > > > > > +Prepare the SD Card & the image
> > > > > > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > > > +
> > > > > > +**1. Download the image**
> > > > > > +
> > > > > > +Download the released package from the official SpacemiT website:
> > > > > > +
> > > > > > +<https://archive.spacemit.com/image/k1/version/bianbu/v2.3.5/Bianbu-Minimal-K1-sdcard-V2.3.5-20260601180942.img.zip>
> > > > > > +
> > > > > > +**2. Extract the image**
> > > > > > +
> > > > > > +.. code-block:: console
> > > > > > +
> > > > > > +   $ unzip Bianbu-Minimal-K1-sdcard-V2.3.5-20260601180942.img.zip
> > > > > > +
> > > > > > +**3. 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``.
> > > > > > +
> > > > > > +**4. Write the image to the SD card**
> > > > > > +
> > > > > > +.. code-block:: console
> > > > > > +
> > > > > > +   $ sudo dd if=./Bianbu-Minimal-K1-sdcard-V2.3.5-20260601180942.img of=/dev/sdb bs=1M status=progress
> > > > > > +
> > > > > > +The SD card is now ready as a bootable Bianbu system disk.
> > > > >
> > > > > This looks out of scope of describing how to create a bootable SD card
> > > > > with U-Boot. In my opinion, you'd better describe the requirements of
> > > > > parition layout and image position for SD-card booting, to allow readers
> > > > > to create their own images/bootable medium from scratch more easily,
> > > > > instead of sticking to the vendored image.
> > > > >
> > > >
> > > > Creating a bootable SD card from scratch would be valuable, but I'll address
> > > > it later due to time constraints.
> > >
> > > In case I didn't make myself clear enough, the documentation *SHOULD*
> > > describe how to create bootable devices from scratch, instead of
> > > alternating an existing OS image to use mainline U-Boot. I don't think
> > > the current documentation helps much for downstream users/distributions
> > > to adapt U-Boot for their own use cases, or at least it could be written
> > > in a much more clear, vendor-neutral way.
> > >
> > > So here's my NAK for this patch. I'm not sure what you mean by "time
> > > constraints", but please keep submitted patches in a good shape.
> > >
>
> In case that I still didn't make myself clear enough, by "bootable SD
> card", I mean a minimal medium with only a bootable U-Boot, you could
> refer to Rockchip or StarFive's documentation.
>

I checked Rockchip or StarFive's documentation. And I can't find any mention of
creating a bootable SD card.

> > I’m not sure why the documentation insists on walking users through creating a
> > bootable SD card from scratch, especially when, at this stage, it
> > still depends on
> > the vendor’s tools.
>
> Please explain which tools it depends on. Now U-Boot for your platform
> already has its SPL ported, and according to your instructions of
> replacing the vendor U-Boot, it seems no extra post-processing is
> required for the SoC to identify it.

The flashing process must begin with a USB transfer. The vendor's
proprietary tool is required to download the images to the target
device. To maintain compatibility with this tool, I need to use the
same partition table that it expects.

Currently, the SPL (Secondary Program Loader) only boots U-Boot; it
has no other function in the boot flow.

>
> And after re-reading the documentation, it seems you don't make use of
> the upstream SPL when creating the SD-card image, is this intended, and
> why?
>

Oh, I missed it. I need to append SPL part.

> > In practice, we’re required to use the vendor’s
> > flashing tool for
> > both eMMC and SD devices,
>
> Please explain the constraints, it's okay to depend on vendor's tools,
> but for creating a SD-card image, I couldn't come up with a reason to
> do so, at least by inferring from the current documentation.
>

I’m required to use the vendor’s flashing tool, flashserver, for
programming SD card images — mainly because it’s the only way I can
properly program the RPMB partition.

The tool supports both eMMC and SD boot modes, and environment
variables (ENV) can be stored on either medium. However, it would be
unusual to boot from an SD card while loading the ENV from eMMC.
Therefore, the simplest and most consistent approach is to keep the
same partition layout across all critical components — including FSBL,
ENV, and OpenSBI partitions — regardless of the boot medium.

> > and we must adhere to the provided partition table.
>
> Thus please clearly describe which part of the partition table must be
> preserved for the SoC to boot.
>

Mentioned above.

> > If users prefer to define their own partition layout, nothing prevents
> > them from doing
> > so on their own. That’s entirely up to them.
> >
> > The default SD image already includes the vendor’s U-Boot. My
> > instructions simply
> > explain how to replace it with the upstream version—nothing more.
>
> Best regards,
> Yao Zi

Re: [PATCH v6 09/11] doc: spacemit: flash on K1 SoC based boards

[Yao Zi]

On Thu, Jul 30, 2026 at 02:25:31PM +0800, Eric Chung wrote:
> On Wed, Jul 29, 2026 at 11:33 PM Yao Zi <me@ziyao.cc> wrote:
> >
> > On Wed, Jul 29, 2026 at 09:49:26PM +0800, Eric Chung wrote:
> > > On Tue, Jul 28, 2026 at 5:45 PM Yao Zi <me@ziyao.cc> wrote:
> > > >
> > > > On Tue, Jul 28, 2026 at 08:53:02AM +0800, Eric Chung wrote:
> > > > > On Tue, Jul 28, 2026 at 1:26 AM Yao Zi <me@ziyao.cc> wrote:
> > > > > >
> > > > > > On Mon, Jul 27, 2026 at 02:59:11PM +0800, Eric Chung wrote:
> > > > > > > Add document on how to flash images into eMMC of K1 SoC based boards.
> > > > > > >
> > > > > > > Signed-off-by: Eric Chung <eric.chung@riscstar.com>
> > > > > > >
> > > > > > > ---
> > > > > > > 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 | 320 ++++++++++++++++++++++++++++++++++++++++++
> > > > > > >  3 files changed, 322 insertions(+), 1 deletion(-)
> > > > > >
> > > > > > ...
> > > > > >
> > > > > > > diff --git a/doc/board/spacemit/k1-mmc.rst b/doc/board/spacemit/k1-mmc.rst
> > > > > > > new file mode 100644
> > > > > > > index 00000000000..b0fe78c75ce
> > > > > > > --- /dev/null
> > > > > > > +++ b/doc/board/spacemit/k1-mmc.rst
> > > > > > > @@ -0,0 +1,320 @@
> > > > > >
> > > > > > ...
> > > > > >
> > > > > > > +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
> > > > > > > +~~~~~~~~~~~~~
> > > > > > > +
> > > > > > > +- A SpacemiT K1 based development board
> > > > > > > +- A microSD card (at least 8 GB capacity recommended)
> > > > > > > +- A card reader for your host computer
> > > > > > > +- A Linux host system (for ``dd``, ``fdisk``, ``lsblk`` commands)
> > > > > > > +- The Bianbu SD card image from
> > > > > > > +   <https://spacemit.com/community/resources-download/Images%20Collects/K1/Bianbu>
> > > > > > > +- A custom ``u-boot.itb`` file (device tree blob or U-Boot FIT image) to be
> > > > > > > +  written to the U-Boot partition
> > > > > > > +
> > > > > > > +Prepare the SD Card & the image
> > > > > > > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > > > > +
> > > > > > > +**1. Download the image**
> > > > > > > +
> > > > > > > +Download the released package from the official SpacemiT website:
> > > > > > > +
> > > > > > > +<https://archive.spacemit.com/image/k1/version/bianbu/v2.3.5/Bianbu-Minimal-K1-sdcard-V2.3.5-20260601180942.img.zip>
> > > > > > > +
> > > > > > > +**2. Extract the image**
> > > > > > > +
> > > > > > > +.. code-block:: console
> > > > > > > +
> > > > > > > +   $ unzip Bianbu-Minimal-K1-sdcard-V2.3.5-20260601180942.img.zip
> > > > > > > +
> > > > > > > +**3. 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``.
> > > > > > > +
> > > > > > > +**4. Write the image to the SD card**
> > > > > > > +
> > > > > > > +.. code-block:: console
> > > > > > > +
> > > > > > > +   $ sudo dd if=./Bianbu-Minimal-K1-sdcard-V2.3.5-20260601180942.img of=/dev/sdb bs=1M status=progress
> > > > > > > +
> > > > > > > +The SD card is now ready as a bootable Bianbu system disk.
> > > > > >
> > > > > > This looks out of scope of describing how to create a bootable SD card
> > > > > > with U-Boot. In my opinion, you'd better describe the requirements of
> > > > > > parition layout and image position for SD-card booting, to allow readers
> > > > > > to create their own images/bootable medium from scratch more easily,
> > > > > > instead of sticking to the vendored image.
> > > > > >
> > > > >
> > > > > Creating a bootable SD card from scratch would be valuable, but I'll address
> > > > > it later due to time constraints.
> > > >
> > > > In case I didn't make myself clear enough, the documentation *SHOULD*
> > > > describe how to create bootable devices from scratch, instead of
> > > > alternating an existing OS image to use mainline U-Boot. I don't think
> > > > the current documentation helps much for downstream users/distributions
> > > > to adapt U-Boot for their own use cases, or at least it could be written
> > > > in a much more clear, vendor-neutral way.
> > > >
> > > > So here's my NAK for this patch. I'm not sure what you mean by "time
> > > > constraints", but please keep submitted patches in a good shape.
> > > >
> >
> > In case that I still didn't make myself clear enough, by "bootable SD
> > card", I mean a minimal medium with only a bootable U-Boot, you could
> > refer to Rockchip or StarFive's documentation.
> >
> 
> I checked Rockchip or StarFive's documentation. And I can't find any mention of
> creating a bootable SD card.

Please grep SD in doc/rockchip/rockchip.rst. For StarFive, it seems
the process of creating bootable SDcards has been removed a little
earlier, but in section "Zero Stage BootLoader" of
doc/starfive/jh7110_common.rst, the BROM's behavior is still described.

> > > I’m not sure why the documentation insists on walking users through creating a
> > > bootable SD card from scratch, especially when, at this stage, it
> > > still depends on
> > > the vendor’s tools.
> >
> > Please explain which tools it depends on. Now U-Boot for your platform
> > already has its SPL ported, and according to your instructions of
> > replacing the vendor U-Boot, it seems no extra post-processing is
> > required for the SoC to identify it.
> 
> The flashing process must begin with a USB transfer. The vendor's
> proprietary tool is required to download the images to the target
> device. To maintain compatibility with this tool, I need to use the
> same partition table that it expects.

So please make it clear whether the proprietary tool is required for
creating SD-card images, or it's only required for downloading the image
to the SD card. The latter seems impossible since you described how to
flash an image to SD with dd in this documentation.

I'm really confused with your description.

> Currently, the SPL (Secondary Program Loader) only boots U-Boot; it
> has no other function in the boot flow.
> 
> >
> > And after re-reading the documentation, it seems you don't make use of
> > the upstream SPL when creating the SD-card image, is this intended, and
> > why?
> >
> 
> Oh, I missed it. I need to append SPL part.
> 
> > > In practice, we’re required to use the vendor’s
> > > flashing tool for
> > > both eMMC and SD devices,
> >
> > Please explain the constraints, it's okay to depend on vendor's tools,
> > but for creating a SD-card image, I couldn't come up with a reason to
> > do so, at least by inferring from the current documentation.
> >
> 
> I’m required to use the vendor’s flashing tool, flashserver, for
> programming SD card images — mainly because it’s the only way I can
> properly program the RPMB partition.

But you don't do so in the documentation, dd is used. This wouldn't
program the RPMB partition AFAIK. And does it mean that K1 requires a
SDcard with RPMB support to boot? This doesn't match my experience with
the platform.

> The tool supports both eMMC and SD boot modes, and environment
> variables (ENV) can be stored on either medium. However, it would be
> unusual to boot from an SD card while loading the ENV from eMMC.
> Therefore, the simplest and most consistent approach is to keep the
> same partition layout across all critical components — including FSBL,
> ENV, and OpenSBI partitions — regardless of the boot medium.
> 
> > > and we must adhere to the provided partition table.
> >
> > Thus please clearly describe which part of the partition table must be
> > preserved for the SoC to boot.
> >
> 
> Mentioned above.

Please quote the text, you do provide an example partition table, but
there's no note describing which partitions are mandatory, and whether
their offsets could be changed.

If a user could only create their own SDcard images by trial and error,
this documentation loses its purpose. Please describe what is mandatory,
or only describe the mandatory parts like Rockchip's documentation.

> > > If users prefer to define their own partition layout, nothing prevents
> > > them from doing
> > > so on their own. That’s entirely up to them.
> > >
> > > The default SD image already includes the vendor’s U-Boot. My
> > > instructions simply
> > > explain how to replace it with the upstream version—nothing more.
> >
> > Best regards,
> > Yao Zi

Frankly, I'm really tired of this discussion, I don't think you
understand much of my questions, even though I tried to explain myself
once and once again. And your replies are self-contradictory.

Please make sure you understand my questions and reply with reasonable
answers. I wouldn't continue to review your patches before you resolve
questions in this thread.

Best regards,
Yao Zi

Re: [PATCH v6 09/11] doc: spacemit: flash on K1 SoC based boards

[Eric Chung]

On Thu, Jul 30, 2026 at 11:22 PM Yao Zi <me@ziyao.cc> wrote:
>
> On Thu, Jul 30, 2026 at 02:25:31PM +0800, Eric Chung wrote:
> > On Wed, Jul 29, 2026 at 11:33 PM Yao Zi <me@ziyao.cc> wrote:
> > >
> > > On Wed, Jul 29, 2026 at 09:49:26PM +0800, Eric Chung wrote:
> > > > On Tue, Jul 28, 2026 at 5:45 PM Yao Zi <me@ziyao.cc> wrote:
> > > > >
> > > > > On Tue, Jul 28, 2026 at 08:53:02AM +0800, Eric Chung wrote:
> > > > > > On Tue, Jul 28, 2026 at 1:26 AM Yao Zi <me@ziyao.cc> wrote:
> > > > > > >
> > > > > > > On Mon, Jul 27, 2026 at 02:59:11PM +0800, Eric Chung wrote:
> > > > > > > > Add document on how to flash images into eMMC of K1 SoC based boards.
> > > > > > > >
> > > > > > > > Signed-off-by: Eric Chung <eric.chung@riscstar.com>
> > > > > > > >
> > > > > > > > ---
> > > > > > > > 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 | 320 ++++++++++++++++++++++++++++++++++++++++++
> > > > > > > >  3 files changed, 322 insertions(+), 1 deletion(-)
> > > > > > >
> > > > > > > ...
> > > > > > >
> > > > > > > > diff --git a/doc/board/spacemit/k1-mmc.rst b/doc/board/spacemit/k1-mmc.rst
> > > > > > > > new file mode 100644
> > > > > > > > index 00000000000..b0fe78c75ce
> > > > > > > > --- /dev/null
> > > > > > > > +++ b/doc/board/spacemit/k1-mmc.rst
> > > > > > > > @@ -0,0 +1,320 @@
> > > > > > >
> > > > > > > ...
> > > > > > >
> > > > > > > > +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
> > > > > > > > +~~~~~~~~~~~~~
> > > > > > > > +
> > > > > > > > +- A SpacemiT K1 based development board
> > > > > > > > +- A microSD card (at least 8 GB capacity recommended)
> > > > > > > > +- A card reader for your host computer
> > > > > > > > +- A Linux host system (for ``dd``, ``fdisk``, ``lsblk`` commands)
> > > > > > > > +- The Bianbu SD card image from
> > > > > > > > +   <https://spacemit.com/community/resources-download/Images%20Collects/K1/Bianbu>
> > > > > > > > +- A custom ``u-boot.itb`` file (device tree blob or U-Boot FIT image) to be
> > > > > > > > +  written to the U-Boot partition
> > > > > > > > +
> > > > > > > > +Prepare the SD Card & the image
> > > > > > > > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > > > > > +
> > > > > > > > +**1. Download the image**
> > > > > > > > +
> > > > > > > > +Download the released package from the official SpacemiT website:
> > > > > > > > +
> > > > > > > > +<https://archive.spacemit.com/image/k1/version/bianbu/v2.3.5/Bianbu-Minimal-K1-sdcard-V2.3.5-20260601180942.img.zip>
> > > > > > > > +
> > > > > > > > +**2. Extract the image**
> > > > > > > > +
> > > > > > > > +.. code-block:: console
> > > > > > > > +
> > > > > > > > +   $ unzip Bianbu-Minimal-K1-sdcard-V2.3.5-20260601180942.img.zip
> > > > > > > > +
> > > > > > > > +**3. 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``.
> > > > > > > > +
> > > > > > > > +**4. Write the image to the SD card**
> > > > > > > > +
> > > > > > > > +.. code-block:: console
> > > > > > > > +
> > > > > > > > +   $ sudo dd if=./Bianbu-Minimal-K1-sdcard-V2.3.5-20260601180942.img of=/dev/sdb bs=1M status=progress
> > > > > > > > +
> > > > > > > > +The SD card is now ready as a bootable Bianbu system disk.
> > > > > > >
> > > > > > > This looks out of scope of describing how to create a bootable SD card
> > > > > > > with U-Boot. In my opinion, you'd better describe the requirements of
> > > > > > > parition layout and image position for SD-card booting, to allow readers
> > > > > > > to create their own images/bootable medium from scratch more easily,
> > > > > > > instead of sticking to the vendored image.
> > > > > > >
> > > > > >
> > > > > > Creating a bootable SD card from scratch would be valuable, but I'll address
> > > > > > it later due to time constraints.
> > > > >
> > > > > In case I didn't make myself clear enough, the documentation *SHOULD*
> > > > > describe how to create bootable devices from scratch, instead of
> > > > > alternating an existing OS image to use mainline U-Boot. I don't think
> > > > > the current documentation helps much for downstream users/distributions
> > > > > to adapt U-Boot for their own use cases, or at least it could be written
> > > > > in a much more clear, vendor-neutral way.
> > > > >
> > > > > So here's my NAK for this patch. I'm not sure what you mean by "time
> > > > > constraints", but please keep submitted patches in a good shape.
> > > > >
> > >
> > > In case that I still didn't make myself clear enough, by "bootable SD
> > > card", I mean a minimal medium with only a bootable U-Boot, you could
> > > refer to Rockchip or StarFive's documentation.
> > >
> >
> > I checked Rockchip or StarFive's documentation. And I can't find any mention of
> > creating a bootable SD card.
>
> Please grep SD in doc/rockchip/rockchip.rst. For StarFive, it seems
> the process of creating bootable SDcards has been removed a little
> earlier, but in section "Zero Stage BootLoader" of
> doc/starfive/jh7110_common.rst, the BROM's behavior is still described.
>
> > > > I’m not sure why the documentation insists on walking users through creating a
> > > > bootable SD card from scratch, especially when, at this stage, it
> > > > still depends on
> > > > the vendor’s tools.
> > >
> > > Please explain which tools it depends on. Now U-Boot for your platform
> > > already has its SPL ported, and according to your instructions of
> > > replacing the vendor U-Boot, it seems no extra post-processing is
> > > required for the SoC to identify it.
> >
> > The flashing process must begin with a USB transfer. The vendor's
> > proprietary tool is required to download the images to the target
> > device. To maintain compatibility with this tool, I need to use the
> > same partition table that it expects.
>
> So please make it clear whether the proprietary tool is required for
> creating SD-card images, or it's only required for downloading the image
> to the SD card. The latter seems impossible since you described how to
> flash an image to SD with dd in this documentation.
>
> I'm really confused with your description.
>
> > Currently, the SPL (Secondary Program Loader) only boots U-Boot; it
> > has no other function in the boot flow.
> >
> > >
> > > And after re-reading the documentation, it seems you don't make use of
> > > the upstream SPL when creating the SD-card image, is this intended, and
> > > why?
> > >
> >
> > Oh, I missed it. I need to append SPL part.
> >
> > > > In practice, we’re required to use the vendor’s
> > > > flashing tool for
> > > > both eMMC and SD devices,
> > >
> > > Please explain the constraints, it's okay to depend on vendor's tools,
> > > but for creating a SD-card image, I couldn't come up with a reason to
> > > do so, at least by inferring from the current documentation.
> > >
> >
> > I’m required to use the vendor’s flashing tool, flashserver, for
> > programming SD card images — mainly because it’s the only way I can
> > properly program the RPMB partition.
>
> But you don't do so in the documentation, dd is used. This wouldn't
> program the RPMB partition AFAIK. And does it mean that K1 requires a
> SDcard with RPMB support to boot? This doesn't match my experience with
> the platform.
>
> > The tool supports both eMMC and SD boot modes, and environment
> > variables (ENV) can be stored on either medium. However, it would be
> > unusual to boot from an SD card while loading the ENV from eMMC.
> > Therefore, the simplest and most consistent approach is to keep the
> > same partition layout across all critical components — including FSBL,
> > ENV, and OpenSBI partitions — regardless of the boot medium.
> >
> > > > and we must adhere to the provided partition table.
> > >
> > > Thus please clearly describe which part of the partition table must be
> > > preserved for the SoC to boot.
> > >
> >
> > Mentioned above.
>
> Please quote the text, you do provide an example partition table, but
> there's no note describing which partitions are mandatory, and whether
> their offsets could be changed.
>
> If a user could only create their own SDcard images by trial and error,
> this documentation loses its purpose. Please describe what is mandatory,
> or only describe the mandatory parts like Rockchip's documentation.
>
> > > > If users prefer to define their own partition layout, nothing prevents
> > > > them from doing
> > > > so on their own. That’s entirely up to them.
> > > >
> > > > The default SD image already includes the vendor’s U-Boot. My
> > > > instructions simply
> > > > explain how to replace it with the upstream version—nothing more.
> > >
> > > Best regards,
> > > Yao Zi
>
> Frankly, I'm really tired of this discussion, I don't think you
> understand much of my questions, even though I tried to explain myself
> once and once again. And your replies are self-contradictory.
>
> Please make sure you understand my questions and reply with reasonable
> answers. I wouldn't continue to review your patches before you resolve
> questions in this thread.

So let it be simple. I'll remove the SD card part from this document
in the next round. Then we don't need to discuss it any more.

Any new comments on this series? If no, I'll send the next round in this week.

[PATCH v6 10/11] config: k1: enable ENV support for eMMC

[Eric Chung]

Enable environment variable support on the eMMC storage device for
both SPL and U-Boot stages.

Signed-off-by: Eric Chung <eric.chung@riscstar.com>
---
 configs/spacemit_k1_defconfig | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/configs/spacemit_k1_defconfig b/configs/spacemit_k1_defconfig
index c0ee3a29f23..7caba18ddcd 100644
--- a/configs/spacemit_k1_defconfig
+++ b/configs/spacemit_k1_defconfig
@@ -14,7 +14,7 @@ CONFIG_SPL_BSS_MAX_SIZE=0x400
 CONFIG_SPL_STACK_R=y
 CONFIG_SPL_STACK_R_ADDR=0xc00000
 CONFIG_SPL_SYS_MALLOC_SIMPLE=y
-CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x100000
+CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x400000
 CONFIG_SYS_BOOTM_LEN=0xa000000
 CONFIG_SYS_LOAD_ADDR=0x200000
 CONFIG_SPL_SIZE_LIMIT=0x31000
@@ -48,6 +48,10 @@ CONFIG_CMD_TLV_EEPROM=y
 CONFIG_SPL_CMD_TLV_EEPROM=y
 CONFIG_OF_UPSTREAM=y
 CONFIG_ENV_OVERWRITE=y
+CONFIG_ENV_SIZE=0x4000
+CONFIG_ENV_OFFSET=0x60000
+CONFIG_ENV_SECT_SIZE=0x10000
+CONFIG_ENV_IS_IN_MMC=y
 CONFIG_SPL_REGMAP=y
 CONFIG_SYSCON=y
 CONFIG_SPL_SYSCON=y
@@ -111,5 +115,6 @@ CONFIG_SPL_SPI_LOAD=y
 CONFIG_SPL_SPI_FLASH_TINY=y
 CONFIG_SPL_SPI_FLASH_SUPPORT=y
 CONFIG_SPL_BOARD_INIT=y
+CONFIG_SPL_ENV_SUPPORT=y
 CONFIG_SPL_MMC=y
 CONFIG_SPL_SYS_MMCSD_RAW_MODE=y

-- 
2.51.0

[PATCH v6 11/11] spacemit: k1: load product name from environment variable

[Eric Chung]

Read the product name from the environment instead of EEPROM,
as the EEPROM may not be programmed and the environment always
contains this information.

Signed-off-by: Eric Chung <eric.chung@riscstar.com>

---
v6:
- Rebased onto latest upstream. Cleaned up board_fit_config_name_match()
  to maintain consistentcy with v5.
---
 board/spacemit/k1/spl.c | 89 +++++++++++++++++++++----------------------------
 1 file changed, 38 insertions(+), 51 deletions(-)

diff --git a/board/spacemit/k1/spl.c b/board/spacemit/k1/spl.c
index 613e8c4cf02..69c992ea57a 100644
--- a/board/spacemit/k1/spl.c
+++ b/board/spacemit/k1/spl.c
@@ -12,9 +12,9 @@
 #include <configs/k1.h>
 #include <dm/device.h>
 #include <dm/uclass.h>
+#include <env.h>
 #include <i2c.h>
 #include <linux/bitfield.h>
-#include <linux/ctype.h>
 #include <linux/delay.h>
 #include <log.h>
 #include <power/regulator.h>
@@ -97,37 +97,41 @@ static void i2c_early_init(void)
 	}
 }
 
-int read_product_name(char *name, int size)
+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" },
+};
+
+static void fixup_product_name(void)
 {
-	u8 eeprom_data[TLV_TOTAL_LEN_MAX], *p;
-	struct tlvinfo_header *tlv_hdr;
-	struct tlvinfo_tlv *tlv_entry;
-	int ret, i = 0;
-	u32 entry_size;
+	char fdt_name[I2C_BUF_SIZE], *name;
+	int i;
 
-	if (!name || size <= 0)
-		return -EINVAL;
-	ret = read_tlvinfo_tlv_eeprom(eeprom_data, &tlv_hdr,
-				      &tlv_entry, i);
-	if (ret)
-		return ret;
-	p = (u8 *)tlv_entry;
-	for (i = 0; i < tlv_hdr->totallen; ) {
-		if (tlv_entry->type == TLV_CODE_PRODUCT_NAME) {
-			if (tlv_entry->length < size)
-				size = tlv_entry->length;
-			memset(name, 0, size);
-			memcpy(name, &tlv_entry->value[0], size);
-			return 0;
+	memset(product_name, 0, I2C_BUF_SIZE);
+	env_init();
+	env_load();
+	name = env_get("product_name");
+	if (name)
+		snprintf(product_name, I2C_BUF_SIZE, "%s", name);
+	memset(fdt_name, 0, I2C_BUF_SIZE);
+	for (i = 0; i < ARRAY_SIZE(k1_board_map); i++) {
+		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 (tlv_entry->type == TLV_CODE_CRC_32)
-			return -ENOENT;
-		entry_size = tlv_entry->length + sizeof(struct tlvinfo_tlv);
-		i += entry_size;
-		p += entry_size;
-		tlv_entry = (struct tlvinfo_tlv *)p;
 	}
-	return -ENOENT;
+	if (fdt_name[0] == '\0') {
+		/* set default board name */
+		sprintf(fdt_name, CONFIG_DEFAULT_DEVICE_TREE);
+	}
+	memset(product_name, 0, I2C_BUF_SIZE);
+	memcpy(product_name, fdt_name, I2C_BUF_SIZE);
 }
 
 static void clk_early_init(void)
@@ -364,11 +368,6 @@ void board_init_f(ulong dummy)
 	preloader_console_init();
 
 	i2c_early_init();
-	ret = read_product_name(product_name, I2C_BUF_SIZE);
-	if (ret)
-		log_info("Fail to detect board:%d\n", ret);
-	else
-		log_info("Get board name:%s\n", product_name);
 	pmic_init();
 
 	ddr_early_init();
@@ -430,26 +429,14 @@ void spl_board_init(void)
 {
 }
 
-int board_fit_config_name_match(const char *name)
+void spl_perform_board_fixups(struct spl_image_info *spl_image)
 {
-	char fdt_name[I2C_BUF_SIZE];
-	int i;
+	fixup_product_name();
+}
 
-	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))
+int board_fit_config_name_match(const char *name)
+{
+	if (!strcmp(name, product_name))
 		return 0;
 	return -ENOENT;
 }

-- 
2.51.0

Re: [PATCH v6 11/11] spacemit: k1: load product name from environment variable

[Yao Zi]

On Mon, Jul 27, 2026 at 02:59:13PM +0800, Eric Chung wrote:
> Read the product name from the environment instead of EEPROM,
> as the EEPROM may not be programmed and the environment always
> contains this information.

Please explain why the environment "always contains this information".
This sounds strange since the environment variable is placed on MMC,
and there should be no "product_name" environment variable in the
environment partition if U-Boot is flashed to a completely new and
empty MMC.

The EEPROM should be the most robost way to distinguish board types. If
you do have devices with unprogrammed EEPROMs, please provide a guide to
program it correctly.

Furthremore, this doesn't seem to fit the subject of the series,
"spacemit mmc driver", since I don't think these changes are required
for MMC to work. So I think this patch should be split out even if you
do want to change the board detection logic.

> Signed-off-by: Eric Chung <eric.chung@riscstar.com>

Best regards,
Yao Zi