On 10-10-2026 11:47, Zixian Zeng wrote:
Hi, Dave:
On 2026/10/6 02:01, Dave Klotz wrote:
spacemit_sdhci_get_b_max() limits every SD read in the SPL to a single
block, so loading a ~1 MiB u-boot.itb from a card takes about 2000
separate commands. The controller handles multi-block PIO reads in the
SPL: the OrangePi RV2 has loaded U-Boot from microSD with them through
the v2026.07 and v2026.10 trees.
Drop the limit and use the host's b_max.
The merged v13 cover retains the v9 changelog entry choosing single-
block SD reads in SPL. This reverses that deliberate policy for the
recorded RV2 SPL boot use case; no general multi-card reliability claim
is made. K1 does not advertise MMC_CAP_CMD23, so the MMC core sends
CMD12 after a multi-block read rather than requiring CMD23. Additional
card models, cold boots and transfer-error recovery remain required.
Signed-off-by: Dave Klotz <[email protected]>
Reviewed-by: Tanmay Kathpalia <[email protected]>
---
Validation: unchanged executable change from v1; exact-base source
replay and checkpatch pass. The corrected combined integration, with
separate clock/MMC and DDR relocation fixes, passed SD SPL/FIT and
automatic NVMe EFI boot on the 4 GiB RV2 in a warm-boot trial. This is
an integration result, not an isolated test of this patch.
drivers/mmc/spacemit_sdhci.c | 11 -----------
1 file changed, 0 insertions(+), 11 deletions(-)
diff --git a/drivers/mmc/spacemit_sdhci.c b/drivers/mmc/spacemit_sdhci.c
index 6488ae0fdb..4284553177 100644
--- a/drivers/mmc/spacemit_sdhci.c
+++ b/drivers/mmc/spacemit_sdhci.c
@@ -324,16 +324,6 @@
return 0;
}
-static int spacemit_sdhci_get_b_max(struct udevice *dev, void *dst,
- lbaint_t blkcnt)
-{
- struct mmc *mmc = mmc_get_mmc_dev(dev);
-
- if (IS_ENABLED(CONFIG_SPL_BUILD) && mmc && IS_SD(mmc))
- return 1;
- return mmc->cfg->b_max;
-}
-
static void spacemit_sdhci_set_control_reg(struct sdhci_host *host)
{
struct mmc *mmc = host->mmc;
@@ -574,7 +564,6 @@
spacemit_mmc_ops = sdhci_ops;
spacemit_mmc_ops.wait_dat0 = spacemit_sdhci_wait_dat0;
- spacemit_mmc_ops.get_b_max = spacemit_sdhci_get_b_max;
ret = clk_get_bulk(dev, &plat->clks);
if (ret) {
Using the current version of the next branch u-boot (ed869863c7),
with your MMC patch series applied.
Since the SPI controller is not enabled by default on the BananaPi-F3,
I also applied another patch series:
Link:
https://lore.kernel.org/u-boot/[email protected]/
I tested u-boot SPL with three SD cards on a BananaPi-F3 and found
a reproducible issue, the specific error I encountered is spl:
partition error (Error: -38)
At the meantime, when i was revert the commit:
mmc: k1: let the SPL read SD cards more than one block at a time
the error has gone. Same SD card, same operation steps.
Maybe BananaPi-F3 do not support read SD cards more than one block at
a time?
Hi Zixian,
Thanks for testing this on the BananaPi-F3 and reporting this. The
same cards and steps failing only with this patch shows that
multi-block SD reads in the SPL are not reliable yet.
I would request to try one more experiment before dropping it.
Please add MMC_CAP_CMD23 to host->host_caps and boot the same cards
again. CMD23 (SET_BLOCK_COUNT) tells the card how many blocks to
transfer. mmc_read_blocks() then uses CMD23 plus CMD18, and it does
not send CMD12 afterwards. The current driver does not set
MMC_CAP_CMD23, so a multi-block read is CMD18 followed by CMD12.
After the SCR is read, the MMC core clears MMC_CAP_CMD23 when the card
does not advertise SD_SCR_CMD23_SUPPORT. Those cards stay on CMD18
plus CMD12.
This also matches Eric's earlier note that on K1 ADMA depends on CMD23:
https://patchwork.ozlabs.org/project/uboot/patch/[email protected]/
If the CMD23 test also fails, I agree that this patch should be
dropped.
Regards,
Tanmay
