On 2023-04-27 17:33, Eugen Hristev wrote: > On 4/27/23 18:25, Jonas Karlman wrote: >> Hi Eugen, >> >> On 2023-04-27 16:45, Eugen Hristev wrote: >>> On 4/18/23 19:46, Jonas Karlman wrote: >>>> This series fixes eMMC HS400 modes on RK3568 and add support for RK3588. >>>> >>>> It has been tested with rock-3a-rk3568/rock5b-rk3588 defconfig and >>>> >>>> CONFIG_MMC_HS200_SUPPORT=y >>>> CONFIG_MMC_HS400_SUPPORT=y >>>> CONFIG_MMC_HS400_ES_SUPPORT=y >>>> CONFIG_MMC_SPEED_MODE_SET=y >>>> >>>> using the following command to switch mode and then read 512 MiB of data >>>> from eMMC into memory, >>>> >>>> => mmc dev 0 0 <mode> && mmc info && mmc read 10000000 2000 10000 >>>> >>>> for each of the modes below. >>>> >>>> 0 = MMC legacy >>>> 1 = MMC High Speed (26MHz) >>>> 3 = MMC High Speed (52MHz) >>>> 4 = MMC DDR52 (52MHz) >>>> 10 = HS200 (200MHz) >>>> 11 = HS400 (200MHz) >>>> 12 = HS400ES (200MHz) >>>> >>>> All reads have reported OK, prior to this some of these modes worked and >>>> others failed. >>>> >>>> Patch 1-2 fixes an issue with high-speed bit and uhs speed mode field. >>>> Patch 3-6 refactors the rk3568 driver to use set_clock and config_dll >>>> ops, so that clocks and regs are changed when output clock is disabled. >>>> Patch 7-10 continues refactoring and simplification of the driver. >>>> Patch 11-12 updates tap and delay values to fix HS400 modes on RK3568. >>>> Patch 13-15 adds support for RK3588 to driver and device tree. >>>> Patch 16-17 adds workarounds needed to use PIO mode in SPL to >>>> successfully load TF-A into SRAM when booting from eMMC on RK3588. >>>> >>>> Note that this series does not include any change to defconfigs to >>>> enable HS200/HS400/HS400ES modes. >>>> >>>> Changes in v2: >>>> - Add Signed-off-by tag and update commit message with a note from where >>>> reg-values originates from >>>> - Rename quirks to flags >>>> - Use driver data for hs200/hs400 txclk tapnum values >>>> - Change u-boot,dm-spl to bootph-pre-ram >>>> >>>> This series require working pinctrl, see [1]. A copy of this series and >>>> its dependencies can be found at [2]. >>>> >>>> [1] >>>> https://patchwork.ozlabs.org/project/uboot/patch/20230315153215.389809-1-eugen.hris...@collabora.com/ >>>> [2] https://github.com/Kwiboo/u-boot-rockchip/commits/rk35xx-emmc-v2 >>>> >>>> Jonas Karlman (16): >>>> mmc: sdhci: Fix HISPD bit handling for MMC HS 52MHz mode >>>> mmc: sdhci: Set UHS Mode Select field for UHS SDR25 mode >>>> mmc: rockchip_sdhci: Fix use of device private data >>>> mmc: rockchip_sdhci: Remove unneeded emmc_phy_init ops >>>> mmc: rockchip_sdhci: Add set_clock and config_dll sdhci_ops >>>> mmc: rockchip_sdhci: Use set_clock and config_dll sdhci_ops >>>> mmc: rockchip_sdhci: Refactor execute tuning error handling >>>> mmc: rockchip_sdhci: Update speed mode controls in set_ios_post >>>> mmc: rockchip_sdhci: Remove empty get_phy and set_enhanced_strobe ops >>>> mmc: rockchip_sdhci: Rearrange and simplify used regs and flags >>>> mmc: rockchip_sdhci: Fix HS400 and HS400ES mode on RK3568 >>>> rockchip: rk3568-rock-3a: Enable support for more eMMC modes >>>> mmc: rockchip_sdhci: Add support for RK3588 >>>> rockchip: rk3588-rock-5b: Include eMMC node in SPL dtb >>>> clk: rockchip: rk3588: Add limited TMCLK_EMMC clock support >>>> mmc: rockchip_sdhci: Limit number of blocks read in a single command >>>> >>>> Peter Geis (1): >>>> mmc: sdhci: Allow disabling of SDMA in SPL >>>> >>>> arch/arm/dts/rk3568-rock-3a-u-boot.dtsi | 8 + >>>> arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 12 +- >>>> arch/arm/dts/rk3588s-u-boot.dtsi | 4 + >>>> configs/rock5b-rk3588_defconfig | 1 + >>>> drivers/clk/rockchip/clk_rk3588.c | 2 + >>>> drivers/mmc/Kconfig | 8 + >>>> drivers/mmc/rockchip_sdhci.c | 309 +++++++++++++----------- >>>> drivers/mmc/sdhci.c | 13 +- >>>> 8 files changed, 215 insertions(+), 142 deletions(-) >>>> >>> >>> >>> Hi Jonas, >>> >>> I saw in the logs you provided in the series that the SPL should also >>> work in eMMC in rk3588, however, I am getting this error on my rock5b : >>> >>> Trying to boot from MMC2 >>> spl: mmc boot mode: raw >>> hdr read sector 4000, count=1 >>> mmc_load_image_raw_sector: mmc block read error >>> >>> Do you have any idea of what's going wrong ? >> >> I know that there was some issue reading more then 4 sectors using CMD18. >> But here it looks like the initial 1 sector read using CMD17 fails. >> Try with CONFIG_MMC_VERBOSE=y, CONFIG_MMC_TRACE=y and CONFIG_LOGLEVEL=8 >> to get a little more detailed log. > > Yes I saw that from debug, it's the initial sector where the FIT should > reside
Please enable above configs and compare what CMD_SEND fails, here is current master branch with above 3 extra CONFIG enabled: https://gist.github.com/Kwiboo/56d82e2d7799331ff21999847a178657 CMD_SEND:17 ARG 0x00004000 MMC_RSP_R1,5,6,7 0x00000900 That should be the CMD17 that tries to read FIT image header from sector 0x4000. How far does yours gets? > >> >> Workaround to force using PIO read-mode and limit to 4 sectors: >> https://source.denx.de/u-boot/u-boot/-/commit/2cc6cde647e2cf61a29f389e8d263bf19672f0f5 >> >> Did a quick runtime test booting from my eMMC module using latest plain >> master branch, commit 2356053a945899687e894a3e3b3de09dd9814bb8, >> yesterday using a Radxa 32GB eMMC 5.1 module: >> https://gist.github.com/Kwiboo/3ff6be7cca04098b4fe3d555637ded37 >> >> It could also be worth testing with pinctrl included in SPL, I add them >> in my defconfig and SPI NOR series (was not included in my runtime test): >> https://patchwork.ozlabs.org/project/uboot/patch/20230422012309.402799-13-jo...@kwiboo.se/ >> > I added them, otherwise I was getting another error, card not inserted, > etc, so I figured the pins are missing from SPL. > > The error I am getting indicates to me some problems during transfer, I > had a look on the patch to disable SDMA, but I guess that doesn't apply > to SPL SDMA should be disabled in SPL using: # CONFIG_SPL_MMC_SDHCI_SDMA is not set But that should only be needed for loading atf into sram. Reading first sector to detect FIT image should still work with or without SDMA. > > I also have to mention that in U-boot proper, the eMMC works fine, if I > boot it from another media Strange, are you sure you have FIT image written at sector 0x4000? Did a re-test booting from different eMMC modules without any issue. My modules originate from Pine64, HardKernel or Radxa, 8, 16 or 32 GB in size. My board is a ROCK 5B V1.42 2022.08.29 revision if that could make any difference. I write rockchip-u-boot.bin to eMMC and SD-card in the same way: dd if=rockchip-u-boot.bin of=/dev/mmcblk0 seek=64 Regards, Jonas >> >> Regards, >> Jonas >> >>> >>> Thanks ! >>> Eugen >> >