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

[Andrei Lalaev <andrey.lalaev@gmail.com>]

Hi Hiago,

On 27.08.26 15:30, Hiago De Franco wrote:
> 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/20260507234836.284918-1-hfranco@baylibre.com/
>>>
>>> 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).


That's interesting. Thank you for your investigation.


> 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


Sure, here is the register dump before `mmc rescan`:

  # SD0_CLK / CMD / D0-D3 pad config
  milkv_duo_256m# md.l 0x03001a00 8
  03001a00: 00000048 00000044 00000044 00000044  H...D...D...D...
  03001a10: 00000044 00000044 00000010 00000000  D...D...........

  # SD0_CD, SD0_PWR_EN
  milkv_duo_256m# md.l 0x03001900 4
  03001900: 00000044 00000048 00000048 00000044  D...H...H...D...

  # sd_pwrsw_ctrl
  milkv_duo_256m# md.l 0x030001f4 1
  030001f4: 00001209                             ....

  # SD0 pin mux
  milkv_duo_256m# md.l 0x0300101c 8
  0300101c: 00000000 00000000 00000000 00000000  ................
  0300102c: 00000000 00000000 00000000 00000000  ................

  # PHY_TX_RX_DLY
  milkv_duo_256m# md.l 0x04310240 1
  04310240: 00000000                             ....

  # PHY_CONFIG
  milkv_duo_256m# md.l 0x0431024c 1
  0431024c: 00000000                             ....

and after:

  milkv_duo_256m# mmc rescan
  unable to select a mode

  # SD0_CLK / CMD / D0-D3 pad config
  milkv_duo_256m# md.l 0x03001a00 8
  03001a00: 00000048 00000044 00000044 00000044  H...D...D...D...
  03001a10: 00000044 00000044 00000010 00000000  D...D...........

  # SD0_CD, SD0_PWR_EN
  milkv_duo_256m# md.l 0x03001900 4
  03001900: 00000044 00000048 00000048 00000044  D...H...H...D...

  # sd_pwrsw_ctrl
  milkv_duo_256m# md.l 0x030001f4 1
  030001f4: 00001209                             ....

  # SD0 pin mux
  milkv_duo_256m# md.l 0x0300101c 8
  0300101c: 00000000 00000000 00000000 00000000  ................
  0300102c: 00000000 00000000 00000000 00000000  ................

  # PHY_TX_RX_DLY
  milkv_duo_256m# md.l 0x04310240 1
  04310240: 00000000                             ....

  # PHY_CONFIG
  milkv_duo_256m# md.l 0x0431024c 1
  0431024c: 00000000                             ....

And if I try to rescan several more times (until SD card is detected
and `mmc info` succeeds), all the registers have the same values as before.

I will probably dump registers with downstream U-Boot and
tracing enabled this weekend.

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

Thank you for your assistance :)
 >>
>>>>
>>>>
>>>> Best regards,
>>>> Andrei Lalaev
>>>
>>> Regards,
>>> Hiago.
>>
>>
>> -- 
>> Best regards,
>> Andrei Lalaev
> 
> Regards,
> Hiago.


-- 
Best regards,
Andrei Lalaev