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.sch...@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
