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
