Re: [PATCH v2 2/3] mmc: k1: let the SPL read SD cards more than one block at a time

[Hung-Chun Tseng <alan.tseng.cs@gmail.com>]

Hi Yixun, Tanmay,

On Wed, Oct 14, 2026 at 09:28:35PM +0000, Yixun Lan wrote:
> I'd suggest we try to see if able to go with setting DT property,
>  assigned-clock-parents or assigned-clock-rates
> the advantage is it will also work on Linux kernel side

That makes sense, so please consider my RFC "mmc: k1: do not require
max-frequency in the device tree" withdrawn in favour of the
assigned-clock-* approach.

For what it's worth, I finally got a working UART on a Milk-V Jupiter
and ran the mainline SPL from an SD card. Two data points that may help
Tanmay with the respin:

- 2/3: Jupiter shows the same failure as the BPI-F3. With
  set_vdd_mmc() putting aldo1 (the SD vqmmc) at 1.8 V, the card runs
  at SD High Speed, 50 MHz, 4-bit. Single-block reads return the right
  data (protective MBR, "EFI PART" header), but a 32-block read of the
  GPT entries returns 0 blocks, so part_get_info() fails and SPL gives
  up. With aldo1 set to 3.3 V instead (a local hack, not a proposal),
  multi-block reads work, the SPL loads u-boot.itb from the "uboot"
  partition and U-Boot proper reaches the prompt; "mmc read" of 2048
  blocks also succeeds there. So dropping set_vdd_mmc() in favour of
  SPL_MMC_IO_VOLTAGE looks right from Jupiter's side too.

- A side note on debugging this: the SPL printed "Error: -38", which
  is misleading. The real error from part_get_info() was -ENOENT; the
  -ENOSYS comes from the SYS_MMCSD_FS_BOOT fallback, which runs after
  the raw read fails and has no SPL filesystem enabled to try.

- The io clock that BootROM leaves for sdhci0 on Jupiter is
  204.8 MHz, matching the SD rate you mention.

Tanmay, I'm happy to test the next version on the Jupiter and reply
with a Tested-by.

Thanks,
Hung-Chun