[PATCH 13/18] rockchip: rk3588: fix non-working SD controller if booting from other media

Thu Jan 25 12:02:49 CET 2024

Hi Kever,

On 1/25/24 11:29, Kever Yang wrote:
> Hi Quentin,
> 
> On 2024/1/24 18:50, Quentin Schulz wrote:
>> Hi Kever,
>>
>> On 1/24/24 11:19, Kever Yang wrote:
>>> Hi Quentin,
>>>
>>> On 2024/1/23 22:49, Quentin Schulz wrote:
>>>> From: Quentin Schulz <quentin.schulz at theobroma-systems.com>
>>>>
>>>> Rockchip SoCs have some jtag/sdmmc autoswitching that simply doesn't
>>>> work really well.[00] The Linux kernel disables it for all SoCs[01], so
>>>> U-Boot needs to do the same in order to fix issues related to SD 
>>>> card on
>>>> RK3588. This autoswitching is enabled (by default) via the force_jtag
>>>> bitfield in SYS_GRF_SOC_CON6 in the TRM part1.
>>>>
>>>> For some reason, when booting from SD card, the BootROM does mux the
>>>> SDMMC controller in the proper configuration for the RK3588-Jaguar. But
>>>> when we don't boot from SD card, U-Boot needs to set it up correctly to
>>>> allow accessing SD cards in that configuration.
>>>
>>> Could you share what's the really issue you met in your board?
>>>
>>
>> I revert the patch and then I have the following when booting from eMMC:
>>
>> """
>> DDR V1.11 f1474cf52f cym 23/05/09-11:02:36
>> LPDDR4X, 2112MHz
>> channel[0] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB
>> channel[1] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB
>> channel[2] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB
>> channel[3] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB
>> Manufacturer ID:0x1
>> CH0 RX Vref:27.1%, TX Vref:21.8%,0.0%
>> CH1 RX Vref:30.1%, TX Vref:20.8%,0.0%
>> CH2 RX Vref:27.9%, TX Vref:21.8%,0.0%
>> CH3 RX Vref:31.4%, TX Vref:19.8%,0.0%
>> change to F1: 528MHz
>> change to F2: 1068MHz
>> change to F3: 1560MHz
>> change to F0: 2112MHz
>> out
>>
>> U-Boot SPL 2024.01-00344-gf1fab3b9557 (Jan 24 2024 - 11:33:43 +0100)
>> Trying to boot from MMC1
>> ## Checking hash(es) for config config-1 ... OK
>> ## Checking hash(es) for Image atf-1 ... sha256+ OK
>> ## Checking hash(es) for Image u-boot ... sha256+ OK
>> ## Checking hash(es) for Image fdt-1 ... sha256+ OK
>> ## Checking hash(es) for Image atf-2 ... sha256+ OK
>> ## Checking hash(es) for Image atf-3 ... sha256+ OK
>> INFO:    Preloader serial: 2
>> NOTICE:  BL31: v2.3():v2.3-589-g3389cfdda:derrick.huang
>> NOTICE:  BL31: Built : 10:14:29, May  9 2023
>> INFO:    spec: 0x1
>> INFO:    ext 32k is not valid
>> INFO:    ddr: stride-en 4CH
>> INFO:    GICv3 without legacy support detected.
>> INFO:    ARM GICv3 driver initialized in EL3
>> INFO:    valid_cpu_msk=0xff bcore0_rst = 0x0, bcore1_rst = 0x0
>> INFO:    system boots from cpu-hwid-0
>> INFO:    idle_st=0x21fff, pd_st=0x11fff9, repair_st=0xfff70001
>> INFO:    dfs DDR fsp_params[0].freq_mhz= 2112MHz
>> INFO:    dfs DDR fsp_params[1].freq_mhz= 528MHz
>> INFO:    dfs DDR fsp_params[2].freq_mhz= 1068MHz
>> INFO:    dfs DDR fsp_params[3].freq_mhz= 1560MHz
>> INFO:    BL31: Initialising Exception Handling Framework
>> INFO:    BL31: Initializing runtime services
>> WARNING: No OPTEE provided by BL2 boot loader, Booting device without 
>> OPTEE initialization. SMC`s destined for OPTEE will return SMC_UNK
>> ERROR:   Error initializing runtime service opteed_fast
>> INFO:    BL31: Preparing for EL3 exit to normal world
>> INFO:    Entry point address = 0xa00000
>> INFO:    SPSR = 0x3c9
>>
>>
>> U-Boot 2024.01-00344-gf1fab3b9557 (Jan 24 2024 - 11:33:43 +0100)
>>
>> Model: Theobroma Systems RK3588-SBC Jaguar
>> DRAM:  4 GiB (effective 3.7 GiB)
>> Core:  327 devices, 26 uclasses, devicetree: separate
>> MMC:   mmc at fe2c0000: 1, mmc at fe2e0000: 0
>> Loading Environment from MMC... *** Warning - bad CRC, using default 
>> environment
>>
>> In:    serial at feb50000
>> Out:   serial at feb50000
>> Err:   serial at feb50000
>> Model: Theobroma Systems RK3588-SBC Jaguar
>> Net:   eth0: ethernet at fe1b0000
>> Hit any key to stop autoboot:  0
>> => mmc dev 1
>> unable to select a mode
>> =>
>> """
>>
>>> The SD card will need to enable SD-DET for SD card function int he 
>>> hardware design,
>>>
>>
>> We do not have an SD-DET on that board, this is not possible (the 
>> connector doesn't support it).
>>
>> SDMMC_DET/GPIO0_A4_u signal is pulled low in HW if left floating (the 
>> state by default since we expose it on an external connector) but we 
>> plan to let customer use it as a GPIO.
> 
> 
> I didn't follow this issue closely in kernel side before, but I would 
> like to know why this happen.
> Is it possible to share the schematic of your board? I want to 
> understand why you didn't use SDMMC_DET for the card slot in hardware 
> design, which always need an IO for driver to detect the card.

We don't have a dedicated CD pin for the SD card connector.

https://www.digikey.com/en/products/detail/molex/0472192001/3044807 is 
the SD card connector we use.

This is allowed by the SD spec, c.f. Table 3-1 : SD Memory Card Pad 
Assignment[1]

"""
1 CD/DAT3(2) I/O/PP(3) Card Detect/Data Line [Bit 3]

2) The extended DAT lines (DAT1-DAT3) are input on power up. They start 
to operate as DAT lines after SET_BUS_WIDTH command. The Host shall keep 
its own DAT1-DAT3 lines in input mode, as well, while they are not used.
3) At power up this line has a 50KOhm pull up enabled in the card. This 
resistor serves two functions Card detection and Mode Selection. For 
Mode Selection, the host can drive the line high or let it be pulled 
high to select SD mode. If the host wants to select SPI mode it should 
drive the line low. For Card detection, the host detects that the line 
is pulled high. This pull-up should be disconnected by the user, during 
regular data transfer, with SET_CLR_CARD_DETECT (ACMD42) command
"""

[1] https://academy.cba.mit.edu/classes/networking_communications/SD/SD.pdf

> What I know is if the SD card using all the IO including SDMMC_DET with 
> its iomux set to sdmmc function, then the force_jtag should work correctly.
> If you only use IO signal other than SDMMC_DET as sdmmc function, and 
> set SDMMC_DET iomux work as GPIO, then yes, you need to disable the 
> force_jtag.
> Since SDMMC_DET in rk3588 is an IO only have one function(not like other 
> GPIOs may have more than 2 functions for choice), this IO can always be 
> used as SDMMC_DET without conflict when the board has SDcard support.
> 

We don't use SDMMC_DET for card detection, but in GPIO mode **and** we 
cannot use SDMMC_DET for card detection because the connector doesn't 
expose a card detect pin.

We just use broken-cd; property (c.f. 
https://elixir.bootlin.com/linux/v6.8-rc1/source/arch/arm64/boot/dts/rockchip/rk3588-jaguar.dts#L402) 
to do polling for card detect in the kernel, but we wouldn't mind too 
much if there's no detection for the SD card anyway as it is cumbersome 
to replace the SD card (which is the purpose of this connector, it needs 
be extra secure since the board is supposed to be used in moving robots) 
so not much of a use-case to detect an insertion/removal at runtime.

Cheers,
Quentin