On 11-10-2026 00:32, Kathpalia, Tanmay wrote:
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.
Hi Zixian,
A few follow-up questions about the SPL-only failure:
The callback limits reads only when CONFIG_SPL_BUILD is enabled. U-Boot
proper already uses mmc->cfg->b_max, even without this patch.
Therefore, multi-block SD reads should already be used in U-Boot proper.
Could you please boot U-Boot proper from another device and test a
multi-block read from the same SD cards?
Could you also compare the following between SPL and U-Boot proper?
- selected SD timing mode
- card clock frequency
- bus width
- PIO, SDMA, or ADMA transfer path
- whether the card advertises CMD23 support
Although both stages use the same driver source, they may use different
configuration options, transfer paths, clocks, and timing modes. This
could explain why CMD18 works in U-Boot proper but fails in SPL.
Regards,
Tanmay
