Hi Kever,
On 1/26/24 03:57, Kever Yang wrote:
Hi Quentin,
On 2024/1/25 19:02, Quentin Schulz wrote:
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@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@fe2c0000: 1, mmc@fe2e0000: 0 Loading Environment from MMC... *** Warning - bad CRC, using default environment
In: serial@feb50000 Out: serial@feb50000 Err: serial@feb50000 Model: Theobroma Systems RK3588-SBC Jaguar Net: eth0: ethernet@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.
Thanks for your information, but I think you are using the wrong microSD connector for rk3588 and maybe also for other rockchip SoCs. Here are four microSD card connector from the web you provide, all of them have card detect signal available for pcb: https://www.digikey.com/en/product-highlight/m/molex-connector/sd-memory-car...
None of those fit our requirements. We need a safe system that doesn't break because of vibrations or shocks. Push-pull connectors are out of question for our design. We have had issues with our Q7 devkit with push-pull connector with SD cards slightly smaller or inserted somewhat the wrong way. I can recall also countless of discussions in the early days of the Raspberry Pis where there were a lot of issues related to SD cards.
This is basically the mechanism we are using https://media.distrelec.com/Web/WebShopImages/landscape_large/4-/01/Molex-50...
I can admit on our pictures of Jaguar and on the Digikey link I provided earlier that it is not clear it is THAT kind of connector and not a push-pull one.
Also.... It works just fine in Linux kernel with broken-cd and in U-Boot with this patch, sooooooo I don't think it is "the wrong microSD connector for rk3588 and maybe also for other rockchip SoCs." :)
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]
- 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 """
Yes, you are right for the SD spec, there is another design for Card detection, which need the controller supports SET_CLR_CARD_DETECT command, and like many other SoCs, rk3588 does not support it.
Thanks for the confirmation, I indeed hadn't found anything in the TRM for it... which is fine, we are not expecting it anyway, we use broken-cd; for it now.
My understanding is that only if none of broken-cd, cd-gpios or non-removable are passed that this kind of card detect mechanism is used. I don't think I should have given this information, as this is not what we're using, so I may have introduced confusing information into the discussion, sorry.
In U-Boot, broken-cd means that we assume the card is always present.
In the Linux kernel, as far as I could tell, the check is done with mmc_sd_detect() which calls _mmc_detect_card_removed() which calls host->bus_ops->alive() which is mmc_sd_alive() which sends CMD_13 to the SD card. It'll wait for the command to return, which it won't if the card isn't present, thus detecting card presence. The implementation of the CMD13 command is required by the spec.
According to the SD spec: """ The host may poll the status of the card with a SEND_STATUS command (CMD13) at any time, and the card will respond with its status. """
So this is perfectly fine for using SD cards on a system without a CD pin and without relying on the DAT3 pin to be used as CD pin (which Rockchip SoCs - at least RK3588 - doesn't support).
Only RTS5208(a Realtek PCI-E Card Reader) supports this command when I search this cmd in kernel code.
Back to this patch, I think it would be better to turn off the force_jtag in board level instead of soc level for now.
I strongly disagree with this. This is making the bring-up of boards unnecessarily complex. I'm lucky I'm working with Heiko who encountered this issue years ago and remembered some funny things happening with the force_jtag feature, otherwise it'd have taken me much longer to figure all this out.
What is the benefit for keeping force_jtag enabled? Especially since the kernel has disabled it for almost a decade already? In my opinion this is a debugging feature, if you need it you can enable it again by removing this line or writing to the register manually. And this would make it even more explicit that such a feature exist because there is now some comment for it.
Cheers, Quentin