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

[Quentin Schulz]

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.

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