[PATCH v3 11/20] rockchip: rk3588: fix non-working SD controller if booting from other media

[Kever Yang]

Hi Quentin,

On 2024/3/9 01:55, Quentin Schulz wrote:
> Hi Kever,
>
> On 3/8/24 11:05, Kever Yang wrote:
>> Hi Quentin,
>>
>> On 2024/2/21 18:37, 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.
>>>
>>> The conditions to enter forced JTAG mode are the following:
>>> - force_jtag is 1
>>> - GPIO4_D2 is muxed for SDMMC function
>>> - GPIO3_D3 is muxed for SDMMC function
>>> - SDMMC_DET is inactive
>>
>> I have explain the reason and send fix for other boards  in kernel 
>> for why the force jtag
>>
>> function not working correctly, see patch [1] and I copy the commit 
>> message here:
>>
>> RK3588 has force_jtage feature which is enable JTAG function via sdmmc
>> pins automatically when there is no SD card insert, this feature will
>> need the GPIO0A4 works in sdmmc_det function like other mmc signal 
>> instead
>> of GPIO function, or else the force_jtag can not auto be disabled when
>> SD card insert.
>>
>> For the rk3588 boards available on mainline kernel, 10 boards enable 
>> SD card function
>> and 9 of then use GPIO0A4 as sdmmc_det, they should all able to use 
>> the force_jtag after
>> my patch apply.
>> The jaguar-rk3588 still have the issue because there is no sdmmc_det 
>> used.
>> The condition of force JTAG mode work correctly is :
>> - force_jtag in grf is 1;
>> - all the SDMMC signal including SDMMC_DET set as SDMMC function in 
>> GRF IOC/IOMUX reg;
>>
>> So please update the commit message and it would be better to move 
>> this setting in jaguar-rk3588 board
>
> Thanks, it's a tiny bit clearer to me now. We never exit this JTAG 
> mode on Jaguar because we have GPIO0A4 floating (with internal 
> pull-down). On Tiger (patches coming this month I hope), it's 
> hardwired to ground but we use a different GPIO as card detect, so 
> we'll have a similar issue. In any case, thanks for the explanation.
>
> Though, I do not understand why you absolutely want this force_jtag to 
> be always enabled. It is a debug feature.

You are right, it's not correct to always enabled for this debug 
feature. Let's leave this as rk3588 common code.

I will add some document in rockchip.rst for people to enable this 
feature easier, this feature also important for some project during develop.


Thanks,
- Kever


>
> Even more so, this is a security issue. I don't think anyone wants to 
> have the JTAG enabled if the user plays with the card detect pin or 
> boot without an SD card connected. I really insist this should be 
> enabled on the SoC level, the same way that the Linux kernel does it.
>
> We could compromise on a Kconfig symbol to enable force_jtag for 
> people who want it but still default to disabled on the SoC level, but 
> I'm not really seeing a reason for it.
>
>> so that other board can enable force_jtag with only modify kernel but 
>> not both kernel and U-Boot.
>>
> If you want JTAG support in U-Boot, you would patch U-Boot. If you 
> want JTAG support in the kernel, you would patch the kernel. If you 
> want it in both, you'd patch both. I'm not sure to understand what 
> disabling force_jtag in U-Boot has to do with force_jtag enabled from 
> the Linux kernel, what am I missing here?
>
> Cheers,
> Quentin