We experience U-boot boot problems after testing blowin of the fuse that controls JTAG availability. No other fuses have been blown yet. Boots seem to hang in clock_enable_coresight when CoreSight interfaces are being unlocked. What is the dependency between the JTAG fuse and CoreSight? Obviously there should be one, but is a boot hang and expected result in this case? We could try checking the jtag fuse status before calling clock_enable_coresight, but there seems to be no jtag related member in struct fuse_regs, and we have not found any specification on where in system memory that would be available for reading. In kernel side there is the tegra-fuse driver, but is there a convenient way to check the “jtag disabled” fuse status in U-boot in tegra124?
Coresight is the debug architecture to debug ARM cores. It uses Serial-wire/JTAG(SWJ) interface and is an IP from ARM.
Can you give the details about the fuse blown?
Thanks for interest. We have blown the fuse that for user space is available as /sys/devices/platform/tegra-fuse/jtag_disable. This is exposed to user space by kernel driver tegra-fuse. This is the only fuse we have blown so far.
Command “cat /sys/devices/platform/tegra-fuse/jtag_disable” gives an expected response if the fuse is blown:
If we in U-Boot file arch/arm/cpu/arm720t/tegra124/cpu.c comment out the call to clock_enable_coresight(1), the board boots up properly, even if the JTAG disabled fuse is blown. Actually, I think that the boot fails in clock_enable_coresight when calling
rst = CORESIGHT_UNLOCK;
writel(rst, CSITE_CPU_DBG0_LAR); // <== FAIL
Obviously we can make SW variants for boards that we want to leave JTAG available. Actually, we are working on a custom board, but the symptom is the same as in Jetson TK1 reference board.
once JTAG is disabled, coresight operation will be treated as illegal, and Tegra will halt.
As you’ve found, you can make u-boot work by ignoring function clock_enable_coresight.