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/[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).
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
