Re: [PATCH v2 0/2] board: sophgo: add support for Milk-V Duo 256M

Hi Andrei,

On Tue, Aug 25, 2026 at 08:01:37PM +0200, Andrei Lalaev wrote:
> On 25.08.26 14:24, Hiago De Franco wrote:
> > Hi Andrei,
> > 
> > On Sat, Aug 22, 2026 at 11:15:10AM +0200, Andrei Lalaev wrote:
> >> Hi Hiago,
> >>
> >> Thank you for the patches.
> >>
> >> From your cover letter I understood that SD card is supported.
> >> However whatever I try, I always get the following error:
> >>
> >>     U-Boot 2026.07-00002-gbd5e3de2ed6a (Aug 22 2026 - 10:27:48 +0200)milkv_duo_256m
> >>
> >>     DRAM:  256 MiB
> >>     Core:  20 devices, 13 uclasses, devicetree: separate
> >>     MMC:   mmc@4310000: 0
> >>     Loading Environment from nowhere... OK
> >>     In:    serial@4140000
> >>     Out:   serial@4140000
> >>     Err:   serial@4140000
> >>     Net:
> >>     Warning: ethernet@4070000 (eth0) using random MAC address - 16:21:8c:10:cd:96
> >>     eth0: ethernet@4070000
> >>     Hit any key to stop autoboot: 0
> >>     milkv_duo_256m# mmc info
> >>     Card did not respond to voltage select! : -110
> >>     milkv_duo_256m# mmc rescan
> >>     Card did not respond to voltage select! : -110
> >>
> >>
> >> I tried 2 different SD cards and got the same result.
> >>
> >> Am I doing something wrong, or is there something else I need to configure?
> > 
> > You are most likely missing this patch:
> > 
> > https://lore.kernel.org/all/[email protected]/
> > 
> > This is needed in order to make the SD card work. This patch is already
> > merged on main branch, as commit 3a4a8963aace ("mmc: cv1800b_sdhci:
> > honor 'no-1-8-v' DT property").
> > 
> > Check this patch and let me know if it works now ;)
> 
> Thank you for your response:)
> 
> I also tried the latest main branch (so all patches are definitely included)
> and had the same problem.
> 
> I guess I somehow managed to fix the problem, so below I'll describe what I did
> and would like to hear your thoughts about it.
> 
> 
> When I generated `fip.bin` using precompiled binaries from fiptool repo [1],
> it started working most of the time. Previously I was using an FSBL manually generated
> using official SDK [2]. However, I would still occasionally get
> voltage select error and timeouts.
> 
> So I started comparing FSBL and U-boot from Sophgo (2021.10) and
> I couldn't find any differences that could explain this behaviour.
> 
> Today I found out that the kernel DTS configures the SD0_CLK pin to a different value [3].
> By default, we have 0x48 in IOBLK_G10_REG_SD0_CLK register, but if I set it to 0x84
> like kernel does, it magically starts to work all the time.
> 
> I understand why increasing the drive strength fixed timeout issues, but I don't understand
> why I don't see the same problem with the U-Boot from Sophgo (2021.10).
> 
> 1 - https://github.com/sophgo/fiptool
> 2 - https://github.com/milkv-duo/duo-buildroot-sdk-v2/tree/main
> 3 - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/riscv/boot/dts/sophgo/sg2002-milkv-duo256m.dts#n68

Thanks for digging into this.

I made some tests here on my milkv-duo 256M and I might have the answer
you are looking for, hopefully.

0x48 is SoC reset value, based on the TRM. This is what I read on my
U-Boot (main branch, like yours):

0x03001a00 SD0_CLK = 0x48 pull-down, 10800 uA  <-- reset value

So on my board the BootROM already does everything Sophgo's
cvi_sdio0_pad_setting() does. SD0_CLK is the single register nobody
programs, exactly as you found. I also checked the FSBL and it never
touches SD0 and never touches drive strength, from what I could see.

I am not able to reproduce your issue, it works every time for me. I
suspect there is a difference on the hardware here: maybe your board has
less margin for the drive strength than mine, it works at the stock
50MHz even with the CLK drive strength at its minimum.

To trigger the issue, I had to force SDHCI divider from N=4 to N=2, so
doubling the clock. With that, I triggered your issue. Of course I am
not sure if this is the same issue that is triggering your, but at least
now with the double clock I was able to increase the drive strength by
writing 0x84 (the kernel value) and it fixed the issue (which makes
sense).

I was not able to properly answer the reason why Sophgo U-Boot works, so
I used Claude to look at the code for me and compare the differences,
here is what it found out:

"It is the PHY. cvi_sdhci_set_ios_post() has a DS/HS branch that does:

    PHY_CONFIG    (0x24c) |= BIT(0)          /* TX_BPS */
    PHY_TX_RX_DLY (0x240)  = 0x01000100

The kernel does the same thing, unconditionally, in
cv18xx_sdhci_reset() (drivers/mmc/host/sdhci-of-dwcmshc.c):

    val |= CV18XX_PHY_TX_BPS;                     /* PHY_CONFIG bit 0 */
    val = TX_DLY(0) | TX_SRC(INVERT_CLK_TX)
        | RX_DLY(0) | RX_SRC(INVERT_RX_CLK);      /* == 0x01000100 */

Upstream U-Boot does neither. cv1800b_sdhci.c only writes
SDHCI_PHY_TX_RX_DLY from cv1800b_execute_tuning(), reached only through
platform_execute_tuning - and that never runs on this board, because
no-1-8-v caps us at High Speed 50MHz / 3.3V and tuning only happens in
UHS modes."

I am not 100% convinced by that, but I will take a look, we might need a
patch here on upstream to configure the PHY properly as the downstream
u-boot and kernel does. Anyway, is funny that I can only reproduce your
issue on this conditions, but these boards might not be something we can
blindly trust ;)

Could you dump these on your board, at the U-Boot prompt on unmodified
upstream main, before touching anything?

    md.l 0x03001a00 8      # SD0_CLK / CMD / D0-D3 pad config
    md.l 0x03001900 4      # SD0_CD, SD0_PWR_EN
    md.l 0x030001f4 1      # sd_pwrsw_ctrl
    md.l 0x0300101c 8      # SD0 pin mux
    md.l 0x04310240 1      # PHY_TX_RX_DLY
    md.l 0x0431024c 1      # PHY_CONFIG

Meanwhile I will be able to investigate this further in a couple of
days.

> 
> >>
> >>
> >> Best regards,
> >> Andrei Lalaev
> > 
> > Regards,
> > Hiago.
> 
> 
> -- 
> Best regards,
> Andrei Lalaev

Regards,
Hiago.