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

[Dragan Simic]

Hello all,

On 2024-03-11 10:07, Kever Yang wrote:
> 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.

I think that having a new configuration option that enables
JTAG access would be good.  Of course, it would remain disabled
by default, but would allow anyone in need of JTAG access to get
it working rather easily.

>> 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